Introduction
The fallback, and the most powerful check available: describe what counts as a violation in plain language, and a model judges each input against it.
It is also the default a new control starts on, which is worth resisting. Reach for a prebuilt check where one fits — this one costs a model call every time it runs.
What it detects
"Describe a check in plain language; an LLM evaluates each input."
Whatever you can articulate. The shipped ISO 42001 pack uses it twice, for judgements no prebuilt check could make: validating tool output before downstream execution, and flagging disparate outcome patterns. Both are questions about whether behaviour was appropriate, which is exactly what a classifier is for.
Configuring it
Field | What it is |
| "The model that evaluates the prompt against the inputs." |
| "Describe exactly what should count as a violation. The inputs are appended automatically." |
| How the model reports its verdict — |
"The inputs are appended automatically" is the sentence to internalise. You write the question, not the harness. Do not paste the content in, do not add placeholders for it, and do not write instructions about formatting — write the rule.
Check model and Check prompt are required. The check runs on User input, Agent output, Tool input and Tool output — not on Tool name — and offers Flag and Block.
Binary or scale
Output | You set | Use when |
| "Breach when the answer is" — | The question has a clean answer |
| A breach threshold; the control trips at or above it | The judgement is a matter of degree |
Prefer the scale where the judgement is genuinely graded. It gives you a dial to turn when the control is too noisy. A binary check that misfires leaves you rewriting the prompt, which is a much blunter instrument.
Note the direction on binary: you choose which answer constitutes a breach. A prompt phrased "is this response appropriate?" breaches on No; one phrased "does this contain a fabrication?" breaches on Yes. Getting that backwards produces a control that fires on everything, and it is the single most common mistake with this check.
Writing a check prompt
Describe the violation, not the goal — "The response states a delivery date not supported by the tool output" is checkable. "The agent should be accurate" is not.
One judgement per control — A prompt asking about three things returns one verdict, and you will not know which of the three fired.
Say what does not count — Naming the near-misses is usually more valuable than elaborating the positive case.
Keep it short enough to reread — You will be tuning this against real incidents. A prompt you cannot hold in your head is one you cannot debug.
Test it before saving
This is the check where Test this control matters most, because a prompt's behaviour is genuinely hard to predict. Run sample content that should breach and sample content that should not — the second is what catches an inverted binary or an over-broad prompt.
"Every other check has a shape you can reason about. This one has whatever you wrote — which is why it ships with a test panel."
What it costs
A model call per evaluation, on every input the control reads. Four apply points on a busy agent means four calls per interaction.
That lands in governance spend, and it is the main reason to prefer a prebuilt check where one fits. See Where Spend Comes From.
Known limitations
No Mask — The check returns a verdict, not a position, so there is nothing to mask.
FlagandBlockonly.Non-deterministic — Two similar inputs can be judged differently. Borderline cases will be inconsistent, and a scale output with a sensible threshold handles that better than a binary one.
Cost scales with traffic and apply points — Unlike every prebuilt pattern or term check.
Only as good as the prompt — Which is the trade for its flexibility.