🛡️ Safety by principle, not mechanics
There’s a fatal asymmetry in every safety text: what teaches a well-intentioned reader often protecting themselves weapon a malicious one. When a lab prompt deals with child protection, self-harm, or abuse, it resolves this asymmetry with a precise design choice — declare the principle, never the detection mechanics. This module distills that discipline from the Fable 5 diff.
Detailed content
The child-safety lesson: stay at the level of the pattern
Between Opus 4.8 and Fable 5, the child safety section went from 5 to 7 rules. Two of the new ones don't add more prohibitions — they add a writing discipline. The model should stay at the level of the pattern, not compile categorized lists of verbatim lines; and when refusing for child safety, it should state the principle, not the detection mechanics. This is the first appearance of a rule that applies to any safety domain.
🛡️ The idea in one sentence
A well-written safety text protects without revealing how to detect. Listing the exact signals that trigger a refusal—the phrases, the verbatim patterns the defense looks for—gives the attacker a map of what to avoid. Staying at the pattern level is what separates a system that educates of one that weapon.
The case study is the diff Opus 4.8 → Fable 5, change #7 (child safety): Anthropic didn’t tighten the list — it tightened the way of writing about the list.
"Claude stays at the pattern level… does not compile categorized lists of verbatim lines"
"states the principle rather than the detection mechanics"
Notice what no is here: no example sentence, no listed sign. The rule follows itself—it describes the discipline without demonstrating it with dangerous material. Lesson: when it comes to security, the form of the rule matters as much as its content.
What it is
Stay at the pattern level is to write the safety rule in terms of principles e boundaries — "protect children from grooming" — and never in terms of mechanics — "detect these specific phrases". The principle guides judgment; the mechanics would be a checklist that both defense and attack can read.
Why learn
Because the instinct of someone who writes rules is to opposite: be specific, list cases, and give examples to "leave no room for doubt." In almost every domain, this is good — an example + a generating criterion is better than just a criterion. But in security, specificity has an inverted cost: every concrete example of how something being detected is also an instruction to how to escape. Knowing when to fall back on the principle is a rare skill.
✓ At the pattern level
- ✓Name what to protect (children, the grooming boundary)
- ✓Describe the nature of the harm, not the exact trigger
- ✓Covers techniques no one has listed yet
- ✓Doesn’t leave anything for the attacker to copy
✗ At the mechanics level
- ✗List verbatim trigger phrases that cause refusal
- ✗Compiles ready-made categories of lines and techniques
- ✗Only takes what’s on the list — fails on everything else
- ✗Provides the exact map of what to avoid
Symmetry is dangerous
Here’s the principle that explains all the others. In security, there’s a fatal symmetry: the same text that teaches a well-intentioned reader to defend themselves teaches a malicious one to attack. A guide on "how to recognize grooming" is, read backward, a guide on "how to groom without being recognized." Defense and attack read the same manual — and that’s why spelling out the mechanics is handing half the work to the adversary.
🪞 The mirror: what educates, arms
The symmetry is not a writing flaw — it is a property of the information itself. Security knowledge that describes mechanisms is inherently bidirectional. That’s why Fable 5’s child-safety rule doesn’t say "explain the warning signs clearly"; it says the opposite — stick to the pattern, no compile the list.
✓ Asymmetric information (safe)
- ✓Helps defenders more than attackers
- ✓The principle guides judgment; it doesn’t give you a recipe
- ✓"refuse anything that could facilitate harm to children" — clear, but no map
- ✓Works even against the new technique
✗ Symmetric information (dangerous)
- ✗Helps attackers as much as it helps defenders
- ✗The detailed mechanics are a reversible tutorial
- ✗"refuse if the sentence contains X, Y, Z" — an easy-to-circumvent list
- ✗Fails against anything outside the list
The symmetry test
Before writing any detailed security rule, ask one question: "if I switch who reads this—from the person I protect to the person I protect them from—does this text help the wrong side?" If the answer is yes, you’re at the level of mechanics. Move up to the principle: say what don’t allow it, no how recognize it.
State the principle, never the detection mechanism
The practical rule that follows from the symmetry is straightforward: state the principle, never the detection mechanics. The principle is what e o reason — durable, generalizable, safe to write. The mechanics are the how to detect — fragile, easy to work around, and dangerous to write. Fable 5 explicitly chooses the first: "states the principle rather than the detection mechanics".
"states the principle rather than the detection mechanics"
Seven words that carry the entire discipline. principle = the value that generalizes; detection mechanics = the checklist that arms it. Choosing between the two is the difference between a rule that ages well and one that becomes an evasion manual the day it leaks.
✓ State the principle
Says what e why. Guides judgment in new cases.
✗ Detail the mechanics
Says how to detect. It becomes a workaround list and a reverse roadmap.
Notice the connection to the entire Trail 3: this is the same move principle > list that you’ve seen with weapons, tone, and self-harm — but in security it stops being a matter of stylistic preference and becomes a defense requirement. In weapons policy, listing categories invites workarounds. In child safety, listing the mechanics weapon the workaround. The cost of the list is higher here.
Principle covers the unforeseen case
The advantage of the principle is not just security — it is coverage. A mechanics list protects against exactly what’s in it and nothing else. One principle — "don’t facilitate harm to children" — captures the technique that appeared yesterday and the one that will appear tomorrow, because it judges by nature of the request, not its exact form. The principle is the only defense that scales.
The refusal trigger: reframing is the signal
This may be the most elegant sentence in the entire prompt collection. Instead of listing what to refuse—which would fall back on mechanics—Fable 5 sets up a introspective trigger: if the model catches itself mentally reframing a request to make it acceptable, that reframing itself is the signal to REFUSE, not a reason to proceed. The warning sign isn't a word on the list — it's the effort to twist the request until it fits.
"If Claude finds itself mentally reframing a request to make it appropriate, that reframing is the signal to REFUSE, not a reason to proceed."
The genius lies in where the trigger lives: within the reasoning itself, not in an external rule. No one needs to anticipate the exact wording of the attack. The model only needs to notice that is working to justify a request — and this is detectable from within, without any list.
🚦 Why this is so powerful
A well-crafted malicious request almost never arrives raw. It arrives almost acceptable, inviting the model to take the last step: "if I assume it’s platonic…", "if I interpret it as educational…". Each of these bridges is the reframing. Instead of trying to enumerate all possible bridges (infinitely many), the trigger marks the act of building the bridge like the alarm.
The practical rule for your agent
You can install this same trigger in any agent you have. Instead of listing forbidden requests, write: "if you catch yourself rephrasing a request to make it sound acceptable, treat that reframing as the signal to stop—not as permission to continue." It’s a rule of introspection, not a catalog — and that’s why it can’t be bypassed by rewriting the request.
Precaution after a refusal
A refusal isn't an isolated event — it's a state change. Fable 5 adds a rule that most prompts forget: after the model refuses a request for child safety, all subsequent requests in the same conversation are treated with extreme caution. The context doesn't return to normal. Someone who just tried once tends to try again from another angle—and the system needs to remember that.
"Once Claude refuses a request for reasons of child safety, all subsequent requests in the same conversation must be approached with extreme caution."
The refusal changes the baseline of the entire conversation. It recognizes that an attack rarely gives up at the first "no"—it rephrases, splits up the request, tries from another angle. Persistent caution closes the back door.
The first refusal happens
The model refuses a request for child safety. So far, that's the default behavior of any decent system. What changes is what comes after.
The baseline rises
The conversation doesn't return to a neutral state. From this point on, each new request carries the context of the previous attempt. The benefit of the doubt deliberately shrinks.
The rephrased request is treated with caution
If the next request could facilitate harm—even if split up, even if disguised as something else—it’s also refused. Rephrasing doesn’t reset the suspicion; it confirms it.
⚠️ The refusal has short-term memory
The common mistake is treating each turn as independent—evaluating request N without remembering what happened in request N−1. In sensitive domains, this is a vulnerability: an attack split into harmless parts gets through because each part, on its own, seems acceptable. The precaution after refusal is the antidote to the sliced-up attack — it makes the system remember.
The generalizable lesson
For any agent handling delicate boundaries, the rule is: a refusal changes the state of the conversation, not just that turn. After saying no to something serious, increase caution for the rest of the session. Context is part of safety—not just the isolated request on the table.
The refusal tone: conversational, without bullet points
Refusing well isn’t just about deciding what — is deciding how it sounds. Fable 5 keeps a guideline that's easy to underestimate: the model can maintain a conversational tone even when it can't or won't help. And there's a counterintuitive formatting rule behind this: when refusing, don’t use bullet points. The list, which organizes things in other contexts, here hardens — turns a human refusal into a bureaucratic sentence.
"Claude can keep a conversational tone even when it's unable or unwilling to help with all or part of a task."
A refusal doesn’t end the conversation. The person is still treated like a person.
"Claude also never uses bullet points when it's decided not to help the person with their task; the additional care and attention can help soften the blow."
Prose softens; lists harden. When refusing, write in sentences.
✓ The refusal that preserves the connection
- ✓Write in prose, in complete sentences
- ✓Keeps the conversational tone without turning into a legal notice
- ✓Clearly says no, but with care
- ✓Treats the person like a person, not a case
✗ The refusal that becomes a wall
- ✗Dumps bullet points of “reasons why I can’t”
- ✗Sounds like terms of service, not a person
- ✗Use the list to protect yourself, and make the hit harder
- ✗A moralizing lecture instead of a simple refusal
🤝 Why bullet points in particular
A bullet point is how someone sounds when they want distance. In a refusal, it reads like a numbered sentence—cold, procedural, defensive. Prose, by contrast, conveys the "extra care and attention" that softens the blow: it recognizes the person on the other side instead of brushing them off. That's why the rule is specific—not "avoid lists in general" (that already applies to everything else), but never use bullets when you’re saying no. At exactly the moment when the temptation to protect yourself with a list is strongest.
📝 Module Summary
- ✓Stay at the pattern level: don’t compile verbatim line lists — state the principle, not the detection mechanics
- ✓Symmetry is dangerous: what educates a well-intentioned reader arms a malicious one—defense and attack read the same manual
- ✓State the principle (what and why), never the mechanics (how to detect): the principle covers unforeseen cases
- ✓O refusal trigger: if you catch yourself reframing the request to make it acceptable, that reframing is the signal to REFUSE
- ✓Precaution after a refusal: the refusal changes the state of the entire conversation — extra caution in all subsequent requests
- ✓Tone when refusing: keep it conversational and in prose — no bullet points, which make the “no” firmer
➡️ Next Module
3.4 — 🪜 Priority and layers. You saw what protect and how writing the rule; now let’s move on to architecture: how a prompt resolves conflicts between rules, which layer takes precedence over which, and why each instruction has its proper place in the stack.