Your hierarchy is not a monument. It is scaffolding.
Every knowledge system you build will eventually betray you. The categories that made perfect sense six months ago start creaking under the weight of new information. Items get shoved into folders where they "sort of" fit. You create a subcategory called "Miscellaneous" or "Other" and tell yourself you will reorganize later. You won't — not until the friction becomes unbearable.
This is normal. It is not a failure of your original design. It is evidence that you have learned something your old structure could not anticipate. The question is whether you respond to that evidence by forcing new knowledge into old containers or by restructuring the containers themselves.
Jean Piaget identified this exact fork in the road seventy years ago. He called the two responses assimilation (fitting new information into existing schemas) and accommodation (restructuring the schemas to fit new information). Both are necessary. But most people default heavily toward assimilation because it is cheaper in the moment — no reorganization, no broken links, no disorientation. The cost shows up later: a knowledge system riddled with exceptions, workarounds, and items filed under categories they have long outgrown.
Hierarchy refactoring is the deliberate practice of accommodation applied to your epistemic infrastructure. When the structure becomes awkward, you restructure it rather than forcing things to fit.
Five signals your hierarchy needs refactoring
Not every moment of friction warrants a restructure. You need to distinguish between normal growing pains and genuine structural failure. Here are the five signals that your hierarchy has outgrown its design:
1. The exception rate is climbing. Every hierarchy produces some exceptions — items that don't fit neatly. That's fine. But when you find yourself mentally annotating more and more items with "well, this also relates to X" or "this could go in either place," the exceptions have become the pattern. Martin Fowler, who literally wrote the book on software refactoring, describes this as a "code smell" — a surface signal of a deeper structural problem. In software, the equivalent is the "Refused Bequest" smell: when a subclass inherits behavior from its parent but doesn't actually use most of it, the hierarchy is wrong. In your knowledge system, the equivalent is a category where half the items only loosely belong.
2. Cross-cutting concerns dominate. You have a note about "leading distributed teams" and it legitimately belongs under Leadership, Communication, Remote Work, and Team Structure. One cross-cutting item is normal. When most of your recent additions cross-cut multiple categories, your hierarchy's organizing axis no longer matches how you actually think about the domain. In software architecture, cross-cutting concerns — logging, authentication, error handling — are recognized as aspects that cannot be cleanly decomposed into a single branch of the hierarchy. The same principle applies to knowledge: when a concern cuts across your entire tree, it is telling you the tree needs a different trunk.
3. Orphan nodes accumulate. Items with no clear parent, sitting in "Inbox" or "Unsorted" for weeks. A healthy capture workflow produces temporary orphans. A broken hierarchy produces permanent ones — items you have looked at multiple times and still cannot place, not because you are lazy but because no existing category accurately describes them.
4. Depth without utility. You have nested five levels deep — Category > Subcategory > Sub-subcategory > Topic > Sub-topic — and navigating to anything requires remembering the exact path. Deep hierarchies feel rigorous. They often indicate that you are over-specifying structure instead of letting the content's natural relationships guide organization. If you cannot explain why a particular level of nesting exists and what decision it helps you make, that level is noise.
5. You avoid adding new material. This is the most damning signal, and the easiest to miss. When your knowledge system creates friction at the point of capture — when you hesitate to save a note because you don't know where it goes — the hierarchy is actively suppressing learning. A well-structured system should make capture easier, not harder.
How to refactor: small moves, preserved meaning
Software refactoring offers a direct methodology you can port to knowledge work. Fowler defines refactoring as "a controlled technique for improving the design of an existing code base by applying a series of small behavior-preserving transformations." The key phrase is behavior-preserving: you change the structure without changing the meaning.
Applied to your knowledge hierarchy, this means:
Rename before you reorganize. Often the problem is not the structure but the labels. A category called "Strategy" that contains both high-level business strategy and tactical project planning doesn't need to be split — it needs its name to be more specific, and the tactical items need their own clearly labeled sibling node.
Extract, don't delete. When a category has grown too large, pull out a coherent subset into its own node rather than trying to re-sort everything at once. This is the knowledge equivalent of Fowler's "Extract Method" refactoring — you take a chunk that has its own coherent identity and give it a name and a home.
Flatten before you deepen. If you are tempted to add another nesting level, first try pulling the contents up one level and using tags or links to preserve the relationships. Deep hierarchies are expensive to maintain. Flat hierarchies with rich cross-references are cheaper and more flexible.
Restructure at the point of pain. Don't reorganize proactively across your entire system. Restructure the specific node that is causing friction, right when you feel the friction. This keeps the cost small and the signal fresh — you remember exactly why the old structure failed.
Batch the strays after the restructure. Once you have restructured a section, sweep through your orphan items and recent captures. Many of them will now have an obvious home. If they don't, that's information too — your restructure may need another iteration.
Piaget was right: accommodation is how schemas mature
Piaget's model of cognitive development rests on an engine called equilibration — the drive to resolve the tension between what your schemas predict and what reality delivers. When a new experience fits your existing mental model, you assimilate it: fast, cheap, no restructuring required. When it doesn't fit, you experience disequilibrium — cognitive discomfort that signals your model is inadequate.
Accommodation is the resolution. You restructure your schema so it can handle the new data. Critically, the resulting schema is not just "updated" — it represents what Piaget called a higher level of equilibrium, because it can successfully handle a wider range of experience than the schema it replaced.
This maps directly to hierarchy refactoring. Your old hierarchy (schema) worked for a while. New knowledge creates exceptions (disequilibrium). You can keep forcing items into old categories (assimilation), or you can restructure the hierarchy to handle the fuller range of what you now know (accommodation). The restructured hierarchy isn't just different — it's stronger. It reflects a more accurate model of the domain.
Conceptual change researchers Strike and Posner (1992) identified four conditions required for accommodation to occur: the learner must be dissatisfied with the existing schema, the new schema must be intelligible, it must be plausible, and it must be fruitful — meaning it opens up new territory. Apply this to your hierarchy: don't restructure until the old structure is genuinely inadequate (dissatisfied), you can articulate the new structure clearly (intelligible), it handles your existing items without loss (plausible), and it makes future capture easier (fruitful).
The Zettelkasten counterpoint: do you even need a hierarchy?
Niklas Luhmann's Zettelkasten — 90,000+ notes maintained over 40 years — had no hierarchy in the traditional sense. As Sonke Ahrens describes in How to Take Smart Notes, the system grew "bottom-up" through organic connections rather than top-down through predetermined categories. Topics and arguments developed based on the evolving web of connections, and unexpected ideas emerged as opportunities rather than filing errors.
This is not a contradiction of hierarchy refactoring — it's the limit case. Luhmann replaced rigid hierarchy with a network of atomic notes connected by context. The "refactoring" happened continuously and locally: each new note was positioned relative to its neighbors, and clusters of related notes formed emergent structure that could shift without reorganizing the whole system.
Tiago Forte's progressive summarization represents a middle path. Rather than restructuring categories, you progressively distill individual notes — bolding key sentences, then highlighting the most important bolded sentences, then writing a summary. The structure remains stable while the signal-to-noise ratio improves within each node. Forte's approach is what you might call "soft refactoring" — you aren't moving items between categories, but you are restructuring how attention flows within the existing structure.
The lesson: hierarchy refactoring is one tool in a larger toolkit. Sometimes the right move is restructuring the tree. Sometimes it's adding cross-references that make the tree's limitations irrelevant. Sometimes it's flattening the tree entirely and replacing it with a network. The signal that tells you which approach to use is the same signal that tells you to refactor: friction at the point of use.
AI as a refactoring partner: the Third Brain approach
This is where AI transforms from a search tool into a structural collaborator. An AI operating on your externalized knowledge system can detect refactoring signals that you are too close to see.
Pattern detection across scale. You notice friction in one category. AI can scan your entire system and identify that the same friction pattern — high exception rates, cross-cutting items, orphan accumulation — exists in four other categories, all traceable to the same root cause: your organizing axis shifted six months ago when you changed roles, but your hierarchy still reflects your old role's concerns.
Alternative hierarchy generation. Enterprise knowledge management tools already use techniques like BERTopic — a topic modeling approach that identifies hierarchical relationships from document embeddings and clustering — to propose alternative taxonomies from the same underlying data. Applied to your personal knowledge system, AI can take your existing items and show you three or four alternative hierarchical structures, each optimized for a different access pattern. You choose based on how you actually retrieve and use the information.
Impact analysis before restructuring. In software, refactoring tools show you every place a change will propagate before you make it. AI can do the same for your knowledge hierarchy: "If you split 'Strategy' into 'Business Strategy' and 'Project Tactics,' here are the 23 notes that would move, the 7 that would need to be tagged with both, and the 4 links from other notes that would need updating." This turns restructuring from an anxiety-inducing leap into a predictable, bounded operation.
Continuous accommodation signals. The most powerful application is not restructuring itself but knowing when to restructure. AI can track your exception rate over time, flag categories where the orphan count is growing, and surface the question — "Your 'Research Methods' category has had 12 new items in the past month, and 8 of them are tagged with categories outside Research Methods. Do you want to review the structure?" — before the friction becomes debilitating.
The pattern here echoes what enterprise taxonomy teams have discovered: AI doesn't replace human judgment about how to organize knowledge. It makes the signals visible, generates options, and reduces the cost of execution. The restructuring decision remains yours.
The refactoring mindset
Hierarchy refactoring requires a specific psychological stance: your organizational structures are hypotheses, not conclusions. Every category you create is a bet about how a domain is organized. Some bets pay off for years. Others need revision in weeks. Neither outcome reflects on your intelligence or competence — it reflects on how much you have learned since the last restructure.
Martin Fowler's core insight about software applies directly: "You can even take a bad design and rework it into a good one." The emphasis is on rework. Not start over. Not abandon. Rework — incrementally, at the point of pain, preserving what works while restructuring what doesn't.
The previous lesson (L-0273) taught you to override when inheritance fails — to make explicit exceptions rather than letting them remain implicit. This lesson takes the next step: when the exceptions accumulate to the point where they outnumber the rules, stop overriding and restructure the hierarchy itself. And the next lesson (L-0275) takes you further still: recognizing that the same data often supports multiple valid hierarchies, and the choice between them depends on what you are trying to do, not on what the data "really is."
Your hierarchy is scaffolding. It exists to support the work. When the work outgrows the scaffolding, you don't shrink the work. You rebuild the scaffolding.