In one paragraph
Given a specification to check text against, the natural move is to put the specification in the system prompt, put the text underneath, and ask. It works well enough to stop anyone questioning the shape. We recently went through a real standard with 53 numbered rules asking a narrow question of each: could this be decided by counting, by pattern matching, or by a dictionary lookup, with no model in the loop? Twelve could, outright. Thirteen more looked as though they could, because the standard ships a controlled dictionary and a lookup seems like a decision. That second group is where the interesting failure lives, and finding it changed the architecture. The dictionary does not decide anything. It is evidence, and handing it to the model is worth far more than trying to use it instead of one.
The reflex, and what it costs
The pattern is easy to recognise once named. An organisation has a specification: a style guide, a regulatory checklist, a set of drafting conventions. It wants text checked against it. So it renders the whole specification into a system prompt and sends every piece of text through with the lot attached.
Our own starting point was exactly this. The consolidated compliance prompt for ASD-STE100, the controlled-language standard used in aerospace and defence technical documentation, came to 89,468 bytes. Roughly 22,000 tokens of system prompt, before a single word of the text being checked. A user checking one paragraph paid for all 53 rules, every time.
Three costs follow, and only the first is obvious.
The direct cost is tokens. Twenty-two thousand tokens of instruction to evaluate forty words of input is a ratio that would be flagged immediately anywhere else in an engineering estate.
The second is latency, and it decides what the tool can be. One call over a long prompt returns everything at once, after a wait. Nothing can be shown until all of it is done, so the interaction has one state, which is waiting.
The third is the one that matters for assurance. A model asked to apply a counting rule will sometimes get the count wrong. Not often, and not unrecoverably, but non-deterministically. This sentence has 23 words and the limit is 20 is a finding that should be identical every time it is produced, by anyone, on any run. Once it comes out of a sampled generation, it is a finding that is usually right.
The correction that also fails
The obvious response is to take work away from the model. That is what we tried, and the standard itself explains why it does not work.
ASD-STE100 has two parts. Fifty-three rules, and a controlled dictionary of about 2,000 entries specifying which words are approved, as which part of speech, with which meanings, and what to use instead when a word is not approved. That dictionary looks like the answer. Approval is a lookup, the alternative is a field, and a lookup is not inference.
Then you meet this, which is the standard's own worked example for rule 1.3:
Not compliant: Follow the safety instructions. Compliant: Obey the safety instructions.
Follow is an approved word. The lookup passes it. It is approved only with the meaning 'come after, go after', and using it to mean 'comply with' is a deviation the lookup cannot see, because the word is on the list and the failure is in the sense.
So the deterministic pass does not merely miss things. It certifies text that deviates. A tool that silently passes non-compliant text is worse than one that does not check at all, because it produces a record saying the text was checked.
Rule 9.1 makes the same point from the other direction, and it is worth quoting because it is the standard prohibiting the method:
When a non-approved word cannot simply be swapped for an approved word with the same part of speech and the same meaning, do not force a literal word-for-word replacement. Instead, restructure the sentence.
Knowing the approved alternative is not the same as being able to apply it. A tool that substitutes because the dictionary names a substitution produces text the standard would flag.
Where the deterministic work actually goes
Once both failures are on the table the architecture resolves, and it is not a compromise between them.
Before the call, deterministic work produces evidence. The dictionary lookup runs against the words actually present in the text, and its results go into the prompt as findings: this word is not approved, its alternative is this, this word is absent from the dictionary entirely. The model is told what the list says instead of recalling it, and it still decides. That is the correct role for a lookup, and it is what the original tool did before we tried to promote it.
The same stage segments the text into blocks, labels each by type, and tokenises under the standard's own counting rules. Several rules apply different limits depending on whether a block is a procedural work step, a warning, a note or a descriptive paragraph. Without the labels the model has to infer the block type and then apply a limit to its own inference.
During the call, the model decides, in chunks. Sectioned by rule group, each call carries only the rules still in play against text that has already been prepared. Chunks that only apply to procedural writing do not run on a descriptive document. This is also where the standard's genuine ambiguities live: rules 3.3, 3.4 and 3.6 all match is or are plus a past participle, and telling them apart requires deciding whether the participle describes a state or an action. Keeping those three in one chunk means the precedence question is asked once, by something capable of answering it.
After the call, deterministic work verifies. This is the part that survives from the original argument, and it is the strongest version of it. Once a rewrite comes back, arithmetic establishes with certainty and no inference whether the rewritten procedural sentence is 20 words or fewer, whether the descriptive sentence is 25 or fewer, whether a semicolon was introduced, whether a British spelling crept in, whether a sentence that was compliant on length stopped being so.
The model does the work. Arithmetic checks its homework. Where they disagree, the tool reports the disagreement rather than choosing.
Why this is an assurance argument
Three properties follow, and each maps to something a governance function already asks for.
A stated confidence boundary. A finding can now say which side of the line it came from. This sentence has 23 words, and the limit for a procedural step is 20 is a different kind of claim from this paragraph appears to cover two topics, and a reviewer is entitled to know which they are reading. Systems presenting both with identical confidence are how misinformation and confabulation shows up in an assurance context, where the cost is a reviewer trusting a judgement that was never certain.
Verification that is regression-testable. The post-call arithmetic is ordinary software and can be tested like ordinary software. Untested AI failure scenarios describes the gap between what an organisation evaluates and what it relies on, and a verification layer written in code is inside the part of the estate where conventional testing works even though the thing it verifies is not.
Attributable regressions. When preparation, judgement and verification are separate stages, a change in output quality traces to one of them. When all three live in one prompt, a behaviour change after a model update is unattributable, and model drift becomes something you observe rather than something you diagnose.
There is a fourth, and it persuades finance. The judgement stage got cheaper because it stopped carrying rules it was not being asked about, and the preparation and verification stages cost nothing per run. Assurance that is cheaper gets run more often, and assurance that runs often is worth more than assurance that is thorough and annual.
The body that owns the standard has since said the same thing from its side. The ASD Simplified Technical English Maintenance Group's June 2026 position paper on AI names three things a model puts at risk in STE work: reliability, terminology control, and the traceability of content decisions. The first two are what the dictionary-as-evidence design above is for. The third is the whole point of keeping the counting and the checking deterministic: a finding that is the same on every run, by anyone, is a finding you can trace, and one that comes out of a sampled generation is not.
Where this generalises
Controlled language is an unusually clean case because much of the standard is mechanical. Most specifications are messier. The method still applies, and the questions to ask of any check are narrow.
What evidence would make this decision easier? Lists, registers, schemas, previous decisions. Assemble it deterministically and hand it over. Do not use it as the decision.
What can be verified about the answer after the fact? Lengths, formats, presence, absence, structural properties. Check those in code, after the model has spoken.
What is left? That is the actual question, and it is what the model is for.
Applied to an output validation guardrail, the split is usually stark. Whether a response contains a bare account number is a pattern, and it should be verified after generation rather than requested during it. Whether a linked domain is on an allowlist is a lookup, and the allowlist belongs in the prompt as well as in the check. Whether the tone suits a distressed customer is judgement. The same shape applies to improper output handling, where the structural checks are the ones with regulatory consequences and the ones you least want sampled.
The uncomfortable part
Doing this requires reading the specification. Not summarising it, not embedding it, not passing it through. Reading it, rule by rule, and forming a view about each one.
That is slow, unglamorous, and the step the reflex exists to avoid. Putting the whole standard in a prompt is attractive precisely because it does not require anyone to understand the standard. The model appears to absorb the understanding on the organisation's behalf.
It does not, and the tell is that nobody can say afterwards which parts of the specification the system is reliable about. That is a governance question wearing engineering clothes, and it is the same question as the one in LLM governance operationally: what is the unit of change, who can make it, and how would you know afterwards?
Our own triage took about a day for a 53-rule standard, and its most useful output was not the twelve deterministic rules. It was follow against obey: the discovery that the part we were most confident about automating was the part that would have failed quietly. Every organisation running an LLM assurance pipeline should be able to say which of its checks are arithmetic, which are evidence, and which are opinions. Very few can, and the ones that have looked usually found something like this.
The rule pages show the working for all 53, including the seven marked as needing human judgement whatever the tooling does. The prompts themselves are published in full, so the argument here can be checked against what actually runs.