Pace the pipeline

Every review stage has a finite catching speed. When output volume exceeds it, the share of errors caught falls mechanically — no amount of reviewer diligence changes the arithmetic of a saturated queue. Pacing the pipeline means governing volume as deliberately as quality: rate-limiting how much AI output can reach consequential action per reviewer-hour, or scaling checking capacity before scaling generation.

Institutionally this looks like: production quotas tied to review staffing, queue-depth alarms that trigger slowdowns rather than backlogs, and honest capacity math in every deployment plan ("who checks this, and how long does a real check take?").

The alert-saturation failure in the Illinois Rapid Safety Feedback case is the canonical counterexample: thousands of maximum-risk flags against a fixed caseload is a pipeline nobody paced.

In the Lab (v10) pacing is a placeable component, not a network-wide lever: the pacing-gate modifiers — one on the review channel, one on the record channel — are tethered onto the specific pathway they throttle, and the effects below are theirs. Where you place the gate is the governance decision.