When teams use LLMs to compile domain-specific knowledge - ingesting technical manuals, research papers, analyst reports - the immediate problem they solve is extraction quality. Can the model process a 200-page PDF and produce coherent, claim-attributed summaries? Usually, yes, given the right pipeline. The second problem is less obvious: what do you do with 100 compiled pages in a flat directory?
A vector store gives you semantic search. A relational database gives you queries. Neither tells you where your knowledge stops, which pages reinforce each other, or where you have covered a topic superficially. For that, you need a graph.
1. The Structural Challenges of Domain Knowledge Management
Building a knowledge base that a team can trust over time is harder than it appears. Several structural problems emerge at scale:
Drift and staleness. A compiled page reflects its source document at ingest time. When the source updates - a regulation changes, a product ships a new version - the page doesn't know it's stale. Staleness detection requires tracking source file hashes: the page is stale when the underlying document changed since ingest, regardless of when the page was last viewed.
Contradiction between authoritative sources. Two documents can disagree on the same fact. LLM compilation doesn't resolve contradictions, it surfaces them. Managing this requires tracking which pages are in conflict and whether the conflict has been reviewed. This is a lifecycle state problem, not a search problem.
Coverage blindness. The hardest knowledge gaps are the ones you don't know exist. A flat file list tells you what you have; a graph shows you what's missing. Sparse nodes with few connections signal underrepresented topics. Isolated clusters with no bridges to the core signal disconnected knowledge domains.
Cross-domain topology. Domain knowledge isn't hierarchical. A taxonomy tree represents categories; it doesn't capture that "quantum error correction" connects meaningfully to both "hardware design" and "cryptographic protocols." Relational references between pages encode topology that no flat structure can represent.
These problems compound. A knowledge base that ignores them becomes a liability: you can't tell what's trustworthy, what's missing, or what has gone stale since ingest.
2. Architecture of the Knowledge Compilation Engine
The compilation pipeline has five discrete layers, each with a defined contract.
Layer 1 - Ingestion. Source documents pass through a skill-based extraction layer that produces clean text. Before any LLM call, a sanitizer strips zero-width characters, bidi overrides, hidden spans, and instruction-injection patterns. This step is non-negotiable when sources come from arbitrary external files.
Layer 2 - LLM Compilation. A multi-pass pipeline processes the cleaned text: analysis (entity extraction, topic classification), decision (create a new page or enrich an existing one), synthesis (write the page in Markdown with inline citation markers), and annotation (link each claim to the specific source lines that support it).
Layer 3 - Lifecycle Management. Every compiled page has a state: draft, active, stale, contradicted, or archived. Transitions are rule-based, not time-based. Active pages are protected, a contradicting ingest flags the conflict for review rather than silently overwriting.
Layer 4 - Graph Construction. During each lint run, the system scans all non-archived pages, extracts [[wikilink]] references, and builds a directed graph. Each page becomes a node; each wikilink becomes an edge weighted by reference count.
Node schema:
slug — page identifier
title — page title
type — concept | person | event | tool | ...
state — active | draft | stale | contradicted | archived
cluster_id — Louvain community assignment
Edge schema:
from_slug — source page
to_slug — target page
weight — [[wikilink]] count (typically 1)
Layer 5 — Visualization and Query. The graph is exposed via GET /graph, returning status, node count, edge count, cluster count, and the full node and edge arrays. The web interface renders this as a D3.js force-directed canvas. Clicking a node opens a detail panel with the page's type, lifecycle state, cluster assignment, and pre-generated questions. An "Ask about this →" shortcut bridges the graph directly into the chat interface.
Assigning pages to knowledge clusters is a community detection problem. The algorithm choice matters more than it appears at first glance.
The Candidates
Louvain maximises modularity, a measure of how much denser within-cluster connections are compared to a random null model. It operates in two phases: local moves (each node is assigned to the neighbouring community that maximises modularity gain) and aggregation (communities collapse into supernodes). The process repeats until no improvement is possible. Runtime is near-linear; no pre-specified cluster count is required.
Infomap models the graph as a random walk medium and compresses the walk description to find community structure. It is information-theoretic and handles directed graphs more naturally. Runtime is also near-linear.
Label Propagation assigns each node the most common label among its neighbours, iterating until convergence. Linear time, but unstable: a single highly-connected node can pull an entire neighbourhood into its label, and results vary significantly between runs.
Spectral Clustering decomposes the graph Laplacian to find stable cluster boundaries. Theoretically clean, but O(n³) eigendecomposition makes it impractical beyond a few thousand nodes.
Girvan-Newman builds a hierarchy by progressively removing high-betweenness edges. Useful for small graphs where hierarchical structure is meaningful; O(m²n) complexity disqualifies it at any meaningful scale.
Comparison
| Algorithm | Complexity | Cluster count | Handles directed | Non-deterministic | Use case |
|---|
| Louvain ✓ | near-linear | Auto | No | Yes | Large sparse graphs |
| Infomap | near-linear | Auto | Yes | No | Directed knowledge flows |
| Label Propagation | O(n) | Auto | Partial | Yes | Massive scale only |
| Spectral Clustering | O(n³) | Pre-specified | Partial | No | Small, dense graphs |
| Girvan-Newman | O(m²n) | Hierarchical | No | No | Small hierarchical graphs |
Why Louvain
Wikilink graphs are sparse. Most pages link to a small fraction of others; the adjacency matrix has few non-zero entries. Louvain handles sparse graphs well, requires no cluster-count hyperparameter, and is fast enough to run as part of every lint cycle without a separate scheduling concern.
Its main limitation is non-determinism: the random order of local move evaluations can produce different cluster IDs across runs. For a knowledge base, this is acceptable. Cluster IDs are navigational aids, not authoritative taxonomy, the page content hasn't changed if its cluster ID shifts between lint runs. Users see "these pages are related" rather than "this page belongs to category 7."
Infomap would be more principled for graphs with strong directional semantics (citations, prerequisites). At the typical scale of a domain wiki (50–500 pages), the added implementation complexity isn't justified. If your wiki grows beyond 5,000 pages with significant cross-domain citation flows, revisit Infomap.
4. The Web Interface: Force-Directed Layout and D3.js
Force-directed layout is the natural choice for a wikilink graph. There's no meaningful hierarchy or grid. Pages cluster by mutual reference density, which is exactly what a force simulation encodes. Highly-referenced pairs attract; low-reference nodes repel toward the periphery. The layout reflects the actual structure of the data.
D3.js wins for graphs under ~2000 nodes where per-node visual control and rich interaction matter:
- Cytoscape.js has a higher-level API and handles larger graphs more gracefully, but its abstraction makes fine-grained visual control harder. Per-cluster node coloring, inbound-degree-proportional sizing, and click-to-chat bridging all require direct control over the render layer.
- Sigma.js uses WebGL for very large graphs (tens of thousands of nodes). The overhead is unjustified for a domain wiki, and its interactivity API is thinner than D3's.
- vis.js is simple to set up but limited in visual customisation. Adapting it to match an existing UI system requires fighting the library.
D3's force simulation runs on either Canvas (for frame-rate performance) or SVG (for per-element targeting). The implementation uses Canvas to handle smooth drag-and-zoom on a dense graph. The canvas layer handles rendering; separate hit-testing handles click events. Node size is proportional to inbound degree, hubs are visually prominent without any manual configuration.
5. Reading the Graph
The screenshot below is from a reference implementation's knowledge graph of a history-of-computing wiki with 110 nodes, 349 edges, and 4 Louvain-detected clusters.
Several features are worth examining closely:
Node color encodes cluster membership. Four visible color groups represent four knowledge neighbourhoods: the large coral/red cluster at center (computing pioneers: the densest, most interconnected area of this wiki), a blue/teal cluster upper-left (hardware eras, earlier computing history), an orange cluster lower-right, and a green cluster lower-middle. Colors carry no fixed semantic meaning beyond consistent cluster identity, they answer "are these pages in the same neighbourhood?"
Node size encodes inbound degree. Larger nodes have more pages pointing to them. In a history-of-computing wiki, the largest node in the central cluster is likely a foundational figure or event that nearly every other page in that cluster references. This makes highly-cited pages visually prominent without requiring any manual taxonomy.
Edge density reveals cluster cohesion. The coral/red cluster shows nearly fully-connected internal structure, its pages cross-reference each other extensively. The peripheral clusters (orange, green) have sparser internal connections and fewer bridges to the core. This is a direct editorial signal: those knowledge domains are underrepresented.
The selected node "Quantum" shows a critical pattern. The panel reports: concept, active, Cluster 0, 23 connections (Hub). With 23 connections it qualifies as a hub, but it belongs to a small, peripheral cluster. The legend reads: "Sparse pages may need enrichment." This is the most important signal the graph gives: a page that is a hub by connection count but has few cluster peers has cross-domain reach without local depth. There is no supporting material around it. The pre-generated questions - "Summarize Quantum", "What are the key ideas in Quantum?", "How does Quantum connect to related topics?" - are not generic suggestions. They are the system's way of flagging: you've cited this topic many times, but you haven't built out the knowledge base around it.
Isolated peripheral nodes, low-degree nodes at the graph boundary, are the clearest enrichment signals. Each one is a topic that exists in name but isn't integrated into the broader knowledge structure.
6. Using the Graph to Improve the Knowledge Base
The graph is not just a visualisation, it is an active feedback loop:
Sparse node detection. Nodes below a degree threshold are candidates for targeted ingest. The graph makes this visual, you see the gaps directly rather than inferring them from page counts. A sparse cluster is obvious at a glance; a list of articles you haven't ingested yet is not.
Cluster distribution analysis. If one cluster dominates while others remain thin, the ingest strategy is skewed toward one area of the domain. For a compliance knowledge base, you might expect roughly equal clusters for regulatory text, enforcement history, and industry practice. If the enforcement cluster is a fraction the size of the others, you have a coverage problem the graph makes undeniable.
Lifecycle-aware auditing. Stale and contradicted nodes can be rendered distinctly from active ones - dimmed or outlined differently - turning the graph into a live audit dashboard. Rather than scanning a flat list of pages with attention flags, you see where the operational problems are concentrated in the topic structure.
Dynamic enrichment hints. After each query, the hint engine generates follow-up suggestions based on the cited pages and their graph neighbourhoods. If a query cites three pages from the central cluster, the suggestions surface adjacent pages in that neighbourhood that were not retrieved but are closely linked. Each answer extends naturally to the next question, guided by the actual structure of the knowledge base. The hint engine runs server-side without LLM calls, it derives suggestions from the graph directly, so there's no additional cost per query.
Reference Implementation
The architecture described in this post is implemented in Synthadoc, an open-source LLM knowledge compilation engine. The knowledge graph view is built in: it activates automatically once the wiki has enough pages for clustering to be meaningful, with no additional configuration required.
Synthadoc Community Edition v1.0 release notes
