The first post, approval design for high-risk operations, argued that a human in the loop lets an AI handle a high-risk action such as a refund. The AI proposes. A person commits. The irreversible step runs from the approved request behind a durable two-person review.
This post shows that model on real screens. It follows one refund end to end in Latch: an AI-recommended account credit for a duplicate charge, paused for independent review before any money moves. The credit and the refund run through the same plugin. The walkthrough follows the credit through approval and a contested refund through rejection. The screenshots are the real screens an operator and a reviewer see.
Start with the action. Issuing a credit is one registered plugin action. The AI cannot do it alone. The action has an owner, an authentication mode, a health check and diagnostics. All are visible before any approval prompt exists.
The plugin registry. Credit issuance is one explicit integration, with its own auth mode, health status and diagnostics. An action that is not named cannot be controlled.
The risk tier is enforcement, not documentation. The credit and refund actions require two-person review (also called maker-checker). The actions have a 24-hour approval expiry and per-action overrides. The tier is a property of the action, configured once.
Risk tiers are enforcement, not documentation. The tier belongs to the action, not a wiki label, and it decides the enforcement mode.
One Credit Moves through the Gate
Once the action is named and tiered, the review is no longer a pop-up. It becomes a sequence inside the case: requested, approved by a different person, executed from the approved request. The case record holds the request, the reviewer, what they saw, what ran, and what the downstream system returned. Four cases show every control state: a refund awaiting approval, an approved credit ready to resume, a refund rejected for incomplete evidence, and a rejection that itself had to clear a review.
Approval as a queue of work. The gate lives on the case, not in a separate inbox the operator must monitor.
The AI recommends. It does not act. The support agent proposes a concrete, scoped credit and routes it through the review. The operator sees the recommendation in the case activity. A drafted customer response sits next to it. The operator decides what happens next.
The AI recommends. The operator decides. The proposed credit is concrete. It enters the case as a request, not a completed transaction.
A reviewer's decision is only as good as the information in front of them. The preview makes the financial impact and reference identifiers impossible to miss.
The action preview is a reviewable artefact. The amount, reference identifiers and human-readable reason are front and centre. The prompt is explicit: verify the duplicate-charge evidence before proceeding.
The control lives where the work lives. It sits on the case, with the requester and current state attached. A reviewer never leaves the record to act.
The approval card in context. It shows action identity, current state, requester and a clear review path inside the case timeline.
Before approving, the reviewer sees the exact stored request that will execute, field by field. Not a rendering. Not a summary. The canonical payload, with the guarantee that this is exactly what will run. Most products skip this moment.
The exact stored payload, including evidence and the customer account it touches, requested by a named operator. The dialog states the rule directly: the payload shown here is the exact request that will be approved or run.
If the preview shows one thing and the runtime sends another, every other control is theatre. Matching the reviewed action to the executed action is a design goal, not an accident. The review dialog and the execution record are the two halves of that guarantee.
Durable Approval Survives the Wait; a Rejection Is an Action Too
Approval is durable and decoupled from execution. Once approved, the action is tied to the case version and the stored request. It can run later from the exact approved payload, even after the original session is gone.
Approval is durable and separate from execution. The approved action stays tied to the case version and stored request, ready to resume.
Not every request should be approved. A rejection is a first-class state, not a dead end in an email thread. The control records why the action was rejected and keeps the full trail visible. A reviewer weeks later can reconstruct the decision without archaeology.
Rejection done right. The gate records why the action was rejected and keeps the full trail visible.
Role separation cuts both ways. Rejecting a contested refund is a consequential decision. The denial itself needs a second reviewer. An analyst flags the rejection as a risk decision. Voiding the refund still requires a two-person review before the case treats the rejection as final.
The AI flags the rejection as a risk decision. Voiding the refund still requires a second reviewer. A denial is an action.
The same case, lower in the trail. The void was approved by a second reviewer. Requester and approver are distinct. The timeline records both.
The Execution Record Is the Proof an Auditor Can Reconstruct
An approval is only as defensible as the evidence it leaves. The audit trail is separate from operational traces. Traces are high-volume and short-lived. Audit evidence is attributable and long-lived. Every entry is reconstructible: who decided, when, why, what they saw, what executed, and what the downstream system returned.
Execution evidence after an approved action runs: status, who ran it, the exact upstream request, the JSON payload and a byte-counted raw snapshot. This turns an approval into an inspectable control.
Six months from now an auditor asks two questions: what did the approver see, and what actually ran. The review dialog answers the first. The execution record answers the second. Together they survive 'how do you know'.
That is the model on one case. The third post covers durable approvals, policy as code, and building gated actions: durability and revalidation, role separation as policy, building plugin actions, and problems that do not yet have clean answers.