The naming meeting is a good meeting. Everyone argues productively about the top-level categories. The design gets a kickoff, a document, an announcement, and an owner, briefly. Creation has rituals, budgets, and applause.
Eighteen months later, a new hire asks why the work-tracking system has a category called Growth Squads. Nobody in the room has ever used it. It contains four items, three of them misfiled, one from a project that was cancelled. Its continued existence makes the whole taxonomy slightly harder to trust, and its removal is on no one's list, because retirement has no ritual, no budget, and no owner. So it stays, and it is not alone.
The taxonomy died a year ago. It just has not been informed.
Creation is funded, retirement is not
Every organization has a creation pipeline for structure: proposals, meetings, documents, tooling. Almost none has a retirement pipeline. That asymmetry, not laziness, is why structures accumulate, and it deserves a plain definition: a death rule is a written agreement, made when a structure is created, that states what triggers its retirement, who executes it, and what happens to its contents.
Three clauses. Trigger: the observable condition that means this category, tag, folder, or hierarchy has stopped earning its place, such as zero items filed in two quarters, or the program it served ending. Executor: the named person who performs the retirement, because unowned rules are decorative. Disposition: where contents go, merge, archive, or delete, decided in advance while the stakes are low.
Without those clauses, the default death rule operates instead, and it is a bad one: structures die when their last advocate gets distracted, which is to say they never die at all. Dead categories do not decompose. They persist, accumulate misfiles, and teach every newcomer that the taxonomy is partly fiction, which degrades the parts that are true.
This is structure-level Every Edge Case Is a Decision the System Never Owned. The edge case was the category the system kept but no longer meant. It is also the quiet sibling of Rooms Drift When No One Owns the Consequence: a room nobody owns drifts, and so does a taxonomy, one unretired category per quarter.
Why do stale categories do so much damage?
Because a taxonomy is a trust instrument, and stale entries tax every use.
Users do not know which categories are fiction. That is the core mechanism. Facing twelve categories, a newcomer must treat all twelve as live, because fiction and truth look identical from outside. Every dead category therefore slows every filing decision and degrades every search. The taxonomy's job is to compress judgment, current categories; stale categories decompress it back into doubt.
The damage compounds through filing behavior. Uncertain users drop items in the least-wrong-looking place, and misfiles in dead categories are nearly unrecoverable, because nobody audits a category nobody believes in. Within a year, the structure contains rooms that are technically present and practically haunted. And the rot spreads by example: if Growth Squads is fiction, maybe Growth is too, and the taxonomy's authority leaks from the edges inward.
The Roadmap and the Codebase Are Different Trees described how a tree rots at the rate of its most volatile layer. This is rot's second face: not churn from the top, but sediment from the bottom, the slow accumulation of structure that outlived its meaning and was never retired. Both faces have the same cure, and it is written down, in advance, at creation time.
The disposition problem is why nobody retires anything
Retirement stalls on one question: what happens to the contents? Answer it at creation and the resistance vanishes.
The strongest dispositions are the cheap ones. Merge-and-redirect: the category folds into its nearest live neighbor, and existing references follow automatically, which is why the rule must exist while the stakes are low and the contents are few. Archive-and-stamp: the structure moves to read-only with its name and date, an honest fossil rather than a live lie. Delete-with-notice: for young categories with trivial contents, the cleanest death, announced before it happens.
What does not work is the reorganization project, the quarterly ambition to redesign the whole taxonomy at once. Reorgs are expensive, political, and therefore rare, which is precisely how eighteen months of sediment builds between them. The death rule distributes the reorg into a thousand tiny, unpolitical, pre-agreed retirements. That is the design insight: retirement must be cheaper than persistence, or persistence wins by default.
What this is not
Not a call for minimal taxonomies only. Rich structures are fine when they carry live meaning; the argument is about lifecycle, not size. A twenty-category scheme with a working death rule stays healthier than a five-category scheme with none.
Not an argument that all stuctures deserve rescue. Some should be deleted outright, contents included, and the death rule should be honest about which ones. The archive disposition is for contents with history; it is not a polite synonym for never.
And not only a work-tracking concern. The rule applies wherever structure accretes: folder trees, service catalogs, alert channels, documentation spaces, tag systems, team names, the metrics dashboard's page list. Each is a taxonomy, and each currently has a creation ritual and no death ritual.
The move
For the next structure anyone proposes, add one paragraph to its design document:
- Trigger: name the observable condition that retires this structure (zero use across two quarters, program end, successor live).
- Executor: one named owner who performs retirements, with the role, not the person, holding the duty.
- Disposition: merge-and-redirect, archive-and-stamp, or delete-with-notice, chosen now, while the structure has four items instead of four hundred.
Then run the backlog pass once: list every existing category, tag, and folder; mark anything with zero use in two quarters; execute the pre-agreed disposition. Expect the first pass to remove a third of the structure. Expect the taxonomy to get more useful as it shrinks.
Take-home
- Open your tracker's category list and count the ones used in the last quarter. The remainder is your sediment, and every entry taxes every filing decision.
- Amend the next structure proposal with trigger, executor, disposition. Three lines. If the room resists writing them, the structure was never meant to be maintained.
- Schedule the retirement pass quarterly. It should be boring. If it is dramatic, retirement has been deferred too long again.
Related reading:
- Every Edge Case Is a Decision the System Never Owned
- The Roadmap and the Codebase Are Different Trees
- Rooms Drift When No One Owns the Consequence
- Most Technical Debt Is Deferred Judgment, Not Bad Code
- Never Hand-Maintain What the System Can Derive
- Every Sync Is a Third System
- Right Decisions Expire
If your structures are accurate everywhere except the places people actually look, the missing piece is not discipline. It is a death rule that was never written. If you want help installing retirement clauses into your taxonomies before the next layer of sediment sets, book a discovery call.
FAQ
What is a death rule in taxonomy design?
A written agreement created alongside the structure itself, naming three things: the trigger that retires it, such as zero use for two quarters; the executor who performs the retirement; and the disposition of contents, merge-and-redirect, archive-and-stamp, or delete-with-notice. Without it, the default rule is that structures never die, and stale categories accumulate.
Why do stale categories damage a taxonomy?
Because users cannot tell live categories from dead ones, so every dead entry taxes every filing and search decision. A taxonomy compresses judgment; stale entries decompress it into doubt. Misfiles in dead categories are also nearly unrecoverable, since nobody audits a category nobody believes in.
How do you retire categories without a big reorganization?
By pre-agreeing the disposition at creation time, when contents are few and stakes are low. The death rule distributes the reorganization into many tiny, unpolitical retirements executed quarterly. Retirement must be cheaper than persistence, or persistence wins by default.
Which structures need death rules?
Anything that accretes: work-tracking categories, folder trees, tag systems, service catalogs, alert channels, documentation spaces, team names, dashboard pages. Each is a taxonomy with a creation ritual and, usually, no retirement ritual. The rule is three lines in the design document, not a process.