D5 · Review Points and Human Oversight

This domain is worth 16% of the mock — roughly 8 of 50 items. It tests where a human belongs in an otherwise automated workflow: not everywhere (that destroys the value) and not nowhere (that courts disaster), but at the points where a mistake would be expensive or irreversible. The recurring judgment is placement — putting the gate at the risky step, and choosing between gating every item and sampling a stream of them.

What you need to know

Human oversight in a workflow means deciding where a person inspects or approves output, when review is mandatory versus optional, and how review scales when volume is high. A mandatory review trigger is any point where an error would be irreversible, regulated, external-facing, or touch sensitive data — those steps require a human gate regardless of how good the output looks. For high-volume work, gating every item is impractical, so you sample: review a representative fraction, track the error rate, and tighten sampling if quality drifts. A misplaced gate is costly in both directions — a gate on a trivial high-volume step throttles throughput for no benefit, while a missing gate on a risky step lets an expensive mistake through.

Learning objectives

By the end of this page you should be able to:

1. Identify mandatory review triggers — irreversible, regulated, external, sensitive — in a workflow.
2. Place a review gate at the step where a mistake is most expensive, not by default everywhere.
3. Design sampling-based review for high-volume work and decide the sampling rate.
4. Diagnose the cost of a misplaced gate — both the throttling gate and the missing gate.
5. Choose the review mode — gate, sample, or spot-check — that matches the step’s stakes and volume.

5.1 The three review modes

GATE       every item is reviewed/approved before it proceeds
           ▸ use for irreversible / regulated / external / sensitive steps

SAMPLE     a representative fraction is reviewed; error rate is tracked
           ▸ use for high-volume, correctable, lower-consequence steps

SPOT-CHECK an occasional glance to confirm nothing has drifted
           ▸ use for low-stakes, stable, low-volume steps

The art is matching the mode to the step: a gate where a mistake is expensive, a sample where volume is high and mistakes are correctable, a spot-check where little is at stake.

5.2 Mandatory review triggers

Some steps require a human gate no matter how confident or fluent the output. The triggers are the same ones that drove the risk axis in Domain 1.

If any trigger is present at a step, that step gets a gate. Fluency, speed and high aggregate accuracy do not exempt it — a 98%-accurate model still needs a human before an irreversible regulated action.

5.3 Placement — the gate goes at the risky step

Oversight is about where, not whether. The gate belongs immediately before the risky action, so the human reviews exactly what will go out.

Draft reply ─► [review inside chat] ─► SEND   ← gate goes HERE, before send
                                       (irreversible/external)

Extract records ─► categorise ─► [sample check] ─► write to CRM
                                  ↑ sampling, not a gate on every record

Placing the gate too early (reviewing a draft that will change before the risky step) wastes the review; placing it too late (after the irreversible action) is no gate at all. The reviewer should see the final artefact at the last reversible moment.

5.4 Sampling-based review for volume work

When a step runs hundreds or thousands of times, gating every item is impossible without erasing the value. Sampling reviews a representative fraction and uses the observed error rate to manage risk.

Worked example. A workflow categorises 800 receipts a week. Gating all 800 defeats the purpose. Instead: sample 5%, oversample receipts above a value threshold, review at week’s end against acceptance criteria, and if the error rate on the sample exceeds the tolerance, raise the rate or gate the high-value slice. This is exactly the “automate categorisation, sample at reconciliation” pattern from Domain 1’s scenario.

5.5 The cost of a misplaced gate

A gate is a cost as well as a control. Misplacing it hurts in one of two directions.

The lesson: more review is not safer if it is in the wrong place. A single well-placed gate before the irreversible step plus sampling on the volume steps beats a blanket gate on everything.

5.6 Review fatigue and rubber-stamping

A gate only works if the reviewer actually reviews. Two failure modes erode gates over time.

The design goal is few, meaningful gates the reviewer takes seriously — which is why over-gating (5.5) is self-defeating: it manufactures the fatigue that makes gates fail.

5.7 Oversight and the contract

Review checks output against something. That something is the acceptance criteria from Domain 3. A gate without criteria is a reviewer guessing; a gate with criteria is an objective check (“every question answered; no unverified account claim; figures reconcile”). Well-written contracts make oversight cheap and consistent; missing criteria make every review subjective and slow.

Decision framework

The GATE decision — for each step, answer these to choose the review mode.

Read it as: grave steps are gated; high-volume correctable steps are sampled; stable low-stakes steps are spot-checked; and you tighten wherever evidence shows drift. Placement is always immediately before the risky action.

Common mistakes

Scenario challenge

Scenario. Aisha runs a workflow that handles inbound support at scale: it classifies each ticket, drafts a first reply, and — for a set of “simple” categories (password resets, shipping-status questions) — it can send automatically. For everything else it drafts and a human sends. Volume is ~2,000 tickets/day. Two incidents just happened. First, an auto-sent “shipping status” reply gave a customer a wrong delivery date pulled from a stale field, and it went out with no human check. Second, the team, alarmed, now wants a human to approve every reply — all 2,000/day — which would require doubling headcount and would still leave reviewers skimming. Aisha must redesign the oversight.

Expert reasoning trace.

1. Locate the two failures precisely. Incident one is a missing gate on an external-facing, irreversible action (a sent email) whose content depended on possibly-stale data — a mandatory-trigger step that had no gate. Incident two is the over-correction toward a throttling gate on all 2,000 items, which will manufacture rubber-stamping and destroy the throughput the automation exists to provide.
2. Apply the mandatory-trigger test. Sending an external reply is irreversible and external — a review trigger. But that does not mean gating all 2,000: it means the auto-send path must be reconsidered, because auto-send removed the human from an irreversible external step entirely.
3. Separate the risky slice from the safe stream. The problem is not the whole stream; it is that “shipping status” replies depend on live data that can be stale. So: keep auto-send only for categories whose replies are self-contained and low-consequence (a password-reset link is stable), and for any reply that quotes data that could be stale or wrong (delivery dates, balances), route to a human gate or verify the data before sending.
4. Reject the blanket gate. Gating all 2,000 is the throttling-gate anti-pattern: it doubles cost, invites rubber-stamping (which would have missed the stale date anyway if the reviewer skims), and punishes the 90% of safe tickets. More review in the wrong place is not safer.
5. Design sampling for the auto-send stream. For the categories that stay auto-send, add sampling: review a fraction daily, oversample any reply that pulled dynamic data, track the error rate, and tighten (or pull a category back to human-send) if drift appears. During this redesign — a new process — start with heavy sampling and relax on evidence.
6. Wire in acceptance criteria. Give the human-send reviewers and the samplers explicit criteria (“no unverified dynamic data; every customer question answered; on-brand tone”), so review checks substance, not format, and the stale-date class of error is specifically on the checklist.

The decision: narrow auto-send to genuinely self-contained low-consequence replies, add a gate (or a data-verification step) for any reply quoting dynamic data, and add sampling to the remaining auto-send stream — instead of either the original no-gate auto-send or the proposed gate-everything. The redesign puts the gate exactly where the risk is (replies with stale-able data) and uses sampling to hold quality on the safe high-volume stream, avoiding both the missing-gate incident and the throttling over-correction.

Assessment traps

Practice questions

Each item states how many responses to select. Commit before revealing.

Key takeaways

• Oversight is about placement: gate the risky step, sample the high-volume stream, spot-check the stable low-stakes work.
• Mandatory triggers — irreversible, regulated, external, sensitive — require a human gate regardless of fluency, speed, or aggregate accuracy.
• Put the gate immediately before the risky action, reviewing the final artefact at the last reversible moment.
• For volume, sample a tracked fraction, oversample risky slices, and tighten on drift; sample heavily during a new process’s burn-in.
• A misplaced gate costs both ways: gate-everything throttles and breeds rubber-stamping; a missing gate lets an irreversible mistake through.
• Fewer, meaningful gates beat blanket review; acceptance criteria turn a gate from guessing into an objective check.
• More review is not safer if it is in the wrong place.