The reviewer is a role, not a step

Tags: human in the loop, review, accountability

A confirmation moment assumes one action, one human, one decision. That holds at ten actions a day. At ten thousand the human becomes a rubber stamp — which is worse than no review, because it manufactures the appearance of oversight while producing none.

What a moment cannot hold

The problem is not that these patterns are wrong. At low volume they are exactly right, and undo over confirm already names the cases where a confirmation still wins: rare, consequential, irreversible.

The problem is that a dialog holds no state. Which means there are four questions it structurally cannot answer, and they are the four questions anyone operating at volume needs answered:

• What is pending? A moment happens or it doesn't. There is no queue, so there is no backlog, and therefore no way to see that review is falling behind.
• Who owns this one? "Someone will check it" is not an assignment. Work nobody is named on is work nobody does.
• What did we approve last month? A dismissed dialog leaves nothing. The audit trail has to be reconstructed from logs, if it exists at all.
• Who signed off on the thing that went wrong? This is the question that gets asked eventually, and a product that cannot answer it has no oversight regardless of how many dialogs it showed.

Review as a state on the object

The alternative is old, well-understood, and sitting in plain sight outside AI entirely.

Make review a state the object carries, with a named owner at each stage and an explicit transition between them. Not a gate in a flow — a property of the thing, which moves from prepared to approved to reviewed, each step attributed.

What that buys, in order of how much it matters:

1. A queue, which means work can be distributed, prioritised, and seen to be accumulating.
2. A name on every transition, which turns "the system approved it" into something accountable.
3. A history as a by-product. The audit trail is not a feature you build; it is what the state machine leaves behind.
4. An honest sampling policy. This is the one people resist and it is the most important.

Sampling is the honest version

At volume, a hundred-percent review policy is a fiction, and everyone involved knows it. The reviewers know, their manager knows, and the policy document says otherwise.

A role-based model lets you write down what you are actually going to do: everything above a threshold gets reviewed, a defined sample of the rest gets reviewed, and the sample rate is a number someone owns and can raise when the error rate moves. That is weaker than reviewing everything and infinitely stronger than pretending to, because it is true, it is measurable, and it produces data about the unreviewed population rather than silence.

A dialog on every action cannot express this. It offers one policy — review everything — and the way it fails is that people click through it, which looks identical to compliance.

When the moment is right after all

The bottom-left branch is worth stating plainly: do not build this for low volume. A three-stage certification workflow over four approvals a week is ceremony, and ceremony is its own failure mode.

The input branch is the one most often skipped. A reviewer shown a generated paragraph and asked to approve it, without the source it was generated from, is not reviewing — they are proofreading. That is a different and much weaker activity, and it is what most AI review queues actually are.

Grounded in

BlackLine, where reconciliations carry preparer, approver and reviewer as certification states rather than as steps somebody walks through. The dashboard is organised around what is due, overdue and in progress, with those states visible per item.

Enterprise accounting arrived here because it had no choice. The volume forced it decades ago, the consequences are regulatory, and the result is a model that has been tested against adversarial conditions — auditors, restatements, people with an incentive to find the gap — for longer than most AI products have existed.

That is the transfer worth making. AI products are arriving at enterprise volume carrying consumer-grade oversight patterns, and the infrastructure for the problem they are about to have is already built, documented, and running in every finance department. It is not novel. It just has not been looked at, because it does not look like AI.

Anti-patterns

• A dialog as the oversight design at volume. Produces clicking, records nothing, and reads as governance in a deck.
• Review with no named owner. Unassigned work is unperformed work, and the absence is invisible until something goes wrong.
• No record of who approved what. The question arrives eventually and this is the only form in which it can be answered.
• A hundred-percent policy nobody follows. Worse than a sampling policy, because it forecloses measuring the part that is not being read.
• Approval that does not travel with the artifact. The state lives in your database and the document goes into an email. Provenance has to survive the export.
• Reviewing output without its input. Proofreading dressed as oversight.
• Approval as a single bit. Approved-by-whom, when, and having seen what, are all part of the claim. One boolean throws away the parts that matter later.

The smallest version worth building

Two states and a name: needs review, reviewed-by. On the object, not in a dialog. Plus a list view of everything in the first state.

That is a queue, an assignment and an audit trail, and it is perhaps a day of work. Add the sampling threshold when the queue is longer than the people, which will be sooner than anyone plans for.

Related patterns

• Undo over confirm — the low-volume half of the same question, and where a confirmation moment is still the right answer.
• Work without being asked — unprompted work is what drives the volume that breaks the moment.
• Pair every insight with its action — a reviewer's queue is the clearest case of an observation that has to arrive with something to do about it.