Human Approval Is a Product, Not a Button

AI approval requires evidence, consequence previews, bounded authority, and durable receipts to be meaningful.

Most human-in-the-loop AI designs transfer responsibility to a person without giving them enough information to exercise it.

The system produces a recommendation. The interface adds Approve and Reject. A human clicks one. The audit log records that a human was involved.

That is procedural compliance masquerading as control.

I call the product around a consequential decision the Approval Surface. It combines the proposed action, supporting evidence, uncertainty, scope, consequence preview, alternatives and a durable record of what the person actually authorized.

Approval is meaningful only when the reviewer can understand and bound the consequence.

A button answers the least important question

An Approve button answers: “Did somebody click?”

The responsible person needs answers to a longer set of questions:

• What does the system believe happened?
• Which source supports that belief?
• What evidence is missing or contradictory?
• What exact action will occur?
• Which records, people or systems will it affect?
• Can I edit the proposal instead of accepting it wholesale?
• Can I preview the result without performing it?
• Can the action be reversed?

If those answers live across logs, dashboards and internal tools, the reviewer is approving under uncertainty created by the product itself.

The interface should reduce that uncertainty before it asks for authority.

The Approval Surface is the complete path. The button is one control inside it.

Review and approval are different jobs

A person may agree that a model interpreted the evidence correctly and still reject the proposed action. They may also disagree with the interpretation while choosing a conservative action for another reason.

Combining those decisions into one click destroys useful information.

Decision	What the person is deciding
Evidence review	Is the cited material present and relevant?
Interpretation review	Does the claim stay within the evidence?
Action approval	Is this consequence appropriate now?
Execution review	Did the approved action occur as specified?

This separation matters for learning. If the system only records “Rejected,” it cannot tell whether the source was weak, the interpretation was wrong, the timing was bad or the action exceeded policy.

A well-designed approval flow generates training signal without making the reviewer label data for the sake of the model. The person’s ordinary work creates the useful distinctions.

High confidence does not grant authority

Confidence estimates quality. Authority defines permission. They are not interchangeable.

A system may be highly confident that an invoice is overdue. That does not authorize it to contact the customer. It may correctly identify a commitment in a meeting. That does not authorize it to create work under somebody’s name. It may find a relevant public conversation. That does not authorize it to post a reply.

The action boundary should be expressed as product policy:

Risk	Default behaviour
Read and summarize	Automatic when source access is permitted
Store a derived claim	Labelled and reviewable
Change an internal record	Preview plus scoped approval
Communicate externally	Explicit recipient and final-content approval
Spend money or delete data	Separate authority, limits and recovery plan

OpenAI’s practical agent guidance recommends human intervention for high-risk actions and repeated failures. The guidance is sound. The harder work is deciding what the reviewer sees and what the approval actually binds.

Repeated approvals create approval debt

Every request consumes attention. When a product asks a person to approve routine, low-information decisions, it trains them to treat the control as ceremony. The apparent safety mechanism gets weaker with use.

Approval debt accumulates in three ways: the system asks too often, the reviewer cannot distinguish high-risk requests from ordinary ones, or previous decisions do not become policy for later proposals. A mature Approval Surface should learn the boundary without silently expanding it. It can automate repeated low-risk cases inside an explicit rule, while routing novel targets, larger consequences and weak evidence back to a person.

The aim is not maximum human involvement. It is concentrated human judgment at the moments where authority or uncertainty materially changes.

Dry runs turn abstract risk into a visible consequence

“Approve this integration” is vague. “Send these three messages to these recipients, using this content, and write these fields if delivery succeeds” is reviewable.

Dry runs are one of the highest-value patterns in applied AI. They let the system complete planning, resolution and validation while stopping before external change. The person reviews a concrete consequence rather than an intention.

We use this pattern across very different work: source configuration before paid provider use, content before external publication, transcript recovery before canonical replacement, and operational alerts before they leave the product.

The underlying action may be deterministic. AI still shapes which action is proposed, which target is selected or which evidence is considered relevant. The preview must expose those choices.

Approval must bind to an exact proposal

An approval becomes meaningless if the system can change material details after the click.

The receipt should bind at least:

• the proposal identity and version;
• the evidence available at decision time;
• the permitted target and scope;
• relevant limits such as cost, duration or count;
• the approving person and time;
• the result and any partial failure;
• whether cleanup or reversal completed.

This is the same discipline applied by the Release Proof Ladder: proof belongs to one exact candidate. An edited message, changed target or larger batch is a new proposal and needs a new decision.

The principle also shaped Elsewhere, an open-source workload router I built for agent, test and build work. Remote execution stays dry until explicitly executed, and the approval receipt binds providers, regions, source boundaries and resource limits. The public repository documents the boundary and its current limitations.

The point is not the command-line implementation. It is that “the user approved cloud execution” is too broad to be safe or useful. The user approved this work, from this source, within these limits, on these destinations.

A refusal needs a usable next move

Fail-closed systems can become unusable if every uncertainty produces a dead end.

An Approval Surface should explain why progress stopped and offer a bounded next move: inspect the missing source, narrow the action, correct the target, request different authority or save the proposal for later. The product remains helpful without manufacturing permission.

This is where the Evidence Layer and approval meet. Evidence tells the reviewer what is known. The Approval Surface lets them decide what consequence that knowledge supports.

What I got wrong

I used to think human review was a temporary stage on the way to higher autonomy. As the model improved, the review rate would fall and the interface could eventually disappear.

Some review should fall. The Approval Surface remains because capability and authority solve different problems. A perfect prediction does not decide whether now is the right moment to act, whether the organization accepts the consequence or whether this person is allowed to authorize it.

The unresolved design question is attention. Approval quality collapses when people receive too many requests and learn to click through them. How should an AI product ration human authority so that the rare request still receives an actual decision?