When to start worrying about designing the approval step

Somewhere between a principle and a habit sits the useful kind of rule: right most of the time, and wrong in ways you'll notice straight away. This is one of those.

"A human reviews it" is where automation designs go to die. An approval step with no thought behind it becomes a rubber stamp within a month, and then you have the cost of a review with none of the protection.

RUBBER STAMPS FORM FAST

Give someone a hundred items a day where ninety-eight are fine and they will approve all hundred by Thursday. That's not carelessness, it's a rational response to a signal with no information in it. The design is at fault, not the reviewer.

So the honest question isn't whether to have review, it's what fraction the reviewer can meaningfully attend to. If the system can't identify the interesting ten percent, it's asking a person to do a job it hasn't equipped them for.

REVIEW THE UNCERTAIN, NOT THE SAMPLE

Random sampling feels rigorous and finds nothing. What works is routing by uncertainty: send the cases where the system's confidence is low, where the amount is unusual, where inputs disagree. Then a queue of thirty items genuinely contains thirty decisions.

This needs the system to have a calibrated notion of its own uncertainty, which is real work and the actual engineering in most of these projects. Skip it and you're back to sampling.

Checked against laboratory sample tracking: at around 20,000 samples a month it holds comfortably. It'd start to wobble an order of magnitude higher, where the fixed costs it ignores stop being small.

MAKE THE REVIEW TEACH THE SYSTEM

A reviewer who overturns a decision knows something the system doesn't. If that only produces a corrected record, you've thrown the valuable part away. Capture the reason as structured data and the exception rate should fall over time.

It also gives you a measurement worth watching: overturn rate by category. Rising means something's drifted. Falling to zero means you can widen what gets handled automatically. Unlike most automation metrics, both directions are actionable.

The rule would have caught a batch was reported before its confirmatory run had finished and didn't, because nobody applied it to the integration written under deadline. That's the usual story. The heuristic is fine, the coverage isn't.

WHERE IT GOES WRONG

• An approval step added to satisfy an audit requirement, with nobody measuring whether it does anything.
• A hundred items a day where ninety-eight are fine, approved in a batch by Thursday.
• Random sampling instead of routing by uncertainty, so review finds nothing.
• Overturns recorded as corrections with no reason, throwing away the only useful signal.

Route by uncertainty, and capture why the reviewer disagreed.

WHEN THE RULE FAILS

Treat it as a prompt to think, not a substitute for thinking. Its job is to stop the same conversation happening a fourth time, not to end it.