Control design note · 2026
A Human Clicked Approve. Was the Decision Actually Reviewed?
The button records human presence. Control begins where disagreement can change the outcome.
- Reading time
- 3 minutes
- Published through
- Astana Hub
- Topic
- AI Governance and IP
About this edition. Originally published in Russian on Astana Hub. This English edition keeps the controlled-case test and the distinction between human presence and effective intervention.
Imagine Friday at 17:40. An AI agent has prepared a pull request with several hundred lines. The tests are green. Its description says "low risk", and the description was also written by the agent. The release window closes in twenty minutes.
A reviewer scans the change and clicks Approve. On Monday, the team finds an error. The log looks complete: review assigned, human confirmation recorded, timestamp present.
The log does not tell us whether the reviewer could see the material error, had enough information and time or whether Reject would actually have stopped the release.
Approve records an event, not the quality of review
The same approval record can describe very different processes. One reviewer compared the output with an independent source. Another saw only an AI-generated summary. A third had doubts but faced a deadline and a rejection route designed to create friction.
Approve confirms that the route reached a person. The quality of control appears in the person's ability to disagree.
This is not about blaming the reviewer. A person cannot make a substantive decision without the necessary context, time, competence and authority.
Give the reviewer an independent point of reference
Review always involves comparison: a calculation against its inputs and rule, a document conclusion against the document, a code change against requirements, architecture and tests.
If the person sees only the AI recommendation, confidence score and explanation produced by the same system, the interface may not contain enough information to identify a material deviation.
The reviewer does not need every internal model detail. They need the evidence that matters for the known failure mode of this task.
Design disagreement as carefully as approval
Interfaces set the price of each action. A green signal appears before the source facts. Approve takes one click. Reject opens four mandatory fields. The queue is measured by speed, but investigation time is invisible.
A real right to disagree includes access to relevant data, a clear criterion, time, competence, the ability to request more information, edit the output, escalate the case and stop the next action.
If the workflow continues automatically, Reject is an interface element, not a control.
Run a case that cannot be approved
Use a safe historical or synthetic case with a known material defect. Put it through the ordinary interface, instructions, time pressure and authority structure.
- Did the reviewer see the defect?
- Could they confirm it against an independent source?
- What happened after Reject?
- Did the next action stop?
If the defect was not visible, examine information design, criteria, preparation and workload. If it was visible but could not change the result, examine authority and escalation. If Reject was recorded and the action still happened, the sequence itself is broken.
This is a test of the system, not a hidden test of employee loyalty.
Keep evidence of intervention, not only attendance
For a consequential decision, the useful trace includes the version of the output and source data, the evidence available to the person, changes to the recommendation, additional information requested, escalation and the final effect on the workflow.
A high approval rate does not prove that review is decorative. If people never change a result, stop an action or escalate a case, it is a good reason to test the disagreement path.
The first question for any Approve button is therefore simple: what happens after Reject?