# Prompt Rules Decay With Model Versions Date Every Never ## Claim A prompt rule written to correct one model generation's bias can amplify the opposite bias in the next generation, so a long-lived instruction set needs a version tag and a reason attached to every "never," not just a rule, because the rule that was correct is exactly the one nobody thinks to re-examine. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to any standing instruction meant to counteract a specific observed model behavior — formatting suppression, verbosity limits, tool-use nudges — not to rules stating durable values or facts. - Strongest where the rule targets a behavior the vendor itself later reports has reversed, since that's direct evidence the correction has outlived its target. - The fix isn't "review everything constantly" — it's attaching a date and a one-line reason to each behavior-correcting rule so a later reviewer can check whether the target behavior still exists, rather than re-deriving the whole rationale from scratch or leaving it unquestioned indefinitely. - Doesn't apply to rules with no model-behavior target at all (e.g., "never commit secrets") — those don't decay because they aren't correcting for a moving target. ## Evidence > [!quote] ID:rw_01m1gzqdxaswbr8x2j79k96ess > "Earlier models overused bullets and bold in chat, and many prompts carry anti-formatting rules written to hold that down. Claude Fable 5.1 leans the other way: it uses bold less and is less likely to reach for headers, lists, or quotation marks. If your prompt contains anti-formatting language, remove it or replace it with a rule that says when specific formatting is appropriate" Anthropic's own migration guide for Claude Fable 5.1 names three instances in one document where advice correct for Fable 5 now works against the new model: anti-formatting rules now over-suppress structure the model already under-uses; early context compaction, once a cost-saving move, may now waste context because cache reads got cheaper; and routing cheap work to a smaller model may now lose to running Fable 5.1 itself at low effort. Each reversal is presented as a fix, with no acknowledgment that the underlying instruction-decay problem is general. ## Links - [[3. Resources/Permanent Notes/State a Model Cannot Hold Belongs in Version-Controlled Files]] — because extends: both treat a long-lived AI-assisted project's instructions as artifacts requiring the same discipline as code — versioned, diffable, and reviewable — rather than as settled prose. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — because this is a maintenance discipline specifically for prompt-and-instruction infrastructure, which is exactly the kind of durable knowledge-work practice the MOC tracks. - [[3. Resources/Permanent Notes/Workaround Guidance Outlives the Weakness It Was Written For]] — why the dating discipline is needed at all: the pain of adding an instruction is immediate and nothing in normal work ever prompts its removal. ## Tests / falsifiers - Track whether a dated, reason-tagged CLAUDE.md rule actually gets revisited at the next model transition, versus being carried forward unexamined anyway — if dating doesn't change reviewer behavior, the mitigation doesn't work as designed. - Find a rule that has remained correct across multiple model generations despite targeting a specific behavior — would show decay isn't universal and some corrections are more durable than others, which would help distinguish which rules need dates most. ## Source - [[3. Resources/Readwise/Articles/Prompting Claude Fable 5.1]] — Anthropic's migration guide for Claude Fable 5.1, platform.claude.com, captured 2026-09-02. Vendor documentation; effect-size claims ("drop substantially," "no measurable change") are asserted without published numbers — treat as "worked on Anthropic's evals" and verify against your own transcripts before relying on the specific magnitudes.