Every hierarchy lies about its children
L-0272 introduced a powerful principle: child items inherit properties from their parents. When you file a note under "Cognitive Biases," it inherits the frame that it describes a systematic error in thinking. When you tag a task as "Client Work," it inherits your default billing rate, communication cadence, and quality expectations.
Inheritance is useful precisely because it's automatic. You don't have to re-specify every property on every child. The hierarchy does that work for you.
But here is the problem no one warns you about: some children don't fit. A penguin is a bird that doesn't fly. A square is a rectangle whose sides must be equal. Your Sunday morning routine inherits from "Morning Routines" but violates the assumption that exercise comes first. These aren't edge cases. They're inevitable. Every hierarchy that lasts long enough will produce children that need to differ from their parent.
The question is whether you handle that difference explicitly or pretend it doesn't exist.
Penguins and prototypes: what cognitive science tells us
Eleanor Rosch's research on prototype theory in the 1970s shattered the classical view that categories have crisp boundaries. When Rosch asked 200 American college students to rate how well various items represented the category "bird," robins scored 1.1 on a 7-point scale while penguins and ostriches scored far higher — meaning they were perceived as poor examples of the category. The category "bird" carries inherited properties: has wings, flies, is small-to-medium sized. Penguins violate nearly all of these, yet they're still birds.
George Lakoff extended this work in Women, Fire, and Dangerous Things (1987), showing that human categories are organized around idealized cognitive models — clusters of assumptions that hold for prototypical members but break for atypical ones. A "mother" in the idealized model is simultaneously the genetic parent, the birth parent, the primary caregiver, and the spouse of the father. But adoptive mothers, surrogate mothers, and stepmothers each override different parts of that inherited model. They're all mothers. They just override different properties.
This is the cognitive architecture you're working with every time you organize knowledge. Your categories carry implicit prototypes, and some members will violate those prototypes. Rosch and Lakoff didn't discover a flaw in human thinking — they discovered a structural feature of how categorization works. The override isn't the exception. It's a design pattern you need to handle deliberately.
The override pattern in software design
Software engineering formalized this problem decades ago and has strong opinions about when overrides are legitimate and when they signal a broken hierarchy.
In object-oriented programming, a child class can override a method inherited from its parent. A Bird class might have a fly() method. The Penguin subclass overrides it: penguins don't fly, they swim. This is a clean, explicit override — the exception is documented in code, visible to anyone reading the class, and handled by the system rather than by the programmer's memory.
But Barbara Liskov identified a deeper constraint in 1987, now known as the Liskov Substitution Principle: if your code expects a Bird, you should be able to substitute any subclass of Bird — including Penguin — without breaking the program. If calling fly() on a Penguin crashes the system or produces nonsensical behavior, the hierarchy itself is wrong. The penguin doesn't just override a method; it violates the contract that the parent class promised.
The classic Rectangle-Square problem illustrates this precisely. A square is mathematically a rectangle with equal sides. But if a Square class inherits from Rectangle and you call setWidth(5) followed by setHeight(10), you get a shape that's either not a square (if it allows different dimensions) or not behaving like a rectangle (if setting width also forces height to match). The inheritance relationship is technically true but practically broken.
Martin Fowler's refactoring catalog offers the prescription: when a subclass overrides so much of its parent that the inheritance relationship is misleading, replace the inheritance with delegation. Don't pretend the child is the parent with exceptions. Acknowledge that the child uses some of the parent's behavior while defining its own contract. Fowler calls this "Replace Superclass with Delegate" — a formal recognition that the hierarchy lied, and the override pattern is the correction.
The lesson for knowledge systems is direct: an explicit override is a signal that says "inheritance applies here, except for this specific property, and here's why." An implicit exception is a time bomb — it corrupts the reliability of the hierarchy for anyone (including your future self) who doesn't happen to remember the special case.
How this works in personal knowledge systems
Niklas Luhmann's Zettelkasten contained 90,000+ notes organized into 108 top-level subject areas. That's a hierarchy. But Luhmann's real innovation was that any note could link to any other note, regardless of where it sat in the hierarchy. He described the slip-box as a "heterarchical network" — the position of a note relative to any other note did not mean it was more or less important. The hierarchy provided a physical address. The links provided the actual intellectual structure.
This is an override pattern operating at the system level. Every cross-link that connects a note to an idea outside its parent category is an implicit override — it's saying "this note belongs here for organizational purposes, but its intellectual relationships extend beyond what this category would predict."
Sonke Ahrens made this explicit in How to Take Smart Notes: the question is never "Under which topic do I store this note?" but "In which context will I want to stumble upon it again?" That reframing is an override of hierarchical inheritance. The parent category says "this note is about X." The context link says "yes, but it's also relevant to Y, and that connection matters more."
Andy Matuschak's evergreen notes take this further. His principle that evergreen notes should be concept-oriented rather than category-oriented is a systematic override of topic-based inheritance. A note titled "Effective system design requires making trade-offs explicit" doesn't inherit the assumptions of any single parent category — software engineering, organizational design, knowledge management. It sits at the intersection, overriding the frame that any single category would impose.
The practical implication: in your own system, when a note or item doesn't fit its parent category, don't just leave it there and hope you'll remember the exception. Annotate the override. A single line — "Unlike other items in [category], this one [specific difference]" — converts an invisible exception into a visible design decision.
The Third Brain parallel: fine-tuning as override
AI systems face the same structural problem, and their solution maps directly onto this lesson.
A large language model like GPT-4 or Claude is trained on broad data — the equivalent of inheriting a general worldview from a parent category called "everything humans have written." That base training carries inherited properties: tendencies toward certain patterns of response, knowledge distributions, stylistic defaults.
Fine-tuning is the override mechanism. When OpenAI fine-tuned GPT-3 into InstructGPT using reinforcement learning from human feedback (RLHF), they were applying targeted overrides to the base model's inherited behavior. The base model "inherited" the property of generating text that looks like internet writing. RLHF overrode that property: generate text that follows instructions, is helpful, and avoids harmful outputs.
The mechanism is precise. RLHF uses a Kullback-Leibler divergence penalty to prevent the override from going too far — the fine-tuned model is penalized for deviating too much from the base model's probability distributions on a per-token basis. In other words, the system applies overrides where they're needed while preserving the inherited base behavior everywhere else. Override the specific properties that need changing. Leave the rest alone.
This maps exactly onto what you should do in a knowledge system. When a child item needs to differ from its parent, override the specific properties that diverge. Don't rewrite the entire item from scratch (that's replacing the hierarchy, not overriding within it). Don't leave the exception implicit (that's pretending the inheritance is complete when it isn't). State what changes, state why, and let the rest propagate normally.
The alignment field has also discovered what happens when overrides aren't explicit. Anthropic's research on RLHF trade-offs shows that an overly aggressive override creates a new problem: a model that overrides too much of its base training in the direction of "harmless" becomes useless — it refuses to answer anything. A model that doesn't override enough inherits toxic patterns from its training data. The right answer is targeted, explicit overrides: change what needs changing, document the change, and preserve everything else.
When overrides become a pattern: the refactoring signal
Here is the judgment call this lesson requires: how many overrides before the hierarchy itself is wrong?
If one child in twenty overrides a parent property, you have a healthy exception. Annotate it and move on. If eight children in twenty override the same property, you don't have exceptions — you have evidence that the parent category's assumptions are wrong.
This is the threshold that leads to L-0274, hierarchy refactoring. The override pattern is a diagnostic tool. Each override is a data point. When the data points cluster around the same inherited property, the property shouldn't be inherited — it should be moved down to the children that actually exhibit it, or the hierarchy needs restructuring entirely.
Software engineers call this a "code smell." When subclasses consistently override the same method from their parent, the method doesn't belong on the parent. In your knowledge system, the equivalent is noticing that most items in a category break the same assumption. "Creative Projects" assumes solo work, but most of your creative projects are collaborative. The fix isn't ten overrides. The fix is changing what "Creative Projects" means — or splitting it into "Solo Creative" and "Collaborative Creative."
The override pattern gives you the vocabulary to notice this. Without explicit overrides, you'd just feel vaguely uneasy about the category without being able to articulate why. With explicit overrides, you can count them, see which properties they target, and decide whether you need a local fix or a structural one.
Making it operational
Three rules for handling overrides in your epistemic infrastructure:
1. Make every override explicit. When an item inherits a property from its parent that doesn't apply, write the override. Don't rely on memory. Don't trust that the context will make it obvious. State what's different and why. This takes fifteen seconds and saves hours of confusion later.
2. Override properties, not identities. A penguin isn't a "non-bird." It's a bird that overrides the flight property. Your Sunday routine isn't "not a morning routine." It's a morning routine that overrides the exercise-first default. Overrides preserve the relationship to the parent while modifying specific inherited traits. The moment you're overriding the identity — the fundamental reason the item belongs in that category — you don't need an override. You need a different category.
3. Track your overrides as diagnostic data. Every override is a hypothesis that says "the parent's assumption holds generally but not here." When those hypotheses cluster, the parent's assumption doesn't hold generally. That's your signal to refactor the hierarchy — which is exactly the skill the next lesson builds.
The primitive is simple: explicit override is cleaner than implicit exception. Clean doesn't mean easy. It means visible, documented, and available for the next time you — or your system — need to reason about where the structure holds and where it bends.