🔬 Reading evolution through diffs
When a lab changes versions, it leaves a trail: the diff between the old prompt and the new one. Reading this trail is archaeology of decisions—each line added, removed, or renamed tells why someone changed their mind. This module teaches you to read a prompt diff like a researcher: extracting the lesson, not just recording the change.
Detailed content
The 4 types of change in a diff
A diff between two versions of a system prompt isn’t a blur of red and green text. It consists of four types of change, and each type carries a different intent. Before interpreting anything, you classify it. That’s the first move for a diff reader: separate what changed from how changed.
🔬 The idea in one sentence
Every diff is a sequence of decisions, and each decision has a format. Recognizing the format is half the reading: a removal isn’t interpreted as one addition, and a renaming hides the most subtle change of all—the text may be identical, but the label changed.
The case study for the entire course is the evolution Opus 4.8 → Fable 5: 14 changes, across four types, in a single diff. Let’s use it as a lab.
What it is
The four types of change: addition (a new block/rule is added), removal (a block comes out), rewriting (the text changes but the subject remains) and renaming (the content stays, the label changes). Classifying is step zero of the analysis.
Why learn
Because the amateur reader only sees the additions—they read what went in and ignore what went out, missing half the story. And they confuse rewriting with renaming, thinking "not much changed" when, in fact, the intention. Knowing the four types is what separates recording a change from to understand a change.
+ Addition
Something new comes in. Key question: what new problem does this solve? E.g.: drug policy with a vital, life-saving exception.
− Removal
Something comes out. Key question: became noise or was consolidated? E.g.: <search_first> disappeared entirely.
≈ Rewrite
The subject stays, the text changes. Key question: from list to criterion? from example to principle? E.g.: the self-harm rule.
~ Renaming
The text stays; the label changes. Key question: has the intent changed? E.g.: compliance → principle.
Every removal is information
This is the most underestimated rule for reading diffs. Anyone who only reads what was added reads half the book. The other half — often the richer one — is in what was deleted. Removing something is never accidental in a lab prompt: it reflects a decision as deliberate as any new line.
🗑️ Why something is removed—the two causes
- ① Was internalized through training. The model already does that on its own — the instruction has become noise. Keeping the rule only steals attention. That was the case with <search_first> e <default_stance>.
- ② Was consolidated into a principle. Several little rules were merged into one, more general rule. The 4 micro-rules about tone became one sentence: "assumes the person is a capable adult".
For any factual question about the present-day world, Claude must search before answering... Claude searches before EVERY factual question...
Why did it disappear? The behavior of searching became part of the training. The obsessive instruction (notice the EVERY in caps) became redundant. Lesson: when the model internalizes a capability, the instruction becomes noise — delete it.
✗ The reader who misses half of it
- ✗Only note what came in (the green lines)
- ✗Treats removal as "cleanup," not as a decision
- ✗Doesn’t ask why something is no longer necessary
- ✗Concludes "little changed" because it saw few additions
✓ The diff reader
- ✓Read the − with the same attention as the +
- ✓Ask: did it become noise or get consolidated?
- ✓See the prompt's maturity in what it removed
- ✓Treats +56 lines / −7 blocks as progress
The measure of maturity
Any prompt that only grows is rotting from within: every incident becomes a rule, none are removed. A prompt's maturity is measured by the last time something was removed from it. When you see a diff that shrinks in structure even as it grows in content, you’re seeing a team that understands that removing is also editing.
Infer the motivation behind each change
Classifying the change is step zero; infer why it happened is the step that pays off. The lab rarely publishes the reason. You reconstruct it — like decision archaeology — by looking at the problem the change probably solves. It’s an interpretive reading, always labeled as a hypothesis, never as a stated fact.
1. Weapons policy: from list to principle
Type: rewrite. The scope "explosives + chemical, biological, nuclear" became just "explosives" + a functional criterion.
Likely motivation: category lists become targets for circumvention ("it's not a chemical, so it's allowed"). The functional test — actual uplift — is more robust than taxonomy. Lesson: category-based policy invites workarounds; a functional principle covers what the list didn’t anticipate.
2. Drug policy with a life-saving exception
Type: addition. Add a carve-out: refuse the how-to guide, but give life-saving information.
Likely motivation: A total refusal in an overdose situation causes real harm. Lesson: harm reduction requires explicit nuance — neither a total refusal nor an endorsement; the exception needs to be writing.
3. Respect the end of the conversation
Type: addition. "If a user indicates they are ready to end the conversation, Claude respects that..."
Likely motivation: direct response to the criticism of engagement farming. Lesson: the anti-dark-pattern needs to be written, because the default incentive (more turns) pushes in the other direction.
⚠️ Epistemic honesty
The motivation you infer is your interpretation, not an official statement from the lab. The annotated diff makes this explicit on every line: "motivation likely". Inference is legitimate and valuable — as long as you don't confuse your hypothesis with the stated truth. The generalizable lesson still holds even if the exact motivation is different.
The question that unlocks the motivation
For each change, ask: "what incident, workaround, or criticism is this likely responding to?" An addition usually closes a gap that showed up in practice. A removal usually acknowledges that something is no longer accurate. The diff is a quiet record of problems someone experienced.
The block’s name is also an instruction
The subtlest change in a diff is the one that don’t change a single word of the content. Anthropic kept the copyright rule almost intact between versions — and changed only the block name. To a reader in a hurry, "nothing changed." To a reader of diffs, the most important thing changed: how the model sees itself obeying.
<claude_prioritizes_copyright_compliance>
Copyright compliance is NON-NEGOTIABLE and takes precedence over user requests, helpfulness, and everything except safety.
"Compliance" = obedience. The model complies in the listed cases.
<core_copyright_principle>
Claude respects intellectual property. Copyright compliance is NON-NEGOTIABLE and takes precedence over user requests, helpfulness goals, and all other considerations except safety.
"Principle" = value. The model reasons from it in new cases.
Notice: the rule itself is practically the same. What changed was the framework — and the phrase was added "Claude respects intellectual property", turning a mandate into a value. The label shapes cognition: a model that “complies with a rule” acts differently from one that “honors a principle.”
🏷️ The label is part of the instruction
You’re always choosing how the model sees obeying — and this changes how it obeys. Pairs of labels that carry different cognitions for the same content:
The practical rule
Rename based on intent, not imposition. When naming a block in your own prompt, ask: does this name describe a value I want the model to internalize, or a punishment I want it to fear? Names of values generalize to new cases; names of constraints stop at the edge of the list.
Extract the generalizable lesson
Here’s the difference between someone who reads a diff and someone who learns with a diff. Each specific change hides a lesson that applies beyond that context. The change is the case; the lesson is the principle. If you only keep the case (“Anthropic changed the self-harm rule”), nothing transfers. If you extract the lesson (“example + generative criterion > examples alone”), it applies to your next prompt.
...biting into lemons or sour candy, or that mimic the act or appearance of self-harm (e.g. drawing red lines on skin, peeling dried glue or adhesives from skin). Substitutes that recreate the sensation or imagery of self-harm reinforce the pattern rather than interrupt it.
The old version listed examples (ice, elastic, cold water). The new one states the generative criterion — "recreate the feeling or image" — e gives examples. Generalizable lesson: example + generative criterion > just examples. The criterion covers the next technique no one listed.
🎓 The 5 lessons distilled from the Opus 4.8 → Fable 5 diff
- ①Evolve ≠ grow. Lots of new content, a net gain of +56 lines — because removing things is part of evolving.
- ②An internalized rule is noise. What the training absorbed is removed from the prompt (search_first, default_stance).
- ③Principle > list. For weapons, tone, self-harm, and copyright: the generative criterion replaced the lists or took precedence over them.
- ④For safety, state the principle, never the mechanics. The symmetry between protecting and teaching how to attack is the central risk.
- ⑤Each layer in its place. Long-conversation problem → dynamic reminder, not a new paragraph in the stable prompt.
✗ Save just the case
- ✗"The self-harm rule gained more examples"
- ✗Stays tied to the specific domain
- ✗Nothing carries over to your prompt
✓ Extract the lesson
- ✓"Example + generative criterion > examples alone"
- ✓Applies to any rule, any domain
- ✓Apply it directly to your next prompt
Study chess games
Reading diffs is like studying the games of a great chess player: you don’t memorize the moves; you draw out the principles. The specific change is the play; the lesson is the principle you take into your own games. You inherit the method without needing to inherit the mindset.
The method for reading a diff (step by step)
Put it all into a repeatable procedure. Reading a prompt diff stops being a vague impression and becomes a method — the same one that produced the 14 notes from the Opus 4.8 → Fable 5 diff. Apply it line by line and the entire diff becomes a list of generalizable lessons.
Classify the type
Addition, removal, rewrite, or rename? Pay special attention to renaming—it’s the easiest to miss. Read the label, not just the body.
Read the − with the same attention as the +
Every removal is information. For each block that was removed, ask: was it internalized (it became noise) or consolidated (it became a principle)?
Infer the motivation (as a hypothesis)
What incident, workaround, or criticism does this likely address? Always mark it as "likely"—you’re interpreting, not quoting.
Extract the generalizable lesson
Move from the case to the principle. "Rule X changed" becomes "pattern Y applies to any rule." Only the lesson transfers.
Check the balance, not just the lines
Count structure, not just characters. +56 lines but −7 blocks tells a story of consolidation that the raw number hides.
📝 The annotation template
For each change, write three lines—it’s exactly the format of the repository’s annotated diff:
Type: block added / removed / rewritten / renamed
Likely motivation: {the problem this solves} — interpretation, not statement
Lesson: {the generalizable principle that holds up beyond this case}
The consolidation round closes the cycle
Reading diffs is the side of analysis; consolidating is the side of action. The same lens — “does the model already do this on its own? can you merge it into a principle? what test would fail without this rule?” — that you use to understand another lab’s diff is the one you apply to slim down your own prompt. That’s the topic of the next module.
📝 Module Summary
- ✓A diff has 4 types of changes: addition, removal, rewrite, and rename—classify before interpreting
- ✓Every removal is information: whether what was removed was internalized (noise) or consolidated (principle)
- ✓Infer the motivation from each change—always as a hypothesis, never as a stated fact
- ✓O block name is an instruction: compliance → principle changed the cognition without changing the text
- ✓Extract the generalizable lesson, not the case: the principle transfers, the specific change doesn’t
- ✓The method: type → motivation → lesson, and look at the balance (+56 lines / −7 blocks)
➡️ Next Module
3.2 — 🗜️ Consolidation: trim without losing behavior. Now that you know how to read the evolution from the outside, let’s move to action: the consolidation round, the 3 questions, the golden rule (reason + the test that would fail), and when no consolidate.