Putting a Model Inside the Content Gate: What an AI Reviewer Actually Catches

On 13 September we shipped substance gates for our statistics-driven scripts — 1,386 lines across three pieces: a data-block contract, an engagement check, and a model acting as judge over both. We are writing this up not because “use AI to review AI content” is a novel idea — it isn’t — but because the order those three pieces had to ship in turned out to matter more than we expected, and because what the judge actually catches is a narrower, more specific thing than “quality control.”

Why the contract had to exist first

The instinct, when you decide a model should review content before it publishes, is to hand the model the finished script and ask whether it’s good. We tried a version of that early on, informally, and the results were what you’d expect from asking an open-ended question: plausible-sounding opinions, phrased with the same confident tone regardless of whether anything specific was actually wrong. A judge given a finished script and an open brief produces a review. It does not produce a verdict, because there’s nothing to check the review against except the judge’s own sense of what “good” means that day.

So the data-block contract had to come first, and it had to be a hard requirement rather than a style guideline. Every statistics-driven script now has to declare its underlying data as a structured block before a word of narration is written against it — the claim, the number, the source, the scope it applies to. That block is the thing the judge checks the script against. Not “does this feel accurate,” but “does every stated number in the script trace back to an entry in the declared data block, and does the scope match.” That is a question a model can actually answer, because it has something concrete to compare rather than a general impression to render.

This is the same lesson in a different shape from the $110,000 hallucination case — a citation looks exactly as confident whether or not it’s real, and the only way to tell the difference is to check it against something structured, not to ask whether it reads convincingly. A model reviewing prose for “accuracy” without a data block to check against has the identical problem the lawyers in that case had: nothing external to verify against, just the fluency of the sentence.

The engagement check, and what it’s for

The engagement check sits after the data-block contract and does a different job. It isn’t about whether the numbers are real — the data-block contract already establishes that. It’s about whether the script does anything with them a reader would actually stay for. A script can pass the data-block contract perfectly — every number sourced, every scope correct — and still be a list of accurate facts nobody wanted to read in that order. The engagement check is a second, separate gate specifically because “true” and “worth reading” are different failure modes, and a single gate that tried to catch both would inevitably get better at one at the expense of the other.

We built these as genuinely separate checks rather than folding engagement into the same judge pass that verifies data, on the theory — which held up in practice — that a check trying to answer two different questions at once tends to answer neither one precisely. This is the same principle behind the pipeline that writes and publishes: each stage does one job and hands off a specific, checkable output, rather than one stage trying to be responsible for everything downstream of it.

What the judge catches reliably

With the data-block contract in place, the model-as-judge step does something narrower and more mechanical than “review the content”: it checks specific claims in the script against specific entries in the declared data block and flags anything that doesn’t trace back cleanly. That’s a matching problem, not a taste problem, and matching problems are exactly what a model reviewer is reliable at. A number in the narration that doesn’t appear in the data block. A claim scoped more broadly than the underlying data supports — a script asserting something about “customers” when the declared data only covers one segment of them. A source cited for one number that was actually attached to a different one in the data block. These are the failures the judge catches consistently, because they are structural mismatches between two things it can compare directly.

What it waves through

The honest half of this post is what the judge does not catch reliably, and it’s worth naming rather than letting the gate’s existence imply more coverage than it has. A claim can be perfectly traceable to the data block and still be a bad idea to publish — accurate, properly scoped, sourced correctly, and simply not a claim worth making, or one that reads as spin even though every number behind it checks out. The judge is verifying a relationship between the script and the data block. It is not exercising the kind of editorial judgement about whether the underlying framing is fair, which is a different question from whether the numbers are real, and one we are not currently asking a model to answer alone.

This mirrors a trade-off we described when we wrote about scaling content production without sacrificing quality: quality gates are good at catching the failure mode they were built to catch, and the discipline is being precise about which failure mode that is rather than treating “passed the gate” as a synonym for “good.” A script that passes the data-block contract, the engagement check, and the model-as-judge review has cleared three specific, narrow bars. It has not been declared good in any sense broader than that, and we’d rather say so than let the gate’s name do more work than its actual coverage justifies.

The ordering lesson, generalised

If there’s one thing from this we’d tell a team about to add a model reviewer to their own pipeline, it’s this: decide what structured thing the model is checking against before you decide what the model should say about it. A judge is only as good as the artefact it’s judging against. Ours didn’t produce anything useful until we gave it a data block with a fixed shape to compare claims to — before that, we had an opinion generator with good production values. The contract wasn’t a formality that happened to ship alongside the judge. It was the precondition for the judge meaning anything at all.

If you’re building a similar review step into your own content pipeline and want to compare notes on where a model-as-judge is reliable and where it isn’t, ContentSage’s team can compare notes.