An AI Approval Should Expire When the Facts Change

A developer has published a case study on the PTHHS project proposing that AI-agent approvals be bound to immutable revisions of the exact reviewed change rather than a stored approved flag, so that approvals expire when underlying records change. The design requires executors to load the approved revision, verify the operator's current authority, and compare record versions before submitting, returning a specific conflict on mismatch instead of letting the assistant reinterpret the old approval. The writeup cites AWS's October 15, 2026 "Trust in Depth" guidance on enforcing agent boundaries outside the model's reasoning, and notes that the public website is delivered while management activation, vendor verification, and agency acceptance remain staged.

A reviewer approves a proposed change. Before the worker submits it, someone else updates the underlying record. The approval still exists, but the facts that made it reasonable have moved. A system that stores only an approved flag has lost the most useful part of the decision: what, exactly, the person reviewed. Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked primary source. The example and implementation recommendations below are illustrative; they do not describe a production incident or claim that every suggested control is implemented in my project. My PTHHS case study https://asaday.co/projects/pthhs describes a management foundation built around preparation, a fresh recheck, independent review, a single submission, and read-back reconciliation for proposed vendor changes. The public website is delivered. Management activation, vendor verification, and agency acceptance remain staged, with fixture-based validation completed. AI-assisted note review is a planned extension. Those distinctions matter when using the work to discuss agent workflows. Consider an ordinary supplier-contact update in a hypothetical business application. An assistant proposes replacing a contact address, and an operator reviews the old value, proposed value, source, and reason. While the proposal waits, another employee corrects that same contact. Executing the original proposal now could overwrite newer work. The reviewer did not approve that conflict; they approved a change against an earlier state. I would give each proposal an immutable revision. Its review record would identify the target, operation, exact proposed values, relevant source versions, reviewer, and review time. If the assistant changes the payload after review, that is a new revision requiring a new decision. A concise summary can help a person understand a proposal, but the stored approval should refer to the actual structured change. A payload fingerprint can help detect a changed proposal, provided the application defines a consistent serialization. It does not prove that the underlying data is current, that the reviewer had authority, or that the proposed values are correct. Those are separate checks. AWS's October 15, 2026 Trust in Depth guidance https://aws.amazon.com/blogs/machine-learning/trust-in-depth-giving-agents-more-autonomy-without-losing-control/ argues for enforcing agent boundaries outside the model's reasoning. It describes policy enforcement on tool calls and rules that depend on earlier steps. That is a useful direction for approval design: instructions to respect review need an execution path that checks review. For the contact example, I would require the executor to load the approved revision, verify the operator's current authority, and compare the relevant record version before submitting. The tool should receive the approved payload from trusted application state rather than accept a replacement payload supplied by the assistant alongside an approval identifier. A mismatch should return a specific conflict: the contact changed after preparation, the approval expired, or the requested operation no longer matches the reviewed revision. The assistant can then prepare a revised proposal. It should not reinterpret the old approval as permission to repair the conflict however it chooses. Elapsed time also matters, but a timer cannot replace a version check. A record can change a second after review. Conversely, a quiet record may remain unchanged for hours. Choose expiry periods for the workflow and check the conditions that actually support the decision. Reading fresh data and then writing creates another interval in which something can change. Where the destination supports a conditional write against a version, use that facility to make the check part of the write. Confirm the actual contract; do not assume every API offers this behavior. When a vendor interface lacks that protection, document the limitation. A lock inside the local application can coordinate its own workers, but it cannot prevent an employee or another integration from changing the external system. A fresh read improves the evidence available to the executor without guaranteeing that the destination remains unchanged. The interface should make that uncertainty visible. Review is a decision about a proposed action. Submission is an attempt. Reconciliation establishes what the system can confirm afterward. Collapsing these into one green status makes troubleshooting harder and can mislead the next operator. The happy path should be only one fixture. Change the target record after preparation. Edit the proposed value after approval. Remove the reviewer's authority. Let the approval expire. Start two workers against the same proposal. Check that each case produces the intended conflict or controlled execution, with enough information to explain the result. Also test the user experience. A conflict message should show what changed and offer a clear path to prepare a new revision. If operators cannot distinguish a stale proposal from a service outage, they may keep approving the same request without understanding it. These controls cost implementation effort and can create extra review when records change frequently. Restrict invalidation to relevant dependencies where that can be done reliably. Rechecking every unrelated field may create noise; checking too little can preserve an approval whose premise has disappeared. For teams adding AI to existing business systems, this is a concrete place to invest the time faster prototyping creates. Let the assistant explore ways to prepare useful work. Make the execution service preserve what was reviewed, detect when its premise changes, and return the conflict for a new decision. That gives the next person operating the product a decision they can inspect rather than a flag they have to trust.