Review before commit checkpoint
A mandatory pause before a consequential agent action becomes binding, so a mistake can be caught before it takes effect.
The impact of agents
As agent submission becomes routine, the moment to review what an agent will do (submit a form, authorize a payment, share data, or accept a decision) before it becomes binding disappears by default. Nothing in an automated flow naturally pauses for the user unless the service designs the pause in. Without the checkpoint, errors propagate into official records with no moment of human verification.
What must be verified
Before a consequential action becomes binding, the user must be able to confirm what the agent is about to do, on what data, and what it chose to include, to a confidence that catches an error before it becomes part of the official record. The agency operating the service must provide that checkpoint and ensure no consequential action proceeds without it.
Protecting access
The checkpoint only protects users who can use it. A review screen dense with legal or financial phrasing gets skimmed or can be misinterpreted. A struggling or time-poor reader, or someone reading the service in a second language, can mistakenly confirm incorrect information into an official record.
Keeping the path open
- Layer the disclosure: a user summary by default, expandable detail, and the full draft on request.
- Label every item in plain language, with a clearly signposted change affordance beside each answer.
- Add no countdown that pressures the review.
- Let a trusted person review with the user, by phone readback or shared access, without taking over the delegation.
- Make the review screen reachable by keyboard, with each answer's source and change control announced to assistive technology.
Response surface
No consequential agent action is binding until the person has reviewed it, so the agent's work is presented for approval with each item's source named.
Check before we submit
Your assistant prepared this. Nothing is sent until you confirm.
On what authority
Maturity
- Established
For human-in-the-loop review screens, a settled pattern across government and commercial services.
- Emerging Headline
For agent-specific review that shows data provenance for each answer, which is still taking shape.
Precedents
GOV.UK 'Check your answers'. The Design System mandates a check-your-answers page immediately before the confirmation screen for every transactional service, using a summary list for each group of answers with a change link beside each item. It is mandatory for services meeting the UK Government Service Standard, and the Scottish and NHS design systems carry the same pattern. A review step before commitment is a design-system requirement across three UK public-sector systems.
Intuit's review-before-action pattern. Intuit's content design system documents a contextual reminder placed near AI-generated content: 'I drafted your email using your past campaigns and brand settings. Review before sending.' The reminder names the data the system drew on, which gives the person grounds to assess what they are approving.
myTax pre-lodgment review (ATO). myTax pre-fills information from employers, banks, health funds, and share registries, then presents a review screen before lodgment where the person can see and amend what was pulled in. The checkpoint sits on a government transaction whose inputs the person did not enter.
DRCF on agentic AI. The UK's four digital regulators jointly name action bundling and choice outsourcing as an emerging risk: an agent executing pull-data, accept-terms, pay, share, and confirm as a single step, so the discrete decisions never surface. Four regulators have named the bundling itself as the hazard.
What carries over to agent use
Directly transferable but requires adaptation. When a human fills a form, the check-your-answers page reflects what they entered. When an agent fills a form, the review page must additionally surface: (a) what data the agent used, (b) what inferences or calculations it made, and (c) what it chose not to include.
The Intuit pattern is the closest existing model for this agent-specific variant because it names the data sources; the GOV.UK pattern supplies the structural template. The combination of GOV.UK's layout with Intuit's provenance labeling is the starting point.
Where things go wrong
The failure mode is consequential notices issued with no review checkpoint, so miscalculations reach users unseen. A mandatory draft-review before any notice creates a human verification point that surfaces errors before they are sent. A checkpoint can also fail while technically present: a review screen skimmed by habit, or an agent configured to auto-confirm the draft on the user's behalf, closes the pause without a human ever reading it. The confirmation record can then be turned against the user: a checkbox ticked by reflex becomes evidence that the user reviewed what they never read, and responsibility for the agent's error settles on the person least equipped to have caught it. The checkpoint stays a safeguard rather than a liability shield only when the service runs its own validation before the screen is shown and draws the eye to the answers it is least sure of. One confirm-all attestation is not proof of review.
Sources
6 references
The instrument, the operating deployment, or the official record itself.
Writing about the subject rather than the framework itself, including vendor commentary.