Instruction-following & constraint-adherence testing

How it works

A system prompt is the least-tested code in an AI product: it is edited like configuration, it has no compiler, and nothing fails loudly when the model quietly stops honouring rule eleven. Testing it splits into three parts that fail independently. Verifiable constraints come first — write each instruction so a program can check it (length, required or forbidden words, language, casing, structure, ordering) and score two numbers, per-constraint adherence and the strict all-constraints-satisfied rate, because a response meeting five of six requirements is a failure to the person who asked for six, however good the average looks. Precedence comes second: when the system prompt, the user, and a tool result or retrieved document disagree, which one wins, and does the answer match the order the product intends. That is the same question prompt-injection testing asks, minus the adversary — an ordinary conflict between legitimate sources, which is how most precedence bugs actually reach production. Persistence comes third, and is the one offline suites miss: a rule honoured at turn three is often gone by turn forty, so adherence is measured as a function of conversation depth and context load rather than once on a fresh context. Negative instructions ('do not mention', 'never suggest') fail markedly more often than positive ones and belong in their own bucket rather than averaged into a single score.

When to use it

Any system whose behaviour rests on a system prompt — which is nearly all of them; as a regression gate after every prompt edit, since a prompt change is a code change with no type checker and no test that fails on its own; agents that take instruction from several sources at once (developer, user, tool output, retrieved document); before shipping a structured-output feature; and whenever a prompt has grown by accretion past a dozen rules, because the probability that all of them are still being followed together drops long before anyone notices a specific one being dropped.

Limitations

Only the machine-verifiable half is cheap and objective; 'be concise', 'stay professional', 'match our tone' need a judge model or a human and inherit those biases, so the trustworthy part of the score covers the constraints you could mechanise. Per-constraint rates flatter the system — the strict rate is the one users experience, and the gap between them widens with every rule added. Results don't transfer across models or even across phrasings of the same rule, so this is a per-system gate rather than a comparison. And a model can satisfy every stated constraint while missing what was actually wanted, which is why a strict score on its own is not evidence that the feature works. Tightening constraints can also cost answer quality, so the adherence number needs a quality number measured in the same run.

Cite this