What tribal knowledge is
Tribal knowledge is the body of expertise, judgment, shortcuts, and unwritten rules that experienced members of an organisation carry in their heads — and that exists nowhere else. It is called "tribal" because, like the oral traditions of pre-literate societies, it is transmitted through proximity, apprenticeship, and observation rather than through documents.
Definition
Tribal knowledge — information, judgment, and contextual understanding collectively held by experienced members, transmitted informally, never formally documented, and lost when those members leave.
Distinct from tacit knowledge (Polanyi, 1966), which cannot in principle be fully articulated — embodied skills, intuitions, aesthetic sense. Tribal knowledge can be articulated and documented. The problem is that existing documentation formats are structurally inadequate to hold it without destroying the nuance that makes it valuable.
Every organisation has it. The senior engineer who "just knows" which parts of the codebase to never touch on a Friday. The account manager who knows the real decision-maker is never the person with the title. The operations lead who knows the three supplier relationships that will cascade into crisis if handled wrong. The CFO who knows which line items the board will actually scrutinise versus which they wave through.
None of this is in any document. All of it is genuinely running the organisation. And all of it disappears the day that person does.
The iceberg — what documentation captures
Formal documentation — wikis, SOPs, onboarding guides, runbooks — captures the visible surface: processes that are easy to describe because they are sequential, repeatable, and low-stakes to get slightly wrong. What stays permanently submerged is everything that makes the visible surface actually work.
Above the surface — what gets documented
. How to set up the development environment
. The steps to deploy to production
. The company org chart and reporting lines
. What the product does and how to demo it
. The official process for requesting budget approval
Below the surface — what stays tribal
! Which stakeholder will silently block any initiative they weren't consulted on first
! The three legacy modules that no one touches because no one fully understands them
~ Why the official deployment process has six undocumented exceptions
! Which customers are held to different SLA terms because of historical commitments
~ Why the sales team quotes below-floor prices for certain deal shapes and leadership accepts it
! Which vendor relationships are personally maintained by one senior person and will break on their departure
? What the actual decision criteria were behind the three most consequential architectural choices
* The two customers technically in breach of contract whom we never enforce against, and why
~ The tension between the roadmap and what the founders verbally committed to enterprise clients
The iceberg items are not secret. They are not sensitive. They are simply never written down — because prose documentation has no structural primitives for risks, exceptions, tensions, unstated rationale, and conditional judgment. It needs different operators.
Taxonomy — six kinds of tribal knowledge
Relational knowledge
Who / trust / power / history
Who the real decision-makers are, which relationships are load-bearing for specific outcomes, which historical conflicts still shape present behaviour, and which alliances are contingent on specific individuals remaining in place.
CLN: @ real-authority + ! fragility · "@ real authority: [name] not [title]"
Exception knowledge
When the official process doesn't apply
The undocumented conditions under which standard procedures are suspended, modified, or overridden. Every mature organisation runs partially on exceptions. The senior person knows all of them; the new hire stumbles into them and is corrected informally.
CLN: ~ official vs actual · "~ stated process vs what we do when X"
Risk knowledge
What breaks and under what conditions
Awareness of the specific conditions, sequences, or actions that cause systems, relationships, or processes to fail. Typically earned through past failures and exists only in the people who were present for them.
CLN: ! core role · "! never X unless Y first — learned: incident [date]"
Rationale knowledge
Why decisions were made the way they were
The context, constraints, and reasoning behind consequential decisions that are now simply implemented facts. Without rationale knowledge, the people who inherit a decision cannot evaluate whether its underlying assumptions still hold.
CLN: * context · "* chosen because [constraint that may no longer apply]"
Pattern knowledge
What situations map to what responses
The expert's ability to classify novel situations rapidly by matching them to known patterns. Not rule-following — pattern recognition. The senior engineer who "just knows" the bug is in the cache layer. The sales director who "just knows" this procurement process will stall at legal.
CLN: ? pattern triggers + → responses
Tension knowledge
Where competing goods pull in opposite directions
Awareness of genuine tradeoffs with no permanent resolution — where the organisation has chosen a balance point that should be revisited but rarely is because it is not written down. Speed vs stability. Sales commitment vs engineering capacity. Short-term satisfaction vs long-term coherence.
CLN: ~ core role · "~ current balance is [state] because [constraint]"
Why it stays tribal — the four documentation failure modes
The question is not why organisations don't value documenting tribal knowledge. They do — universally, loudly, and repeatedly. The question is why, despite that stated value, it almost never actually gets documented in useful form. The answer is structural.
Failure 1 — Prose flattens conditional logic
The most valuable tribal knowledge is conditional: "do X, unless Y, in which case Z, but never Z if W." Prose can express this, but it buries the condition structure in subordinate clauses that read as caveats rather than branches. A new hire extracts the main verb and misses the subordinate clause that would have saved them two weeks of work.
Failure 2 — No operator for "this is dangerous"
Prose documents have one semantic register. A risk, a procedure step, a rationale, and a prohibition are all expressed as sentences. Visually, structurally, they are indistinguishable. The reader must parse every sentence to find the critical ones. Under time pressure, this fails — exactly when it matters most.
Failure 3 — Expert knowledge resists self-description
The expert who holds tribal knowledge is typically the worst person to document it. They have unconscious competence — they perform relevant judgments automatically, without being aware of doing so. Asked to write down "how they do it," they produce an account of what they consciously believe they do, omitting exactly the tacit pattern recognition and exception handling that makes their knowledge valuable.
"If I try to write down how I decide which bugs to fix first, I can't. I just look at the list and I know. But if you watch me do it for a week, you could probably write it down better than I could."
— Senior engineer, 11-year tenure, during knowledge transfer interview
Failure 4 — Documentation feels like extra work
Senior people are senior because they are effective at doing things. Documentation is perceived as separate from — and in competition with — doing things. The time cost is real and immediate; the benefit is abstract and deferred. Every incentive structure pushes against it.
The cost of loss
Immediate The knowledge is gone. No document captures it. The void is not yet visible — existing projects continue on their trajectory and the absent knowledge hasn't been needed yet.
High cost A situation arises that the departed person would have handled in twenty minutes. Without their pattern recognition, the team takes three days to diagnose and two more to resolve, with escalations that wouldn't have been necessary. Estimated cost per incident: 40–60 person-hours.
Exception stumbled into
Month 2–3
Relationship damage A new hire follows the documented process exactly — and violates an undocumented exception. A client relationship handled with a known-but-unwritten carve-out is suddenly handled by the book. The client escalates. The exception is now known but still undocumented, because there is still no format to hold it.
Architectural drift
Months 4–12
Long-term Without rationale knowledge, decisions get revisited and re-made without awareness that they were already resolved — and that the resolution involved constraints still present but no longer visible. The codebase accumulates unanswerable "why did we do it this way?" moments.
Onboarding degrades
Year 1+
Compounding New hires spend 6 months accidentally discovering what the senior person knew instinctively. Each discovery requires a correction conversation that should have been a document. Time-to-productivity lengthens. Some percentage who would have succeeded leave in frustration. The knowledge base continues eroding.
Why CLN solves the extraction problem
CLN addresses all four failure modes simultaneously — not by requiring more effort, but by providing the right structural primitives.
Against Failure 1 (flattened conditions): CLN's ? operator makes conditional branches explicit and scannable. The condition and its outcomes sit on adjacent lines with clear visual hierarchy. It cannot be misread as a caveat — it is structurally a branch.
Against Failure 2 (no danger operator): CLN has three levels of risk signal — !, !!, and ✗ prohibition. Each is visually distinct from procedure, rationale, and context. A reader scanning the left column cannot miss the dangerous line. The severity is encoded in the symbol, not the prose.
Against Failure 3 (expert self-description): The observation-annotation loop — watching the expert perform, drafting a CLN document of what was observed, then asking the expert to react — bypasses the self-description problem entirely. The expert does not author; they edit. Editing is fast because the draft surfaces the gaps and errors that need correction without requiring the expert to generate from scratch.
Against Failure 4 (documentation as extra work): CLN's structure makes each line independently encodable. A five-minute conversation between a senior and junior, structured as CLN note-taking by the junior, produces ten lines of high-fidelity captured knowledge. The senior did not "write documentation" — they answered ten questions. The junior produced a CLN fragment that is immediately useful and reviewable.
Observation–annotation loop★★★★★ Most effective
Junior observes senior performing a task. Junior writes CLN draft:
. for each step,
! for each hesitation or "watch out,"
? for each visible decision point. Senior reviews the draft and reacts — corrects, adds, flags gaps. Result is CLN with the expert's fingerprints, not their prose.
Why it works: editing is 3–5× faster than authoring · CLN gaps are visually obvious · senior never needs to introspect on their own process
Post-mortem mining★★★★☆ Highly effective
Every incident post-mortem contains tribal knowledge that just became explicit under pressure. Systematically extract: the
! conditions not in any document, the
? decision branches invented on the fly, the
* rationale for why the resolution worked. Add to the relevant SOP as permanent updates.
Why it works: incident pressure forces articulation · the knowledge was just active, not buried · the post-mortem conversation already contains the CLN content
Pre-departure interview★★★☆☆ Useful but imperfect
90-minute structured session with departing senior, CLN note-taker, and operator-typed questions. Not "what do you know?" but: "What should someone never do? What are the exception conditions? Which relationships are personally maintained?" Operator-typing bypasses the "just describe your job" failure mode.
Why it underperforms: best knowledge is what no one knows to ask about · useful as supplement, not primary source
Onboarding stumble capture★★★★☆ Scalable
Every time a new hire stumbles into an undocumented exception or risk, the correction conversation is immediately translated into a CLN fragment and merged into the relevant document. New hire confusion is a reliable sensor: wherever they are confused, there is something the experienced person knows that is not written down.
Why it works: new hires detect gaps passively · the correction conversation already contains the CLN content · just needs capture in format
The CLN extraction interview
The most transferable technique is the operator-typed extraction interview — every question maps to a CLN operator, guaranteeing the output is immediately CLN-formatted and covers all knowledge types.
extraction-interview-protocol.cln — operator-typed questions TASK: Tribal Knowledge Extraction Interview
@ duration: 60–90 min · note-taker: junior · subject: senior/expert
= goal: capture what lives only in the subject's head · not what is already documented
⟶ = questions (definitions / scope)
? "What is the actual goal of [domain], as distinct from the stated goal?"
? "What does done correctly look like — what is the signal?"
? "What would you say this area is fundamentally about, in one sentence?"
⟶ ! questions (risks / dangers / exceptions)
? "What are the 3 things a new person must not do in your area?"
? "What has gone badly wrong before — and what was the trigger?"
? "When does the official process fail? What are its edges?"
? "What would you be horrified to see a new hire do on day 30?"
⟶ ~ questions (tensions / tradeoffs / undocumented exceptions)
? "Where does the documented process not match what you actually do? Why?"
? "What decisions do you make differently depending on context — when and why?"
? "Where are there two valid but competing approaches, and how do you choose?"
⟶ @ questions (ownership / relationships)
? "Who are the people whose sign-off actually matters — regardless of title?"
? "Which relationships are you personally maintaining that will need transition?"
? "Who needs to be consulted before [decision type] even if not officially in the loop?"
⟶ * questions (rationale / history)
? "Why was [major decision / architecture / process] done this way?"
? "What constraints existed then that we should check are still true?"
? "What alternatives were considered and why were they rejected?"
⟶ ? questions (open unknowns / future risks)
? "What are you worried about that no one else seems to be?"
? "What will probably break in the next 12 months and why?"
? "What question should I have asked that I didn't?"
Head to document — before and after
✕ Typical "documentation sprint"
A departing senior engineer is given two weeks and asked to "document everything you know." They produce a 40-page Confluence document in prose. It takes 8 hours to write, 4 hours to read, and covers the procedures they are consciously aware of — omitting the pattern recognition and exception handling that made them valuable. Three months later, a junior asks a question the document doesn't answer. No one knows the answer.
✓ CLN extraction approach
A junior pairs with the senior for 5 working sessions across two weeks — observing, writing CLN fragments in real time. The senior reviews each session's draft for 15 minutes: adds ! flags missed, corrects ~ framing. After two weeks: 12 CLN documents covering risks, exceptions, rationale, and relationships. Gaps are visible as ? lines. The knowledge is in the document, not in one person.
example-extracted-fragment.cln — legacy codebase module DOMAIN: PaymentProcessor module (extracted from Sarah Chen, 2026-02-20)
= module purpose: handles idempotency for all payment retries
= written: 2019 · author: original CTO · no tests at time of writing
! never modify idempotency key generation in lines 847–891 !!
* why: 3 production incidents 2021–2022 · all caused by key collisions
* logic looks wrong but is intentional — see postmortems INC-0021, INC-0043
! Stripe webhook handler has silent 30s timeout — does not surface as error !!
* discovered: 2023-06 · ticket filed · product deprioritised indefinitely
! if payment status "pending" >45s — check webhook queue, not payment state !!
~ module is "deprecated" but 14% of transactions still route through it
* official position: being replaced Q2 2026
* actual position: migration has been "Q2" for 3 years · treat as permanent
~ investing in fixes vs accepting risk until migration · no written policy
@ person who understands this module: Sarah Chen (departing 2026-03-15)
@ after departure: Marcus Webb has partial knowledge · notify before any changes
! there is no one else · this knowledge currently exists only in this document !!
? are 2021–2022 incident postmortems findable in current JIRA instance?
* Sarah believes they are in the old Linear workspace, not current system
CLN as knowledge audit tool
A CLN knowledge base has a property no prose wiki has: its gaps are structurally visible. A ? line with no answer is an explicit unknown. A ! with no * why: child is a risk with undocumented rationale. An @ owner pointing to a single person is a single-point-of-failure flag.
knowledge-audit.cln — structural scan risk indicators AUDIT: Knowledge base — structural risk indicators
! single-owner @ lines with no backup contact !!
→ each = departure risk · verify tenure · document backup
! bare !! lines with no * why: child !!
→ risk documented · rationale not · enforcement becomes arbitrary if author leaves
? unresolved ? lines older than 90 days
→ either answered and doc not updated · or genuinely unknown
→ both are problems · triage required
~ ~ lines with no documented resolution policy
→ known tension · no agreed balance point · everyone resolves individually
* undated * context lines (no @date or @author metadata)
→ rationale may be stale · cannot evaluate whether constraint still holds
⟶ audit output: ranked risk list by indicator count per domain
→ highest-risk domains: most single-owners + most bare !! + most stale ?
→ these are the tribal knowledge hotspots · prioritise for extraction sessions
The audit is a succession planning tool. An organisation with a CLN knowledge base can calculate — before a departure happens — which domains have the highest tribal knowledge concentration and lowest documentation depth. A departure in a low-risk domain is a normal transition. A departure in a high-risk domain triggers an extraction sprint. The difference is visible in the CLN structure before the resignation letter arrives.