Rule-set judge
A term list checks words. A rule such as "address the reader formally" is prose, and a term list cannot check it. The rule-set judge lets a second, small model read each finished text of a configuration and check it against the rules in the snippet library. It is off unless an administrator switches it on. ADR-288 records the decisions.
Switching it on
- Write the rules into one or more prompt snippets and give them a tag, for
example
brand_. Every non-empty line is one rule, so write one rule per line. A hint quotes the line.rules - Create a configuration for the judge: a small, fast model with a short
timeout, for example 10 seconds, and no fallback chain, so that one check
stays one call. A timeout is not retried. Its provider must be at least as
trusted as the provider that wrote the text, and must admit the data class
declared on the rule snippets. Otherwise the check does not run. Where the
writing provider is not known, for a configuration that picks its model by
criteria or a provider without a declared trust zone, only a judge on a
localprovider is asked. -
Open the configuration whose texts are to be checked, tab Rule-set judge:
- Check against the rule set
- Off, Report or Block.
- Rule set (snippet tags)
- The tags of the rule snippets. The same tags can also be selected under Prompt snippet tags, so the model writing the text sees the rules too.
- Judging configuration
- The configuration created in step 2. There is no default: nr-llm does not know which of your models is the small one.
Only administrators see and write the fields, also through the DataHandler, whatever a group is granted. The judge sends the text to the provider of the judging configuration, which is the same kind of decision as routing snippets into a caller's system message.
Report and block
- Report
- The text is delivered. For each broken rule the editor reads a hint that quotes the rule and the passage. When the check fails, the text is delivered with a hint that it was not checked.
- Block
- A broken rule stops the text like a term list. The message quotes the rule and the passage. When the check fails, the text is stopped as well: an output must not be able to switch off its own check by confusing the judge. The block appears as a governance event, which names the rules but does not store the passage.
A check fails when the judging configuration is missing or inactive, the call fails or takes longer than its timeout (20 seconds at most), the answer does not match the expected format, or the judge names violations of which none can be found in the text. A failure is logged as a warning.
What is checked
One call per finished text. Not checked are answers under 30 words, the tool rounds of a plain loop and image descriptions. A JSON answer, as a wizard receives it, is checked by its text values. A queued task and a field fill have no tools and store their answer, so that answer is checked.
In the AI chat and in editor actions, runs that offer tools, the change a writing tool would make is checked, not the text of the chat: one call per response that proposes a write. In report mode the change is proposed with the hints; in block mode it is not proposed, and the chat says which rule stopped it.
A stream is held in block mode, so the editor sees the text appear at once after the check. In report mode it streams as usual and is checked at its end.
The judge runs after the other guardrails. A text a term list already stopped costs no call.
A caller can name further configurations whose guardrails apply too (ADR-290); the AI chat does so when it runs on a site's own configuration and names its own. Each of them with the judge switched on is checked with its own rule set by its own judging configuration, one call each, and the strictest mode decides: block over report over off. The same rule broken at the same passage is reported once. Each judge may only receive what the provider that wrote the text may pass on: the trust-zone check is measured against the configuration the call runs on. A site on a more trusted provider than the chat configuration's judge is therefore reported as not checked by that judge, and in block mode its judged writes stop until the judge is moved to a provider at least as trusted.
Cost and limits
Every check is a call on the judging configuration and is recorded like any other call: in usage, cost, telemetry and the budget of that configuration. A cached answer is checked again when it is served.
The judge is a model. Its verdict can differ between two runs on the same text, and it can miss a violation. A hint or block only quotes a rule that exists and a passage that is in the text, so it cannot point at something invented.
Where editors see the result
A block reaches every surface that shows term-list messages today, as the same kind of exception. Its message quotes the passage; a surface that stores the refusal, a job's error or a chat message, stores the version without it.
Hints appear in the AI task module and the tool playground, and with their releases in the cowriter's writing dialog, the landing page wizard, the repurpose job view and the AI chat.
For developers: a hint travels with the response, in
Completion under guardrail (read with
Guardrail), and for a stream as the return value of
the generator (Guardrail, once drained). A call
that returns a string, an array, a tool loop or an agent run is wrapped in
Guardrail, which returns the result and the hints
reported during it. To store a refusal, use
Guardrail.