“A human approval button is not automatically human oversight.”
The human approval button that verified nothing
Early in the design of my trading system, I treated human approval as the primary safety boundary.
The workflow seemed reasonable:
  1. The system analyzes an opportunity.
  2. It creates a recommendation.
  3. The recommendation is shown to the operator.
  4. The operator approves or rejects it.
  5. Nothing proceeds without approval.
Human in the loop. Problem solved.
Except it wasn’t.
If the operator receives only a confident recommendation and an approval button, what exactly are they verifying?
If they cannot see the supporting evidence, contradictory evidence, data freshness, risk calculation, invalidation condition, and unresolved uncertainty, then approval may be little more than trusting the system and clicking “yes.”
The human is present, but no independent judgment is taking place.
That led me to separate three ideas I had previously treated as interchangeable:
  • Human in the loop: A person must perform an action before the workflow continues.
  • Human on the loop: A person monitors the system and can intervene.
  • Human verification: A person receives enough evidence and authority to independently evaluate the proposed action.
Only the third one creates a meaningful approval boundary.
For a human approval request to be useful, I now believe it should answer several questions clearly:
  • What action is being proposed?
  • Why is it being proposed now?
  • What evidence supports it?
  • What evidence contradicts it?
  • What remains unknown?
  • How current is the information?
  • What risk is being accepted?
  • What would invalidate the decision?
  • What happens if no action is taken?
  • What authority does approval actually grant?
The approval itself also needs boundaries.
An approval should be:
  • Tied to one specific decision
  • Based on a recorded input snapshot
  • Limited to a defined action
  • Time-bound
  • Invalidated when material conditions change
  • Single-use where appropriate
  • Recorded with the eventual outcome
Otherwise, someone could approve one set of circumstances while the system acts later under materially different conditions.
Another important separation is that human approval should not override deterministic safety controls.
If the proposed action violates a hard risk limit, uses stale data, exceeds permitted exposure, or depends on an unknown position state, clicking “Approve” should not make it valid.
The human may authorize an eligible action, but they should not be able to convert an ineligible action into an eligible one accidentally.
This changed how I think about supervised agents.
The goal isn’t simply to keep a person somewhere in the workflow. The goal is to create a point where the system presents a decision in a form that allows the person to understand it, challenge it, and knowingly accept or reject its consequences.
A button confirms that someone clicked.
Evidence-backed approval confirms that someone had a genuine opportunity to decide.
How are others making sure the human step in their workflow is actual verification rather than a rubber stamp?
0
4 comments
Joseph Manion
2
“A human approval button is not automatically human oversight.”
ZeroOne Systems
skool.com/zero-one
ZeroOne helps you build world class AI agents that make meaningful change to your life.
Leaderboard (30-day)
Powered by