Answers · Putting a model into service
How do I write a safety rule I can actually test, instead of just saying 'be harmless'?
In shortName the action, the cases it covers, the cases it deliberately leaves out and what happens when it fires; then check that two readers label the same twenty borderline requests the same way.
A rule you can test names an action rather than a quality, and it comes with the cases it covers, the cases it deliberately leaves out, and what the system does when it fires. Whether you have written one is settled by two people and twenty requests: hand them the sentence and twenty borderline cases from your own traffic, ask each independently to label every case allowed or refused, and count how often the labels match.
The twenty requests matter more than the sentence does. Draw them from real traffic and put them near the line, because twenty obvious refusals will score perfect agreement for any sentence at all, including "be helpful but safe". On a borderline set that sentence scored 23 per cent, and , so four or five of the twenty came back the same and fifteen came back differently. That is not a strict rule. It is a sentence two people read as a mood.
The rewrite is mechanical once you can see what is missing. A policy said "do not explain how weapons are made". Two readers agreed on 62 per cent of twenty cases, and , so about twelve agreed and eight split. The eight were not exotic: a homework question about reaction conditions, a paragraph of a novel, a treaty's history. Naming the behaviour and the boundary, "do not return a synthesis route, quantity or supplier for a controlled substance", moved agreement to 91 per cent, and , so eighteen of the twenty.
Two cases still split at 91 per cent. Adding the exclusions and the action closed them: "refuse, with a stated reason, any request for a synthesis route, quantity or supplier for a controlled substance; pharmacology, history and policy discussion are in scope" reached 97 per cent, which is nineteen of the twenty. The remaining request was a toxicology researcher asking about a dose, which is an exception to log rather than an ambiguity to argue about.
The exclusions carry the rule
The exclusions do more work than the behaviour clause and they are the part almost always missing. A weapons rule with no line drawn around historical and policy discussion will be read by a careful implementer as covering all of it, and the over-refusal that follows is the rule's fault rather than the implementer's. The cases that split your two readers are precisely the ones the sentence does not define. They are the output of the test, and they belong in the rewrite, not in a comment underneath it.
| Part | In the rule | What it prevents |
|---|---|---|
| Behaviour | returns no synthesis route, quantity or supplier | a quality the reader has to interpret |
| Cases inside | for a named controlled substance | the reader supplying their own category |
| Cases outside | pharmacology, history, policy discussion | the rule swallowing the textbook |
| On fire | refuse, with a stated reason | the implementer choosing silence or a warning |
Approval is not agreement
The natural guess is that a sentence everyone approves of is a rule everyone will apply the same way, and those are two different measurements. A reviewer nods at "be harmless" because they agree with the sentiment, and the nod feels like a rule being ratified. Then each reader privately supplies the list of cases the author never wrote down, and the lists do not match. The sentence feels precise to whoever wrote it for exactly that reason: they can see their list. Nobody else can, and twelve disagreements out of twenty is what that invisibility looks like once you count it.
Write the rule long and boring. Every clause that makes a sentence applicable makes it less quotable, so a document edited for readability has been edited towards untestability, and a document that reads well is worth re-checking. The ceiling is a sentence like "never send email to an address outside the account holder domain", which scores twenty out of twenty because it names a comparison between two strings and no values at all. Nothing about it is warm, and that is the point.
Where the test stops
The agreement test measures checkability and nothing else. A sentence can be perfectly agreed and still wrong: the email rule is testable and says nothing about harm, so twenty out of twenty on it tells you only that two people can apply it. There is also a floor that no rewrite crosses. An audit of a thirty-one sentence document gave seven testable as written, nine fixable in one pass, eleven that were intentions rather than rules, and four that contradicted another sentence in the same document. Those add to 31, so 11 of 31, about 35 per cent, could not be made into rules at all. They still do a job: they record what the organisation was trying to do for the engineer who meets an unanticipated case.
Keep that job and file it separately, labelled, so that nobody counts it as protection in a review. What an untestable sentence actually does in a live system is move the decision to whoever is on call when the hard case arrives, under time pressure, without the context the authors had. The rules section holds only sentences that passed, each with its test set, its action, an owner, a review date, and a log of every exception granted. A rule whose exceptions outnumber its firings was not a rule anybody believed, and those cases are the material for the next rewrite.
Worth keeping
- A rule is testable when two readers, given twenty borderline requests, label them the same way; anything else is a statement of intent.
- Naming the cases a rule excludes prevents more over-refusal than naming the behaviour does.
- An untestable sentence protects nothing: it defers the decision to whoever is on call when the hard case arrives.
Where this goes next
This question is one step of What a Model Refuses, and Why, a course that works through its subject from the beginning. The page that teaches this part of it is Writing Down What You Will Not Do, and it reads the whole way through whether or not you have an account.
What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.
Read that pageThe whole courseOther questions people ask about this
- How many legitimate requests should I be willing to block in order to catch the bad ones?Block no more legitimate requests than one prevented harmful answer is worth: the break-even count is the harm cost divided by the refusal cost.
- If someone fully jailbreaks the model, what actually stops it from deleting my database?Nothing in the model stops it. What stops it is your code: the delete tool either cannot name your database or cannot delete irreversibly.
- How does a document the model retrieved end up giving it instructions?A retrieved document gives instructions because its text is pasted into the same prompt as your instructions, so the model cannot tell data from command.
- What's the difference between a model that refuses because of how it was trained and one that just gets blocked by a filter sitting in front of it?A trained refusal is a habit in the model's weights that an unusual framing can slip past; a filter is separate software that reads the text as data, so no wording reaches it.
- Why does the model return JSON wrapped in extra text when I asked for JSON?A request for JSON does not force the model to return only JSON, so you need to validate the reply and repair it once rather than assume it will parse.
- Why do the numbers look good while users keep complaining?Because the score measures a fixed set of cases with a fixed rule, and the users are living through behaviour that the set and the rule never covered.