A reviewer approves an AI-generated refund plan after seeing 12 affected orders and a $430 total. Before execution, the system refreshes its data: there are now 19 orders and a $760 total. The approval button remains green because the interface treats consent as a property of the session, not of the evidence.
Approval should authorize one versioned action envelope:
plan_id: refund-batch-184
plan_revision: 7
evidence_revision: orders-snapshot-31
action: issue_refunds
scope: 12 orders
maximum_consequence: USD 430
expires_at: 2026-07-23T16:30:00Z
approved_by: reviewer-id
If material fields change, approval expires. The system asks again and explains why.
What the review card must show
Place decision evidence before the action:
- Action: what will happen in plain language.
- Scope: exact count and selectable affected set.
- Consequence: money, permissions, deletion, communication, or other irreversible effect.
- Evidence: sources, timestamps, and gaps.
- Uncertainty: unresolved assumptions and excluded cases.
- Reversibility: undo window and what cannot be undone.
- Validity: plan revision and expiry condition.
A confidence percentage is not a substitute. It does not tell the reviewer which order is unsupported or what changed.
Define material change
Not every refresh should interrupt. Write rules before implementation:
| Change | Approval |
|---|---|
| wording only | preserve |
| source timestamp refresh, same values | preserve and update provenance |
| affected set adds/removes an item | expire |
| total consequence crosses threshold | expire |
| execution tool or destination changes | expire |
| stronger supporting evidence arrives | product-specific; show diff |
| evidence becomes unavailable | expire |
The server—not only the browser—must compare the approved envelope with the execution envelope. Otherwise a stale tab can execute obsolete consent.
Recovery flow
review revision 7
-> approve revision 7
-> evidence changes to revision 8
-> execution rejects stale approval
-> card shows a focused diff
-> reviewer can approve 8, edit scope, or cancel
The diff should answer “what changed since I approved?” Preserve the old decision in audit history without implying the reviewer approved the new version.
For accessibility, move focus to a concise change heading only when execution is blocked; do not unexpectedly move focus for background refreshes. Make additions and removals available as text, not color alone. Ensure the affected set is keyboard navigable and summaries remain meaningful at zoom.
Research protocol
This is a design hypothesis until tested. Use scenario-based sessions with representative reviewers.
Scenarios
- one item is added after approval;
- total cost rises above a policy threshold;
- evidence disappears but the plan stays identical;
- nonmaterial wording changes;
- approval expires while the reviewer is reading.
Tasks
Ask participants to decide, explain the authorized scope, respond to the change, and identify whether execution can proceed.
Measures
- correct prediction of tool effect;
- detection of changed scope;
- false re-approval of stale evidence;
- time to identify the material diff;
- successful cancellation or scope edit;
- confidence explanation based on evidence, not interface color.
Stop a scenario if participants repeatedly approve an action whose changed consequence they cannot describe. That is a safety failure, not merely usability friction.
Do not ask “Do you trust the AI?” Ask: “Which orders are authorized now, what changed, and what would stop you from approving?”
Content example
Weak:
The plan changed. Review again.
Stronger:
Approval expired: 7 orders were added after your review.
Previous: 12 refunds, up to $430.
Current: 19 refunds, up to $760.
Review the 7 additions before approving revision 8.
The stronger copy names the decision-relevant difference without claiming the new plan is wrong.
Limits
Versioned approval does not make a harmful action safe, guarantee evidence quality, or replace authorization policy. Some emergency workflows need delegated thresholds rather than repeated prompts. Excessive invalidation can train reflex approval, so materiality rules require monitoring and revision.
The boundary question is specific: which missing or changed evidence must stop execution, and which update would only add noise?
