What Your AI Approval Button Hides

In a fictional support case, I would approve a reply to Maya Lee only after removing an unsupported replacement promise. If an agent changed the recipient to Alex Ruiz before sending, the old approval must fail. I have not run that test. Until I have, I cannot claim the interface holds that boundary. The recipient is the test.

An approval must bind the action I saw to the action the system executes. A click alone tells me nothing about whether the recipient, promise, or authority changed after I pressed it. The button is not the boundary.

I have written about human control of AI. Here I want to make the decision visible, then name the test that could prove the boundary works.

What decision belongs on the screen?

I start with an illustrative support workflow. An agent proposes a reply about a delayed shipment. The draft sounds helpful. It also promises a replacement without the facts this fictional policy requires.

If I saw only the prose, I might proofread it and miss the commitment. I need the promise, recipient, and authority on the same screen.

Here is a wholly fictional card. Every name, address, order ID, policy condition, and timestamp is invented for this example. This is a proposed interface, not an Orbyt support product or an observed customer event.

Neither eligibility fact is here.

I would block the promised replacement until the missing facts are established. If I removed the promise, I would prepare a new reply for approval:

Hi Maya, I am sorry your order is late. I am checking the carrier status and replacement stock. I will update you when I have those facts.

That promise is gone.

I would approve that text to Maya only. The edit creates a new proposal; it cannot inherit approval for the earlier promise. I would put the action, recipient, consequence, evidence, and missing fact on one card. I would make the order record and policy available beside the decision.

What must remain bound to the approval?

The displayed recipient, content, scope, and relevant version must belong to the action that executes. A model must not quietly regenerate the reply after approval and keep the old permission.

Orbyt's experimental Command Record specification describes a record with the target, operator, requested change, evidence, and limits on reversal. It gives me a concrete model for what the interface should explain. The specification is not proof.

I would bind the confirmation to the displayed content and recipient. I would also have the executor reject an expired confirmation and recheck the conditions that make the action valid.

If a person approves the revised reply to Maya, the executor should reject a version addressed to Alex. It should not ask a model whether those two messages are close enough. They are different actions. The old approval must fail.

The same check applies when the world changes without a rewrite.

If the recipient changes, approval expires. If a policy change removes authority, the action stops. If another operator already completed the task, the system reconciles that state before attempting a duplicate.

My permissions audit, published August 25, 2026, found 391 allow rules, zero deny rules, and zero ask rules. I had not calculated their combined reach. I had approved individual prompts while trying to finish other work. Each prompt looked local. Together, they left agents with more permission than any one prompt made obvious.

A separate audit of my governance checks found that agents could edit the files that judged their authority. The agent could edit its judge. An approval screen can look governed while the agent has a route around the boundary. I need the executor to enforce scope independently of the screen and of an agent's own description of its limits.

When is a confirmation useful?

More approval screens can bury judgment under interruptions. More clicks are not supervision.

I would keep a confirmation only when the reviewer can make a useful choice.

I would let routine, reversible work within an established policy proceed without another prompt. I would stop for a new recipient, broader permission, external commitment, or uncertain consequence. At that point I would state the specific boundary the action crosses.

Google's People + AI Guidebook (opens in a new tab) treats the balance between automation and user control as a design decision. It recommends allowing people to adjust outputs and retain control where their situation requires it. A reviewer needs an alternative.

If I gave the reviewer no new information and no useful alternative, I would remove the interruption or redesign the control.

This is where taste in AI products becomes operational. I would put the consequence and missing evidence beside the approval button. I would link the order record and policy there. I would give a public commitment more attention than a harmless copy edit.

What should happen after the press?

I would show what happened after the press. Approval, request acceptance, execution, and observed effect are different events. One green check would collapse them into a false account.

The Command Record specification separates those states. A request records intent. An executor can record a commit or acknowledged call. A separate reader must establish the effect before the record earns the corresponding state.

I would write the status to match the evidence.

After sending a pause command, I can say the pause was requested. Requested is not paused. I would claim the seat is paused only when a separate observation supports that statement. If confirmation is unavailable, I would show that uncertainty.

In the fictional support case, an accepted send request would not prove that Maya received the message. Accepted is not delivered. I would show the delivery state I could actually observe. That matters before anyone retries.

The Collective makes this problem easy to see: the human issues a command, while another part of the system must establish its effect. The same design applies to ordinary business software.

How would I test comprehension?

I would test the proposed interface with realistic tasks before optimizing approval speed. I would ask the reviewer what will happen, what remains uncertain, and which action would exceed the permission they are granting.

I would record their answer before execution and compare it with the proposed action. A fast approval with the wrong understanding is a failed review, even if every endpoint returns successfully.

I need two cases. In a safe test environment, I would prepare the fictional reply to Maya, approve it, then change only the recipient to Alex Ruiz before execution. The old confirmation must be refused and no message sent. I would then leave the approved recipient and reply unchanged. That authorized control must be accepted. One must fail. One must pass. I have not run this test or observed either result.

I would also test a delayed result. I would show the existing request so the operator can distinguish waiting from failure before retrying. These are proposed tests; this article reports no participant results.

What to do Next

I would start with one consequential action and write its approval card before touching the layout. I would name the action, target, consequence, missing evidence, and available alternatives in ordinary language.

Then I would trace those promises into execution. I would record what invalidates approval and what observation earns completion. If I could not explain that path, I would not trust a prettier button to fix it.

I would approve the action on the card, not a later action that merely resembles it.

Related reading:

• Human-in-the-Loop Is Not Enough the broader argument for meaningful human control.
• Trust Is the Product trust built from clarity, control and proof.
• Codex Accuses. Claude Convicts. the historical audit that exposed a gap between governance and authority.
• Verification Is the New Literacy how to evaluate evidence instead of accepting a confident result.