Human-in-the-Loop Design Decision

“Human in the loop” is not a control. It is a slot where a control might go. Whether anything actually gets caught there depends on a question that rarely survives the design review: what can this specific person detect, on this specific screen, in the time they will really have?

This framework makes you answer that before you pick a position for the human. It is four questions and a routing table, and it is deliberately short.

Why this exists

The default design is “a person reviews everything.” It feels safe and it degrades on a schedule.

Here is the mechanism. A reviewer starts out reading carefully. The model is right most of the time, so their prior shifts. By the third week the review is a keystroke — and the approval is still real. It is signed, timestamped, and admissible. The reading behind it is not.

You can measure this, which is the whole point. Track the edit rate: the share of items the reviewer changed, not the share they approved. If reviewers are changing fewer than one item in twenty, that gate is no longer a control. It is latency with a signature on it. Either the model is now good enough to sample instead of gate, or the reviewer cannot see the errors that remain — and those two have opposite fixes.

The second failure is quieter. A reviewer who sees items one at a time cannot detect a systematic error. A bias that tilts every output the same direction looks defensible in each individual case, because each case is individually defensible. Only side-by-side review catches it, and one-at-a-time is what every review queue ships with by default.

How to use it

Answer these four before anybody draws the workflow.

1. Detectability. Could the reviewer tell a correct output from a wrong one using only what is on the screen? If they would have to open another system to know, the review is theater. Fix the screen, or move the human somewhere they can be useful.
2. Reversibility. How long is the window in which this action can be undone cheaply, and who can undo it? Reversibility, not severity, decides whether you need a gate at all.
3. Volume. Items per day per reviewer. Past a few dozen a day, careful reading is not something you can design around, and you should be sampling.
4. Why the human is there. Sometimes the review exists to place accountability rather than to improve accuracy. That is a legitimate reason. Say it out loud, so nobody designs for quality and ships a signature.

Then pick a position. The human can go before (person authors, model drafts), after (model acts, person reviews a sample), or beside (model handles the clear cases and routes exceptions to a person). Gating every item is the fourth option, and it is the one that has to be justified rather than assumed.

Instrument whichever you choose on day one: edit rate, median time to decision, and the share of reviewer changes that were later reverted. That third number is the one nobody collects, and it is the only one that tells you when the human has become the less accurate party.

Where it goes wrong

A loop does not make a system accurate. It caps one class of error at the reviewer’s own detection rate for that class, and it does nothing whatsoever for errors they cannot see. When someone tells you human review handles the risk of fabricated output, ask them how the reviewer would know. If the answer requires checking a source the reviewer never opens, the risk is unmitigated and the design is claiming otherwise.

Do not use this where the reviewer lacks the domain to judge. A person who cannot evaluate the output will approve it, and you have added delay plus a false record of oversight. That is worse than no review, because the record gets believed.

And do not treat a sample as a gate. Sampling measures an error rate; it does not stop the individual bad item. If one bad item is genuinely unacceptable, sample nothing, and spend the budget on detectability instead.