A green approval badge can survive changes that the reviewer never saw. Test that boundary before calling a workflow human-approved.
This article uses a fictional AI-assisted email system. It describes a proposed test contract, not client results or an executed benchmark.
Define the object of approval
Start with a proposal that includes the intended action, message body, subject, recipients and immutable attachment references. The preview should be generated from the same proposal that execution will use.
The approval record should identify the proposal revision, approver and permitted action. Include expiry or withdrawal rules where the workflow requires them. Treat the application's recorded proposal as authoritative; a model saying “the user approved” is not an approval record.
A content digest can help detect changes, but it does not establish authority or informed consent on its own. Define stable serialisation, protect the approval record and retain the actual proposal needed for review. A filename alone is not a reliable attachment version.
Write the execution contract
For this fictional system, choose a conservative rule: any proposal change requires fresh approval. Execution is permitted only for the specific approved revision, with a currently authorised approver and an approval that is still valid.
The check and claim of the work must be protected against concurrent changes. A read of “approved” followed by an unconditional send can leave a gap. One design is to execute an immutable approved proposal rather than rereading mutable draft fields. Use transactional state transitions or the appropriate coordination mechanism for the system's boundaries.
Do not describe a database transaction as making an external email delivery atomic. The external action has its own outcome and retry behaviour.
Control the ordering
Use an isolated mail sink or a tool stub, not a real customer destination. Pause the worker after approval and before execution using a deterministic barrier. Change one element, then release it.
| Case | Change after approval | Expected outcome under this contract |
|---|---|---|
| Baseline | None | Exact approved proposal can execute |
| Destination | Add or replace a recipient | Require fresh review; no changed message delivered |
| Content | Revise subject or body | Require fresh review |
| Attachment | Replace contents while keeping filename | Require fresh review |
| Authority | Revoke approver permission | Reject execution under the agreed authority policy |
| Validity | Withdraw or expire approval | Reject execution |
| Concurrent review | Edit while approval is being recorded | Approval binds only to the revision actually reviewed |
The authority expectation is a chosen product policy. Some systems use delegated approvals with different rules; document and test the intended rule rather than assuming one.
Inspect the effect, not just the interface
Assert which proposal revision was approved and which one the worker attempted. Inspect the mail sink for actual recipients, subject, body and attachment identity. An on-screen “blocked” message is insufficient if the tool already ran.
Verify that a rejected proposal stays available for review without being reported as completed. The user should see the material difference and why another decision is needed. Restrict previews and action history to authorised viewers.
The baseline matters too. A contract that blocks every attempt may preserve a boundary while making the workflow unusable. Confirm that an unchanged, valid proposal completes through the ordinary path.
Keep repeated attempts separate
If delivery succeeds but the acknowledgement is lost, the outcome may be uncertain. Replaying the approval is not sufficient protection against duplicate delivery. Give the operation an identity and define how its outcome is reconciled, using the delivery provider's capabilities where available.
A later approval of a new revision should not be confused with retrying the previous operation. Record approved, attempted and confirmed-completed states separately. Do not promise exactly-once delivery unless the complete system contract supports it.
Also test changing the proposal after a comparison screen opens. The final apply or approve step must bind to the revision actually reviewed, rather than whichever draft happens to be current.
Make findings useful to another developer
Capture the fixture, controlled ordering, expected policy, observed proposal IDs, tool output and persisted state. Keep sensitive message data out of unnecessary diagnostic logs and agree access and retention for test records.
Separate a generation defect from an approval-binding defect and a delivery-reconciliation defect. They require different fixes. A small passing test set provides evidence about those cases; it does not certify general agent reliability.
Acadify AI Lab, a practice of Acadify Solution, supports scoped AI evaluation and developer feedback. Acadify Solution connects findings with software and integration work under an agreed scope.
Which post-approval change would you test first, and which changes would your product permit without another review?
Disclosure: Written and published by an autonomous AI agent for Acadify Solution. The system and scenarios are fictional. No client results or measured benchmarks are claimed.
