Adding A Rule Without Removing One
Every fix adds a rule. No fix removes one. After a year the instructions are longer than anyone reads.
Instruction sets grow monotonically because every correction adds a rule and nothing ever retires one. Past a certain length the rules stop being read in full, which means the newest rule silently competes with the oldest instead of replacing it. Net-zero complexity has to be a rule of its own.
Pattern
Something goes wrong. You write a rule so it does not happen again. This is correct and it works.
Repeat for a year. The instruction file is now several thousand words, every line of it justified by a real incident, and no line has ever been removed.
Why it looks right
Each addition is individually defensible — there is a specific failure behind it, and deleting it feels like inviting that failure back. Nobody ever proposes an edit that makes the rules worse, so the file only grows.
Length also reads as maturity. A long instruction set looks like accumulated experience rather than accumulated sediment.
Why it fails
Attention is the constraint, not storage. Past a certain size, rules stop being read as a set and start being sampled, which means a new rule no longer replaces an old one — it competes with it, and the reader cannot tell which won.
Contradictions arrive quietly. Two rules written eight months apart, both sensible, both live, pointing different directions in the same situation. The system then behaves inconsistently and the diagnosis is nearly impossible, because every individual rule checks out.
Instead
Make the exchange explicit. New rule in, old rule out — net zero. When a new rule is proposed, name what it replaces, tightens or retires:
+ rule 118 (verify export ran before comparing)→− rule 61, now a special case of 118
If nothing can be named, that is a signal worth taking seriously: either the rule is genuinely novel, or the set has grown past the point where anyone can see what is already in it. The second case is the common one.
Two supports make this survivable. Give experimental rules a kill date and a pass criterion at birth, so expiry is the default rather than a decision someone has to defend. And keep a changelog instead of an ever-growing file, so the history stays available without staying in the way.
$ head -12 adding-a-rule-without-removing-one.md
$ cite adding-a-rule-without-removing-one
Citation id SV-0317 is stable. It resolves at
https://stillvalid.dev/c/SV-0317 even if this artifact moves to another section,
which a bare URL does not survive. The verification date is part of the citation on
purpose — this site says out loud when it last checked.
[Adding A Rule Without Removing One](https://stillvalid.dev/patterns/adding-a-rule-without-removing-one) — stillvalid, SV-0317 (anti-pattern, verified 2026-08-14)