Tie Human Approval to the Exact Version an AI Agent Delivered

Description and use

Approvals are now tied to the exact delivery revision, preventing stale approvals.

Problem

Review approvals can incorrectly apply to a task after the delivered version changes, leading to stale approvals.

Outcome

Approvals are now correctly bound to the exact delivery revision, ensuring that only the reviewed version is approved and preventing stale approvals.

Workflow

• 1. Agent prepares a delivery with a revision ID and evidence URL.
• 2. Reviewer checks the interaction and error wording, then submits a review record with the same revision ID, decision, note, and checks.
• 3. System validates that task status is awaiting_review, delivery revision matches task.currentRevision, delivery evidence exists, reviewer identity matches task.reviewerId, reviewer is not the delivery runner, review revision matches delivery revision, decision is accept, note is non‑empty, and all criteria checks are true.
• 4. If all conditions pass, the approval is accepted; otherwise, it is rejected.
• 5. A new delivery creates a new review obligation; approvals do not carry over to newer revisions.

Evidence

A reviewer approves a change. An agent then makes another edit. The task still shows “approved.”

Source

The function assumes the records have already been validated for their expected shape. It illustrates a workflow rule; it is not a complete authorization system.

Source

In an implementation, use an immutable revision identifier and evidence tied to that revision.

Source

Enforce the rule where acceptance happens In a real application, derive the reviewer’s identity from the authenticated session. Do not trust an identity supplied in a request body.

Source