Pattern: Human Review Queues That Scale

Human review is how most AI features become safe enough to ship. It is also how they become impossible to scale, and the difference is entirely in what fraction of items a human sees and how long each one takes them.

Review everything, review nothing

The two defaults are both bad and both common. Reviewing every item caps the feature’s throughput at human throughput, which usually removes the reason for building it — and, worse, degrades into rubber-stamping. A reviewer approving hundreds of items with a high base rate of correctness stops reading. That is not a discipline problem; it is what attention does under a low signal rate, and it means a hundred per cent review can catch fewer errors than a well-targeted ten per cent.

Reviewing nothing is the other default, usually arrived at by accident: the queue exists, nobody is assigned to it, and it becomes a log. The failure is silent, because an unreviewed queue looks exactly like a reviewed one from outside.

The pattern between them is to route by expected value: a human sees an item when their attention plausibly changes the outcome, and everything else proceeds without them.

Routing by expected value

Three signals, combined, decide whether an item is queued. None of them alone is sufficient and the third is the one usually missing.

• Confidence. Some measure of how uncertain the system is: logprobs on a classification, disagreement between two samples, a verifier’s objection, a retrieval score below threshold, a validation warning. Any of these beats a self-reported score, which needs calibrating before it can carry weight.
• Stakes. The cost of this specific item being wrong. A refund of five pounds and a refund of five thousand are not the same review decision even at identical confidence, and stakes are usually a field you already have.
• Reversibility. Whether an error found later can be undone. An item that is reversible for a week does not need pre-review; it needs post-hoc sampling. This is the signal that lets a queue shrink dramatically without a change in risk.

The combination gives four routes rather than a binary. Auto-approve high-confidence low-stakes items. Queue low-confidence high-stakes items for pre-execution review. For high-confidence high-stakes items, execute with a reversibility window and sample a fraction for post-review. And for low-confidence low-stakes items, prefer abstention or a deterministic fallback over a human — they are the bulk of the uncertain traffic and the least worth anybody’s time.

The sampled post-review route is the one teams leave out, and it is the one that keeps the whole system honest, because it is the only route that produces evidence about the items you decided not to look at.

One structural point about the confidence signal itself. The signals that work best are the ones produced as a by-product of something you were doing anyway — a schema violation, an arithmetic mismatch, a retrieval score, two samples disagreeing. They cost nothing extra, they are grounded in an observable event rather than in the model’s opinion of itself, and they degrade gracefully: if the signal stops being informative, the queue simply routes on the others. A single learned confidence score, by contrast, is a component that can silently stop being calibrated, and when it does the routing decision quietly becomes random while every dashboard continues to look normal.

The capacity arithmetic

A review queue is a queue, and the arithmetic is the arithmetic of every queue: if arrivals exceed service, the backlog grows without bound. This gets skipped because the queue is staffed by people rather than servers, and people do not report a depth metric.

arrival_rate = volume * queue_fraction        // items per hour into the queue
service_rate = reviewers * 3600 / seconds_per_review

STABILITY:      arrival_rate  <  service_rate
                 (strictly less; at equality the queue is already unstable
                  because arrivals are bursty and reviewers are not)

Rearranged, the number you can actually control:

  queue_fraction  <  reviewers * 3600 / (volume * seconds_per_review)

Read it as a budget. Reviewer headcount and volume are given to you.
seconds_per_review is set by the INTERFACE. queue_fraction is set by the
routing thresholds. If the inequality fails, exactly two levers exist:
raise the confidence threshold (see fewer items) or cut seconds_per_review
(make each item faster). Hiring is the lever that is always proposed and
scales worst, because volume grows and headcount is linear.

Also plan for the tail: at 80% utilisation, waiting time is already
several times the service time. A queue sized to be exactly keeping up
is a queue with a multi-hour latency, which for a pre-execution review
is a product decision, not an operational detail.

The most under-appreciated term is seconds_per_review, because it is the one nobody treats as engineering. Halving it is exactly as valuable as doubling the reviewers and considerably cheaper, and it is entirely a function of the interface.

The interface decides whether it works

A review queue implemented as a list of records with an approve button will produce approvals, not reviews. Four properties change the reviewer’s job from investigation to verification.

One anti-property, worth stating explicitly: never show the model’s confidence as a number next to the approve button without knowing it is calibrated. Reviewers anchor on it, approval rates track it, and an uncalibrated number becomes an instruction.

Who reviews is a design decision too, and it is usually made by default. Routing every queued item to a domain expert is expensive and often unnecessary: many queue entries are there because a field was malformed or a document was unreadable, which anyone can resolve. Two tiers — a first pass that handles the mechanical cases and an escalation path for genuine judgement calls — cuts the expert load substantially, and it does so without changing any threshold. The signal that you need this is a queue where the same person is alternating between five-second decisions and five-minute ones, because the long ones set the pace for both.

Closing the loop

A queue that only gates is worth much less than a queue that also teaches, and the difference is a small amount of plumbing decided early.

• Capture the correction, not just the verdict. The corrected value is a labelled example produced by an expert as a by-product of work they were doing anyway. This is the cheapest source of evaluation data any team has, and it is thrown away by default.
• Feed corrections into the eval set, deliberately. Not all of them — a set made only of past failures stops representing traffic. Sample corrections into your golden dataset alongside ordinary cases, and keep the ratio written down.
• Track approval rate per route, and read it. If reviewers approve nearly everything in the queue, the threshold is too conservative and their time is being wasted. If they reject most of it, something upstream is broken and the queue is absorbing a defect rather than a tail. Both are actionable and neither is visible without the metric.
• Sample the auto-approved path. Review a small random fraction of what never reached the queue. Without this, the error rate on the majority of your traffic is unmeasured, and the routing thresholds are unfalsifiable. This is the same argument as for grading a sample of production traffic, applied to the specific decision the queue embodies.

Done well, the queue’s share of traffic falls over time as the system improves and the thresholds are retuned — which is the visible form of progress in a feature like this, and the reason to make queue_fraction a monitored number rather than a constant somebody chose once.