Essay

A Second Check, Always

September 2, 2026· 10 min read

The cheapest error is the one you catch at the source

There is a moment in every AI project where someone looks at the accuracy number, sees it is high, and asks why the pipeline needs a second step. The extraction model is at 94 percent. The classifier is at 96 percent. Why pay for another model call, another few hundred milliseconds, another component to maintain?

The answer is in what the remaining few percent cost. In a financial document pipeline, a single wrong field does not announce itself. It flows downstream into a ledger, a report, a filing, and nobody notices until a discrepancy surfaces weeks later somewhere else entirely, at which point tracing it back to the original extraction is far more expensive than the extraction ever was. The error was cheap to catch at the source and ruinous to catch downstream.

So the second principle I hold in production AI work, after refusing over guessing, is this: every high-stakes AI decision gets validated by an independent mechanism before it is allowed to ship or act. Sometimes that mechanism is a second model. Sometimes it is a deterministic rules layer. Sometimes it is an automated regression suite standing between a proposed change and production. What matters is that it is independent of the thing it is checking.

This essay is about the four forms that second check has taken in systems I have shipped, and what I learned about when each one is the right tool.

Form one: a second model, from a different family

The most direct version is dual-model validation, and the system that taught me its value was a financial document intelligence pipeline processing invoices, bank statements, and regulatory filings.

The architecture is simple to describe. Documents are ingested and parsed. One model, Claude, performs the extraction of structured fields. A second, independent model, based on Gemini, then reviews that extraction specifically for accuracy, completeness, and conformance to the required schema. Nothing passes downstream until it clears that internal quality gate.

The word doing the work in that description is independent. The choice to use a genuinely different model family for the review step, rather than a second call to the same model, was deliberate and it is the part people most often get wrong.

Why the same model cannot check itself

Two calls to the same underlying model are correlated. If that model has a systematic blind spot on a particular document layout or a particular field convention, asking it to check its own output will not reliably surface the blind spot, because the checker shares it. You get the appearance of a second opinion with much less of the substance.

A model from a different family, trained on different data with different architectural choices, has different failure modes. It is more likely to catch a mistake the first model made precisely because it does not make the same mistakes. You are not buying “two chances to be right.” You are buying decorrelation of errors, which is a much more valuable thing.¹

What it delivered

The system reached 94.7 percent accuracy across invoices, bank statements, and regulatory documents, and reduced manual processing time by 78.3 percent. But the result I care more about is organizational: the dual-model validation pattern proved effective enough that it became the default architecture for every AI feature built afterward in that environment. Once a team has seen an independent check catch a confident error before it shipped, they stop asking why the pipeline needs a second step.

The honest limitation

Dual-model validation catches disagreement between two models. It does not catch the case where both are wrong in the same way, for instance a genuinely ambiguous field or a formatting convention unusual enough to confuse any general-purpose model regardless of vendor. For the handful of fields where correctness matters most, totals that must reconcile and dates that must fall in valid ranges, I would add a thin layer of deterministic checks on top. Which brings me to the second form.

Form two: a rules layer that does not care how confident the model is

In the natural language query system I described in Refuse Over Guess, the second check is not another model at all. A small language model proposes a structured intent, and a fully deterministic rules layer independently validates every field of that proposal.

This is the right shape whenever the space of valid outputs is closed and enumerable. A metric either exists or it does not. A date range either parses or it does not. There is no judgment involved in checking those things, so there is no reason to spend a model on it. Rules are cheaper, faster, and, critically, they are right by construction rather than right on average.

The two forms are not competitors. They cover different territory. Use a second model when the check requires judgment: does this extracted summary faithfully represent the document? Use rules when the check requires certainty: is this value inside the allowed set? Most real pipelines need both, and the order matters. Rules go first, because they are cheap and they eliminate the cases where a second model call would be wasted on something that was never going to pass.

That system shipped with more than seven hundred automated tests. I think of the test suite as the third layer of the same idea: an independent mechanism that checks the checkers.

Form three: a sanity pass inside a classification pipeline

The accounting platform I built categorizes every transaction across more than 140 expense categories. Classification runs as a three-stage pipeline: rule-based enrichment first, then an LLM classifier, then an LLM sanity-check pass.

The sanity pass is a second check in its lightest form. It does not redo the classification. It asks a narrower question: given this transaction and this proposed category, is there anything obviously wrong here? A software subscription categorized as travel. A refund categorized as revenue. The kind of confident mistake a classifier makes a few percent of the time and that a reviewer would catch in a second glance.

Two things make this form work. First, the sanity pass is asked a different question than the classifier, which gives it some of the decorrelation benefit even when it is not a different model family. Second, and more important, every human correction feeds back. When a user fixes a categorization, that correction is captured and improves future classification without retraining anything. The second check gets sharper over time because the humans who override it are teaching it where it was wrong.

The platform processes more than a thousand transactions a day at roughly half a cent of AI cost per transaction, with 70 to 90 percent fully automated. The sanity pass is a nontrivial share of that half cent. It is the best money in the pipeline.

Form four: a validation gate on the system’s own changes

The fourth form is the one I find most interesting, because the thing being checked is not a model output. It is a change to the system itself.

In a pipeline that reads handwritten financial applications, I built a monitored optimization loop. Using observability across a multi-model framework, the system continuously monitors its own accuracy, identifies which prompt versions are causing errors, and proposes improvements. So far that is a system tuning itself, which sounds either wonderful or terrifying depending on your temperament.

What makes it the former is the gate. Every proposed change is tested against a held-out validation set before it is promoted. Nothing goes to production because it looked better in the proposal. It has to clear the validation bar first, measured on data the proposal never saw. The optimization loop is the model doing the work; the held-out evaluation is the independent check. Same principle, one level up.

The result is a system whose accuracy on checkbox detection, handwritten numbers, and field extraction has stayed high and kept improving after launch with zero manual prompt retuning. Processing time for an application went from four hours to eight minutes. But the number I would point a skeptical CTO at is the one that is not there: the count of regressions promoted to production by the self-tuning loop. The gate is why that count is zero.

Automatic tuning without that gate is a liability, not a feature. I have seen teams build the loop and skip the gate because the gate is boring. The gate is the product.

Continuous evaluation, or a benchmark that goes stale

There is a fifth pattern that runs underneath all four forms, and it is worth naming on its own because it is the one most often skipped.

A one-time benchmark tells you how a model performed on the documents you happened to have on the day you ran it. It says nothing about six months later, when the real document mix has drifted in format, quality, and edge cases. Degradation that is not measured continuously surfaces only when someone downstream notices something does not add up, which is the expensive way to find out.

So in the document intelligence system, alongside the dual-model gate, I built custom evaluation metrics that continuously and automatically assess data quality on every single extraction, not on a benchmark run once at build time. The second check is not just “did this output pass review?” It is “is the rate at which outputs pass review changing?” A benchmark is a photograph. Production needs a heartbeat.

Choosing the right check

Putting the forms side by side:

Two rules for applying the table. Order the checks from cheapest to most expensive, so rules eliminate the easy failures before a model call is spent. And never let the same component be both the worker and the checker. Independence is the property you are paying for; everything else is implementation.

Why this is the default

I now treat “a second check, always” as the default architecture for anything that touches money, compliance, or a decision a person will act on. Not because models are bad. The models in these systems are excellent, and getting better. I treat it as the default because the cost asymmetry never goes away: an error caught at the source costs one extra step, and an error caught downstream costs an investigation. No amount of model improvement changes which of those you would rather pay for.

The demo will never show you the second check. It slows the demo down and it only matters when something goes wrong. That is exactly why it belongs in the architecture rather than the roadmap.

essaysllm-as-judgeevaluationreliability