Human review is not a failure mode

Human review is often described as a temporary compromise: something the team will remove once the model is good enough. That framing leads to bad systems. In many workflows, review is the mechanism that makes AI useful, accountable, and capable of improving.

So skip "Can we eliminate humans?" and ask a better design question: which decisions justify human judgement, what evidence does the reviewer need, and how can the system make that review efficient?

Review is a workflow stage

"Have someone check it" is not a review design. A real review stage has an owner, entry conditions, criteria, possible decisions, and a recorded outcome.

Define:

• what is being reviewed;
• why it requires review;
• who is qualified to decide;
• what evidence appears beside the output;
• which criteria determine approval;
• what happens after approve, revise, reject, or escalate;
• how the decision is recorded for future runs.

Match the gate to downside and reversibility

Not every output needs the same scrutiny. Classify the workflow along two dimensions: potential downside and ease of reversal.

Risk is contextual. A social caption may be low-risk for one brand and regulated communication for another. The workflow owner must define the actual downside rather than copy a generic policy.

Put review at decision boundaries

Review is most valuable where the system crosses a meaningful boundary: from research to claim, draft to publication, recommendation to commitment, or internal record to external action.

Adding a checkpoint after every model call creates delay without improving control. Reviewing only the final output may be too late if an early source-selection error shaped everything that followed.

For a research-backed article, one gate may approve the evidence set before drafting and another may approve the final public claims. For customer support, the system may classify and draft freely but pause before sending a refund promise.

Specify each gate

For every step in the workflow, answer five questions:

• What is the downside if this step is wrong?
• Is the output reversible?
• Does it touch policy, money, reputation, legal risk or customer trust?
• What must a human check before the output moves on?
• Can review happen by exception rather than on every case?

Where the answers call for a gate, write down five things before launch:

1. The gate: the exact point in the workflow where work stops.
2. The reviewer: a named role, not "the team".
3. The criteria: what the reviewer checks.
4. The pass/fail rule: what is enough to approve, and what forces a revision.
5. The escalation path: who decides when the reviewer cannot.

Build a review packet, not a scavenger hunt

The reviewer should not need to open five systems to understand the proposal. Put the relevant material together:

1. The proposed output or action.
2. The original request.
3. Source evidence and timestamps.
4. Assumptions and missing context.
5. Validation results.
6. Confidence or routing reason, when meaningful.
7. The exact consequence of approval.

Do not show a confidence score without explaining what it represents. Model confidence is not a universal probability of correctness. A routing reason such as "sent to review because the account tier is missing" is often more useful than 72%.

Give reviewers a small decision set

An unstructured comment box makes later analysis difficult. Use a small set of outcomes:

• Approve: the output can move to the next stage.
• Revise: return it with a specific correction.
• Reject: the method or result is unsuitable.
• Escalate: a different role must decide.

Allow comments, but also capture a reason code such as missing evidence, policy conflict, wrong tone, factual error, or insufficient context. These labels reveal patterns across runs.

If the work comes from a Playbook, you already have a starting list. Its rubric items ("Grounded", "Clear uncertainty", "No unsupported claims") are the criteria the output was meant to meet, so a failed rubric item makes a precise reason code. It also tells you where to fix things: a run of "No unsupported claims" failures points at the Playbook's instruction or its Knowledge, not at the reviewer.

From the Library · PlaybookSupport TriageTriage one support ticket: category, P1 to P4 priority, a reply, clarify or escalate route, a safe draft reply and an internal note, all from your own policy.→

Use exception-based review carefully

The long-term goal is often to focus human attention where it has the highest value. Rules can route routine, low-risk cases through a lighter path while surfacing ambiguous or consequential cases.

A support workflow might require review when:

• the customer asks for money, cancellation, or legal escalation;
• account data is missing or contradictory;
• the draft cites a policy with low retrieval confidence;
• sentiment suggests reputational risk;
• the proposed response includes a commitment not present in approved policy.

High-confidence routine questions may then receive sampled review instead of universal review. Sampling should remain in place to detect drift and unknown failure modes.

A concrete failure case

Take an AI workflow that drafts partnership outreach. Reviewers approve each message by reading only the polished draft. One message claims the prospect recently launched a feature, but the source article describes a different company with a similar name.

The reviewer technically existed, yet the control failed. The system did not show the source, entity match, or age of the evidence. The review interface rewarded fluency rather than verification.

Telling reviewers to be more careful will not fix this. The review packet should pair every personalised claim with its source and surface ambiguous entity matches before drafting.

Measure review as part of system performance

Track more than approval rate. For a small team, four measures are enough:

• percentage approved without change;
• revisions by reason code;
• false approvals found later;
• median review time.

A very high approval rate can mean the system is good, or that reviewers are rubber-stamping. Audit samples after approval to tell the difference.

Review time also matters. If reviewers repeatedly reconstruct missing context, improve the packet. If they make the same edit, encode the rule or example. Human effort should teach the system, not vanish into an inbox.

Know when not to reduce review

Do not remove a gate just because recent outputs look good. Ask whether the sample represents real variation, whether the failure cost is acceptable, and whether monitoring can detect regression quickly.

Keep explicit approval for actions involving money, legal commitments, access permissions, irreversible publication, sensitive personal data, or material customer promises unless an accountable owner has approved a different control model.

The review design checklist

Before launching an AI-assisted workflow, confirm that:

• the risk and reversibility of each output are understood;
• review sits at meaningful decision boundaries;
• each gate has an accountable owner, criteria, a pass/fail rule and an escalation path;
• reviewers receive source evidence and missing-context signals;
• approve, revise, reject, and escalate paths are defined;
• reasons are recorded in a reusable form;
• low-risk automation still has monitoring or sampling;
• reviewer corrections feed prompt, context, or method improvements;
• removal of a gate requires evidence, not optimism.

Done well, review concentrates judgement where it counts, limits the downside, and builds the evidence a workflow needs before it is trusted with more.