KM-201a · Module 2
Linking and Cross-Referencing: Building the Graph, Not Just the List
4 min read
A knowledge base without links is a list of documents. A knowledge base with well-designed links is a graph. The difference is not aesthetic — it is the difference between a system where users find the one document they searched for and a system where they find that document and the three related documents that give it context, the decision record that explains why it exists, and the procedure that implements it.
Links in a knowledge base serve four functions. Navigation links connect related concepts so users can follow a thread of understanding without returning to search. Context links connect a knowledge artifact to the decision or rationale that produced it. Implementation links connect a policy to the procedure that implements it, or a reference document to the procedure that uses it. Hierarchy links connect parent concepts to child concepts, enabling both top-down browsing and bottom-up navigation.
The discipline of cross-referencing is not about adding as many links as possible — it is about adding the links that answer the questions a user would naturally ask after reading a document. After reading a policy, a user asks: what procedure implements this? After reading a procedure, they ask: what policy governs this, and what reference does it draw from? After reading a decision record, they ask: what is the current state — is this still the policy we follow? Those are the links that should exist. Links that are added because they are tangentially related create noise without adding navigability.
For AI retrieval systems, the link graph is valuable beyond navigation. When a RAG system is designed to traverse knowledge graph relationships, a query about a specific policy can surface not just the policy document but the procedures that implement it, the decision record that justified it, and the reference documents it draws from — all as part of a single synthesized response. This is the difference between AI retrieval that answers questions and AI retrieval that provides understanding.
- Mandatory Links at Publication Every knowledge artifact should require two links at publication: the parent (what category or concept does this fall under?) and at least one related artifact (what does a user naturally need after reading this?). This minimum ensures the graph is connected — no orphaned documents.
- Bidirectional Linking When document A links to document B, document B should link back to A or at minimum list A in its 'referenced by' metadata. Bidirectional linking enables graph traversal in both directions and prevents the situation where a policy is updated but none of the procedures that implement it are notified.
- Link Maintenance Links decay. A document is renamed and all the links that point to it by name become broken. A document is deprecated and the links to it should be updated to point to the replacement. Link maintenance is a governance responsibility — assign it to the same owner who owns content accuracy. A knowledge base with 15% broken links is a knowledge base users stop trusting.
Do This
- Require at minimum one related-artifact link at publication
- Build bidirectional linking so relationships are traversable in both directions
- Audit link health as part of the annual taxonomy review
- Design the link schema to support AI graph traversal, not just human navigation
Avoid This
- Add links to every tangentially related document — noise degrades navigability
- Treat linking as optional contributor behavior rather than a publication requirement
- Let links decay when documents are renamed or deprecated
- Build a knowledge base without links and call it a knowledge graph