Govern the loop
A human clicking approve at the end of a pipeline is a signature, not oversight. If you want the review to be real, almost all of the work happens before anything runs. This is the version I keep.
Before you build it
Four decisions and a habit
None of these are features. None of them demo well. They are closer to how you would run a room than how you would build a product, which is exactly why they get skipped.
-
Write down what the system may decide alone
Put the boundary somewhere people can argue with it. An unwritten boundary is not a boundary, it is whatever the model did last week.
Test: can somebody who was not in the room read the line and tell you which side a given case falls on?
-
Decide what evidence ships next to an answer
A reviewer looking at output alone is guessing. A reviewer looking at the reasoning, the inputs, and the confidence is reviewing. The difference is what you chose to display.
Test: can the reviewer say why it decided that, without opening another system?
-
Define the escalation, then make it cheaper than approving
Most review tools do the opposite. Approve is one click and flagging means writing a paragraph to somebody who will be annoyed by it. You can predict the outcome from the size of the buttons.
Test: count the clicks and the keystrokes on each path. If approve is cheaper, you have built a rubber stamp.
-
Do not measure the reviewer on throughput
Whatever you measure is the behaviour you will get. Measure a human on how fast they clear a queue and the fastest path through their day is yes. That is not a character flaw, that is the design working as built.
Test: look at the time stamps. If the median review is a handful of seconds, nobody is reviewing anything.
-
The habit: sample what nobody escalated
Read a random slice of the approvals nobody questioned, on a schedule, forever. Every other check looks at the cases somebody already flagged. This is the only one that can find the blind spot, because a blind spot is by definition in the pile nobody looked at twice.
Test: is it on a calendar with a name against it? If not, it will not happen.
Written by Jason Penrod, 2026. I figure out what to build first, then build it. More of these are at jpcreativesolutions.com/notes, and the work itself is at jpcreativesolutions.com.