The Review Queue Sets the Speed Limit on Generation
The problem
I ran a marketing content-generation pipeline through a scripted fourteen-day trace where the team upgrades to a faster, cheaper generation model partway through and scales daily output from twenty drafts to two hundred. The human review team's capacity doesn't move an inch across those same fourteen days. Twenty-five drafts a day, fixed, because that's genuinely how many a person can read carefully and give useful feedback on in a working day.
Generation velocity and review capacity are now moving in completely different directions, and I built the response into the trace exactly the way I've watched teams actually respond to this pressure in practice: push the backlog through by skipping review on the oldest items sitting in the queue. That silent pass gets treated as an acceptable release valve, a way to keep the pipeline from visibly jamming, rather than what it actually is, which is a capacity signal nobody bothered to listen to.
By day fourteen, two numbers had both climbed in a way that should worry anyone watching them. The unreviewed-ship rate, the share of published drafts each day that never got looked at because the backlog had already overflowed, kept rising. The quality-escape rate, the share of those unreviewed drafts that a separate quality check later flagged as genuinely defective, rose right alongside it. Generation kept accelerating the entire time, because nothing in the pipeline was checking generation speed against what review could actually clear. The two curves diverged, and the gap between them is exactly where the defects were hiding.
What strikes me most about this failure, looking back at the trace, is how reasonable each individual decision looked in isolation. Upgrading to a faster model is good engineering. Wanting more content output is a reasonable business goal. In the moment, skipping review on the oldest backlog items felt like the pragmatic choice compared to blocking the whole pipeline. Nobody made a bad decision here. The pipeline simply never had a mechanism that named the growing gap between what it could generate and what it could verify as a problem in its own right.
The pattern
The fix caps daily generation at whatever the review queue can actually clear, with a small configurable buffer, instead of letting generation scale to demand or to how fast the model happens to run. A throughput-gate checks queue depth before releasing the next batch of generation. If the queue is already near its clearing capacity, the gate holds back new generation instead of adding to a pile that's already growing faster than anyone can work through it.
When demand for generation consistently exceeds that capped rate over a rolling window, the system raises a structured event: invest in verification capacity. That event is a named, logged signal pointing straight at the actual constraint, standing in for the two responses I'd otherwise expect: a silent skip of unreviewed drafts, or a reflexive swap to a different generation model to compensate for a problem that was never about generation quality in the first place.
Running the same fourteen-day demand ramp with this gate in place holds the unreviewed-ship rate and the quality-escape rate at or near zero the entire time, because ungated generation never gets the chance to outpace review. The backlog stays flat instead of climbing, and the throttling itself gets logged and made visible on purpose, instead of staying invisible and denied. The pipeline keeps shipping at exactly the rate it can actually stand behind, and the gap between what the business wants and what it can currently verify becomes a named decision for someone to act on, instead of a quality problem that surfaces downstream after it's already out the door.
The same ratio showed up outside my trace in early October. OpenAI published 722 machine-generated mathematical manuscripts across 17 fields, and only 162 of them, about 22 percent, had their main results formalized in Lean, the proof assistant that checks each step mechanically. The rest wait on human verification, and the Association for Human Mathematics objected publicly to publication by blog post in place of peer review. Mathematics makes an unusually clean test case, because the verification capacity is a known quantity: a community of referees with a finite number of hours. A system that produces 722 manuscripts stands in the same relationship to that community that my two-hundred-draft pipeline stood in to its twenty-five-draft review team. Generation speed belongs to the model. Verification speed belongs to the people, and nothing in the release rate was tied to either one.
Design considerations
This pattern manages a symptom, and I want to be plain about that instead of overselling it. Capping throughput to capacity doesn't manufacture more reviewer capacity out of thin air. If the capacity-investment signal fires and nobody acts on it, generation just stays permanently throttled below what the business wants to produce, and the underlying shortfall never actually gets resolved. What the gate guarantees is that the shortfall stays visible and named instead of getting silently absorbed as a rising defect rate that someone eventually notices in production, weeks after the fact, with no clear line back to its cause.
The buffer built into the cap deserves real thought. A default value copied from somewhere else won't do. Too thin a buffer and any single day of reviewer absence, illness, a public holiday, a reviewer pulled onto something urgent, immediately produces a backlog that the gate then has to work through over several days. Too generous a buffer and the pipeline is deliberately generating well below what review could actually handle on a normal day, leaving real throughput on the table for the sake of a cushion that mostly never gets used. I've found this number has to come from actually watching review capacity vary over a few real months. Guessing at it from an average hides exactly the variance the buffer exists to absorb.
There's a version of this problem the gate doesn't touch at all: work that arrives in a genuine, unavoidable spike rather than a sustained climb, a product launch that needs a burst of content on a specific date, a seasonal push that can't be smoothed out over a longer window, both entirely different from a sustained climb in ordinary demand. A throughput gate built around a rolling-window capacity-investment signal is calibrated to catch sustained mismatch, and a short, deliberate spike the business already knows about and has planned reviewer coverage around is a completely different situation calling for a completely different response. Applying the same gate logic to a planned spike either blocks legitimate, expected volume or forces the buffer so wide that it stops doing useful work the rest of the year.
The harder question underneath all of this is what actually counts as review capacity in the first place, and I don't think it's a fixed number the way twenty-five drafts a day makes it sound. Review quality itself degrades under sustained pressure well before a reviewer's raw throughput drops, so a queue that's technically clearing twenty-five items a day might be producing steadily worse review on each of them as fatigue accumulates, and a gate that only watches queue depth has no way to see that kind of decay happening underneath a number that looks stable on the surface. Capacity, measured honestly, is the quality of the judgment being applied as much as it is the count of items that got looked at.