After three instances of the same insight, extract it into a canonical note
When encountering the same insight expressed in three or more separate notes across different contexts, extract the shared structural pattern into a single canonical note with a precise name, then replace the duplicate instances with links to the canonical abstraction.
Why This Is a Rule
The Rule of Three applied to knowledge management: one instance of an insight is an observation. Two might be coincidence. Three across different contexts confirms a genuine pattern that deserves its own canonical representation. Abstracting before three instances risks premature generalization — the "pattern" might be an artifact of two similar contexts rather than a universal structure. Waiting beyond three wastes the opportunity to name and link what you've already discovered.
The extraction procedure mirrors code refactoring: identify the shared structure, extract it into a named abstraction, and replace the concrete instances with references. In code, this is "extract function." In notes, this is "extract canonical atom." The result: three domain-specific notes that each contained a version of the insight now link to a single, precisely named pattern that captures the structure they share.
The naming step is critical. An unnamed pattern continues to appear as separate insights. A named pattern becomes a lens: once you've named "premature abstraction" as a canonical concept, you start recognizing it everywhere — in code, in organizational design, in personal planning. The name makes the pattern portable across domains.
When This Fires
- Reviewing your knowledge base and noticing repeated themes across different notes
- Writing a new note and feeling strong déjà vu — you've written something like this before
- Finding the same principle showing up in notes from different domains or time periods
- During any knowledge base maintenance where pattern detection is part of the review
Common Failure Mode
Abstracting after one instance: "This is a general principle!" — when it might just be a context-specific observation. Or abstracting at four or five instances when you should have abstracted at three — leaving duplicates scattered through your system, each slightly different, none canonical. The three-instance trigger balances premature abstraction against delayed consolidation.
The Protocol
When the same insight appears in a third note: (1) Identify the structural pattern shared by all three instances — what's the same when you strip away the domain-specific details? (2) Create a new canonical note capturing only the shared structure. (3) Give it a precise, domain-neutral name. (4) In each of the three original notes, replace the insight with a link to the canonical note, keeping the domain-specific context. (5) Going forward, link new instances to the canonical note rather than restating the insight.