When is deterministic validation better than another model call?

The reflex when something needs checking in an AI workflow is to add another model call, because the surrounding system is already model-based and the check is easy to describe in words. That reflex is usually wrong. Most of what needs checking is a condition — this field is present, this value is in range, this identifier resolves, this total matches, this format parses — and every condition of that kind is a few lines of code with properties a model call does not have.

Those properties are worth naming. It returns the same verdict on identical input, so a passing result means something stable. It costs effectively nothing, so it can run on every item rather than on a sample. It is fast enough to sit inline. It fails with a specific reason rather than a paragraph. And it is immune to presentation, which matters more than it sounds: a model reviewing a well-organised confident wrong answer is more likely to approve it, and a validator does not read the prose at all.

The reserve case for a model check is genuine linguistic judgement: does this passage support this claim, is this response appropriate in tone, does this summary omit something material, are these two descriptions of the same thing. These resist expression as rules, and a model does them usefully — particularly when it sees only the artefact and the criterion, without the reasoning that produced the artefact.

The productive pattern combines both in order. Run the deterministic checks first and stop on failure, because a run that fails a structural check does not need a judgement about its quality. Then apply the model check to what survives, on a sample if volume requires. This ordering also lowers cost substantially, since the cheap check eliminates most of the failures before the expensive one runs.

There is a design consequence upstream. If checks are easier when the output has a defined shape, then constraining the output shape is what makes deterministic validation possible, and that decision is made when the workflow is designed rather than when the checking is added. Workflows that emit free prose have chosen model-based checking by default, usually without anyone noticing the choice was being made.

One honest limitation. A deterministic check verifies conformance, not correctness: an identifier that resolves may be the wrong identifier, and a total that reconciles may reconcile to the wrong figure. That is a real gap and it is not an argument for replacing the check with a judgement, which does not close it either. It is an argument for the checks to test the things that actually distinguish right from wrong in your process, which requires knowing what those are.