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.
Place decision evidence before the action:
A confidence percentage is not a substitute. It does not tell the reviewer which order is unsupported or what changed.
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.
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.
This is a design hypothesis until tested. Use scenario-based sessions with representative reviewers.
Ask participants to decide, explain the authorized scope, respond to the change, and identify whether execution can proceed.
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?”
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.
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?