Where human review belongs in an AI production workflow

Human review works when a person can make a specific decision. A queue of generated answers with an “approve” button is not enough if the reviewer cannot see the sources, the requested effect, or the conditions for rejection.

Take a fictional assistant drafting a customer-facing incident update. It may summarize verified incident notes. It may not invent a recovery time, claim a root cause without evidence, or send the update merely because its prose sounds polished.

Separate mechanical checks from judgment

Shape checks can verify that a draft contains required sections and stays within a length limit. They cannot establish that the stated cause is true. Give the reviewer the incident record, the candidate revision, and the material claims requiring support.

Visual field note / V17

Generation is one step

Read the diagram as text

Flow from bounded input and sources, then generate a candidate, then check shape and constraints, then human reviews material claims, then accept or return specific defects, then publish approved revision, then observe correction requests. Generation produces a candidate. Checks and human review decide whether that exact revision is ready to publish.

Open full-size SVG ↗Download PNG ↓

The action boundary matters. Generating text is reversible. Publishing it creates an external commitment. Keep that effect separate so approval applies to the exact reviewed version and destination. If the draft changes after approval, the approval should not silently cover the new material.

Use a concrete rejection rubric

For the incident example, reject unsupported cause statements, unexplained technical terms, and promises the owner has not accepted. Return a specific defect: “The notes establish elevated errors, but not data loss; remove the data-loss claim.” That instruction is more useful than “make it safer.”

Visual field note / V18

The review rubric

Read the diagram as text

Shape / can it be consumed?: Accept expected fields and types. Reject missing required structure.; Material / is it supported?: Accept source-backed claims. Reject invented evidence or history.; Use / does it help?: Accept clear actionable output. Return ambiguity for revision. Review structure, evidentiary support, and usefulness separately; return unsupported or ambiguous output for revision.

Open full-size SVG ↗Download PNG ↓

A reviewer should be able to abstain. Missing evidence is a state to resolve, not a pressure to approve the least-bad guess. Route unanswered questions to an accountable owner, and show that the workflow is waiting for evidence.

Keep the review proportionate to the effect

Requiring a person to approve every formatting correction creates fatigue. Allow deterministic, bounded changes where mistakes are cheap to recover. Reserve judgment for claims, access, irreversible changes, and external commitments that need authority.

Review volume can itself reveal a design problem. Repeatedly rejecting the same invented field suggests the generation boundary or input contract needs improvement. Recording a rejection category helps investigate that pattern; it does not justify inventing a model accuracy score from a handful of examples.

Before release, rehearse one acceptable draft, one unsupported claim, one missing-source case, and one candidate changed after approval. Verify that only the approved revision can reach the authorized publishing step. Test those effects with a fake publisher so the rehearsal sends nothing to real customers.

This is a reference workflow, not a report of measured review performance. Pair it with coding agent boundaries and the systems guide. If you want help designing useful approval points without creating a bottleneck, start a leadership conversation.