Once a content pipeline is handed to a model, volume stops being the problem. Trust becomes it.
And the expensive errors are never the obviously fake ones. They're the ones that look entirely correct: mixed definitions, drifting units, seasonality sold as growth, a number cited from evidence that doesn't contain it. They read as fluent, professional and well-supported, and only someone who knows the domain stops at them on the third pass.
So you need gates. Where they go, how many, and who mans them is the part worth getting right.
Three layers, and the order can't change
Layer one: deterministic rules. Never delegate to a model what code can decide. Does the number appear verbatim in the cited evidence? Are the units right? Does the time range cross definitions? Is the entity the one that actually exists in the system?
None of these have a gray zone, they run in milliseconds, and they don't have moods. They go first so the expensive review that follows isn't spent on trivia.
Layer two: a multi-model review panel. Whatever fails the deterministic rules goes straight back; what passes is worth a model's attention on things that genuinely need judgment — does this conclusion hold, is this causal claim defensible, has the tone crossed a line?
The critical part is that the reviewer can't be the generator. Sharing a context makes evaluation systematically lenient.
Layer three: people. A review console, source on the left and fields on the right, confirmed line by line before anything lands. Fully manual at the start, a few weeks to season the checks, then the machine takes over the front of the line.
Invert the order and you lose: put model review first and rules second, and you'll pay inference costs on problems one line of code could have blocked.
A gate trims the tail; it doesn't reshape the body
This is the part I see misread most.
If a gate significantly changes the body of the output — most normal results get altered by it — that isn't a gate problem, it's an upstream problem, and the fix belongs in the prompt, the tools or the data. A gate here is just covering the lesion.
What a gate should do is shave the tail: the fraction of a percent that comes out absurd, hallucinated, or out of bounds. It contributes almost nothing to average quality. Its entire value is making sure the worst few never happen.
To judge whether a gate is healthy, look at its block rate. Persistently high means upstream is broken; persistently zero means it's decoration.
Fail open when drafting, fail closed when publishing
The same content deserves completely different strictness at different stages.
Fail open while generating. For drafts, intermediate results, things only you will see, keep the gate loose. Here a false positive costs more than a miss — a blocked draft is one wasted inference, and it was going to be edited by a person anyway.
Fail closed before publishing. Once this will appear in front of a user, be cited, or enter a database, the gate should be strict enough to prefer publishing nothing. Here a miss costs far more than a false positive.
Plenty of systems run one threshold end to end: either too strict early, which strangles exploration, or too loose late, which sends the tail straight to users.
A few gates that actually earn their place
From systems that really run. All of them are unglamorous, and all of them have caught something real:
- Numeric verification. Every amount, count and percentage in the output must match a value found in the cited evidence. No match, no publish, and "approximately" doesn't count.
- A material-change gate. If this round's data hasn't meaningfully changed from last round's, the topic goes into cooldown and nothing is generated. Otherwise the system produces for the sake of producing, and manufactures zero-information content like "flat this week."
- Topic fatigue. Semantically cluster recently covered topics and keep them out during a cooldown window. This is what stops the same story being retold three times in different words.
- Red lines. No KPI targets, only red lines: correction rate, retraction rate, out-of-scope leakage rate. These numbers aren't for performance review. They're for stopping the line.
Boundaries
Gates don't create quality; they prevent quality incidents. A mediocre system with a hundred gates still produces mediocre output — it just doesn't embarrass itself. Real improvement always comes from upstream.
The human layer can't stay human forever. The point of the review console isn't to keep a review team employed; it's to collect high-quality judgments — what passes, what doesn't, and why. Those labels are the fuel that lets machines take over step by step. If a year later people are still doing the same share of the work, that gate was designed badly.