Human approval checkpoints
An approval should authorise one exact proposal
A reviewer needs to approve the action that will actually run. Tie the decision to a saved target, payload and version so later changes cannot inherit it.
In this article
A yes can become ambiguous
An assistant prepares a change to an order's delivery address. A reviewer checks the address and approves it. Before execution, the assistant resolves an ambiguous suburb differently and changes the postcode. If the application stores only "approved: true" on the conversation, the altered payload may run under a decision that covered something else.
The problem is not that a person failed to read carefully. The system failed to preserve what the person approved. An approval should identify a concrete proposal, not give general permission for whatever the agent produces next.
Save the proposed operation before showing it to the reviewer. Include the target, material fields, relevant target version and any destination or attachment that changes the consequence. Give that proposal a stable identifier and prevent it being edited in place after approval.
Keep the decision separate from execution
The reviewer submits a decision against the saved proposal. The server verifies that the reviewer has authority for that action, records the decision and moves the proposal into an executable state. The executor then loads the approved payload from trusted storage.
Do not ask the model to reproduce the approved values from the conversation. Even an innocent reformatting step can change an address, amount or record identifier. The model can explain the result, but it should not reconstruct the authority-bearing payload.
- Save proposalTarget, payload and relevant version
- ReviewShow the actual effect and unresolved details
- Record decisionApprover, scope and expiry
- ExecuteLoad approved values and recheck current eligibility
Decide what makes a decision stale
Time is one cause of staleness, but not the only one. The target may change, the reviewer may lose authority or the business rule may be revised. Define which changes require a fresh proposal and which can be safely revalidated without returning to the person.
For example, a harmless internal note added to an order may not invalidate an address proposal, while dispatch beginning probably does. A blanket version mismatch rule is simple and conservative. A more selective rule can reduce unnecessary review, but it needs explicit dependencies and stronger tests.
The execution step should also prevent duplicate effects. Approval authorises an operation, while idempotency controls repeated submission of that same operation. Neither property replaces the other.
Show enough to make the decision useful
Present the current value, proposed value, target identity and any consequence that is not obvious from the field itself. Explain uncertainty before the approval, not in a hidden trace. A reviewer should not have to read the full agent conversation to discover which record will change.
Test by modifying one material field after approval. The executor should reject the changed proposal or require a new decision. Then test a repeated execution request for the unchanged proposal. The first test protects the meaning of approval. The second protects the business effect from duplication.
Primary sources
OWASP: transaction authorisationAWS Builders' Library: idempotent APIsReferences checked 11 September 2026.