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.

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.