Human review

Give human review a real decision.

Design review points that show the proposed action, relevant evidence and the authority required to proceed.

Explore the playbookDownload PDF
On this page

Review checkpoint

  1. 1

    Proposal

    The exact action and affected record

  2. 2

    Evidence

    Source context and validation findings

  3. 3

    Choice

    Approve, reject or request clarification

  4. 4

    Record

    The decision, actor and version reviewed

Avoid approval without context

A button labelled Approve is not a meaningful control if the reviewer cannot see what will change or why the system proposed it.

Invalidate stale approvals

If the underlying record or proposed action changes, the previous decision may no longer apply. Bind approval to the version actually reviewed.

Give reviewers the evidence they need

Human review is useful when a person can understand and change the proposed outcome. Present the source material, extracted values or proposed tool action alongside the relevant business rule. Highlight uncertain or conflicting information. Avoid making a reviewer navigate through several systems to reconstruct the context the automated process already had.

For a supplier invoice, show the document, supplier identity, line items, totals and any mismatch with a purchase order. Distinguish values read from the document from values inferred or corrected by the system. The reviewer should know exactly which result they are approving, and whether their decision will create a draft, update a record or release a payment instruction.

Bind approval to the actual proposal

Store a stable reference to the version under review. If the target record, amount or action changes after approval, decide whether approval remains valid. For consequential changes it will commonly need to be requested again. Enforce this rule in application logic rather than relying on an instruction in a model prompt.

Provide separate paths for approval, correction, rejection and escalation. A reviewer who cannot resolve an ambiguity should not have to approve it merely to clear a queue. Consider delegation, absence and workload so that the review process remains practical. Record the decision and necessary context without retaining unnecessary personal or confidential information in an unrestricted log.

Measure the quality of the review process

Observe how often reviewers correct proposals, what they change and which cases take longest. A high approval rate does not by itself prove that the system is accurate. Reviewers may be under time pressure or unable to see the evidence needed to detect an error.

Sample completed work with an appropriate subject-matter reviewer and compare decisions against the original material. Feed recurring issues into the extraction rules, evaluation set or interface design. Agree how a mistaken approval can be corrected and which downstream systems need reconciliation. Human review should form a usable part of the workflow, with an owner and recovery path, rather than serve as a reassuring label on an otherwise unattended process.

Use the agreed risk and validation rules to decide which items need review. Keep uncertain and consequential cases visible instead of overwhelming the queue with low-value approvals.