Override traits, not identity — if you are overriding…
Override properties rather than identities—preserve the child's relationship to its parent category while modifying specific inherited traits, as overriding identity signals you need a different category, not an override.
Why This Is a Rule
There's a critical distinction between overriding a property and overriding an identity. A penguin overrides the "can fly" property of birds while remaining a bird — it shares the identity (bird) with a modified trait (flightless). This is a legitimate exception. An item categorized as a "meeting note" that's actually a decision record doesn't override a property — it overrides the identity. It isn't a meeting note with different traits; it's a fundamentally different thing that belongs in a different category.
Property overrides are healthy exceptions: "Unlike most engineering tasks, this one doesn't require code review." The item remains an engineering task with a modified review requirement. Identity overrides are miscategorizations: when the override changes so many properties that the item no longer meaningfully belongs to the parent category, it needs to be recategorized, not over-annotated.
The diagnostic: does the item still share the core identity of its parent category? If yes → property override (legitimate). If no → identity override (miscategorized, move it).
When This Fires
- When adding an exception annotation to a categorized item
- When an override list on an item is growing (overriding identity incrementally)
- During hierarchy audits when checking whether exceptions are legitimate
- In code when a subclass overrides most of the parent's methods
Common Failure Mode
Overriding so many properties that the identity is effectively changed: a "bug" with overrides for "not a bug, actually a feature request, also needs design review, also involves product team." At this point, the item isn't a bug with exceptions — it's a feature request miscategorized as a bug. Move it.
The Protocol
When adding an override: (1) Check: am I overriding a property (specific trait) or the identity (what this fundamentally is)? (2) Property override → document explicitly: "Unlike [parent], this item [specific difference]." Legitimate exception. (3) Identity override → don't override; recategorize. The item belongs in a different category. (4) If you've accumulated 3+ property overrides on the same item, check: does the item still meaningfully belong to its parent category? Multiple property overrides may be incremental identity override.