The Compounding Research Wiki

The problem this solves: You have a growing body of sources — articles, primary documents, notes, datasets — and you want Claude to help you work with all of them, not just one at a time. The instinctive approach is to feed Claude documents one by one and ask questions. The smarter approach is to have Claude build and maintain a persistent synthesis layer: a wiki that compounds over time.

Two approaches to sources

Session-by-session: You feed Claude a document, ask questions, get answers. Next session, you feed another document. The answers are good. But the connections between documents exist only in your head — Claude cannot see them unless you reconstruct them manually each time.

The compounding wiki: Claude reads new sources and writes what it learns into a structured set of files — entity pages, concept pages, comparisons, summaries. Each new source is processed into the existing structure. Over time, Claude's knowledge of your research corpus is persistent, cross-referenced, and available to any session.

The difference is not about any single answer. It is about whether knowledge from your sources accumulates anywhere, or evaporates at session close.

Named source of this pattern: this is Andrej Karpathy's "LLM Wiki" pattern, described in a gist that went viral in April 2026. His framing of the core distinction from RAG: "the wiki is a persistent, compounding artifact" — where standard retrieval-augmented generation re-derives an answer from raw chunks on every query, the wiki compiles that work once and keeps it current. Karpathy's own shorthand for the roles: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

The three-layer structure

sources/          ← Raw sources. Immutable. Claude reads but never modifies.
                    Articles, PDFs, primary documents, images, data files.

wiki/             ← The synthesis layer. Claude owns this entirely.
                    Entity pages, concept pages, comparisons, summaries.
                    Built by Claude from the sources; cross-referenced and maintained.

CLAUDE.md         ← The schema. You own this.
                    Wiki structure, conventions, ingestion workflow, what to do
                    with contradictions, how to handle name variants, etc.

The key distinction from CLAUDE.md as project instructions: the wiki is content Claude has produced from your sources, not instructions for Claude about how to behave. CLAUDE.md tells Claude what to do; the wiki is what Claude knows.

The schema encodes your research perspective. What Claude extracts from a source — which entities matter, which claims are worth a page, what counts as a contradiction — is determined by the schema. The same deposition register processed through a social-network schema produces different pages than the one processed through a belief-history schema. This is a feature, not a problem: the schema makes your interpretive choices explicit and consistent across the corpus. If your perspective shifts mid-project, update the schema and re-ingest the affected sources.

Three operations

Ingest

Process a new source into the wiki. Claude reads the source, extracts relevant entities, concepts, claims, and evidence, then updates the relevant wiki pages — or creates new ones. Existing pages are updated, not replaced: new information is added, contradictions are flagged.

Read sources/primary/deposition_register_12.pdf.
Update or create pages in wiki/ for:

- each named person not yet on the list

- each location mentioned

- any claim that contradicts or extends an existing wiki page
Flag contradictions with [CONTRADICTS: <page>] rather than resolving them.

Ingest is a repeatable operation. Every new source you add to sources/ gets an ingest run. The wiki grows with the corpus.

Query

Ask a question; Claude searches the wiki and synthesises an answer. Because the wiki is pre-structured and cross-referenced, Claude can find relevant pages without re-reading every source. Useful explorations — answers you would want to return to — can be written back into the wiki as new pages.

What do we know about the relationship between Bernard Gui and the Franciscan convents
in Toulouse? Use the wiki only; flag if something requires checking the source directly.

Query sessions are lightweight because the heavy reading has already happened in ingest. Claude is navigating a knowledge base, not re-reading documents.

Lint

Periodic health check on the wiki itself. Claude reads across the wiki — not the sources — and identifies structural problems.

Review the wiki/ directory. Report:

- Pages that contradict each other without a [CONTRADICTS] flag

- Claims that appear to be unsupported (no source reference)

- Entity pages that are referenced from other pages but do not exist yet (orphan links)

- Pages that appear redundant and could be merged
Do not fix anything — report only.

Lint is the most underused operation. It is the wiki's equivalent of source-checking in traditional research: verifying that what Claude has built is internally consistent before you rely on it. (See B.trust — the argument for verification as architecture rather than afterthought applies here directly.)

Limitation: error compounding. Lint checks internal consistency, but it cannot catch errors introduced during ingest — a misread date, a conflated person, a paraphrase that drifted from the source. Because later ingest passes build on earlier pages, a factual error in an early page can propagate forward into many pages that cite or reference it. For high-stakes claims — specific dates, names, numbers — periodically verify wiki pages against the raw sources, not just against each other. The log tells you which ingest session introduced a claim; go back to the source when something looks wrong.

The wiki structure itself partially mitigates this. A claim that is cross-referenced by many pages — cited, built upon, connected — has been implicitly reinforced through repeated ingestion. A claim that sits in a single isolated page, referenced nowhere else, is structurally unconfirmed. This means lint does not need to be exhaustive: treat it as triage. Pages with no inbound links and claims that appear only once are your highest-risk facts. Review those first. Errors that entered the wiki but were never reinforced by subsequent ingest will surface as structural outliers — which is exactly what lint reports.

Navigation files

wiki/_index.md — A content-oriented catalog of wiki pages, organised by category, with one-line summaries. Updated during ingest when new pages are created. This is how you and Claude find what is in the wiki without reading every page.

wiki/log.md — An append-only record of every ingest, query, and lint pass: what source was processed, when, and what was added or changed. The chronological provenance of the wiki. If a page contains a claim you do not recognise, the log tells you which ingest session introduced it.

## 2026-03-15 — Ingest: deposition_register_12.pdf
Added: Bernard_Gui.md (new), Toulouse_Franciscan_convent.md (new)
Updated: Complicitas.md — added testimony linking Guilhem Arnaut to credente network
Flagged contradiction: Bernard_Gui.md vs. Inquisitors.md — conflicting dates for
  Gui's appointment in Toulouse (Register 12: 1307; Limborch summary: 1308)

## 2026-03-17 — Lint pass
Orphan links: 3 (Pons_Arnaut.md, Autier_movement.md, Waldensian_sources.md — create next ingest)
Unsupported claims: 2 flagged in Catharism.md — need source reference added

What the wiki contains

The content depends entirely on your research. Useful page types for historians and social scientists:

How this connects to what you already have

If you have been following the meta-document practice in this book, you already have parts of this structure:

What you have Wiki equivalent
CLAUDE.md The schema layer — already doing this job
_history.md Similar to wiki/log.md, but for session work, not source ingestion specifically
_index.md Similar to wiki/_index.md
_logic/ domain knowledge files Wiki pages for your specific domain — the pattern already used in data-heavy projects

The difference is intentionality: the wiki pattern names the synthesis layer explicitly, treats it as Claude-owned, and defines repeatable operations (ingest, query, lint) for maintaining it. What many researchers do informally — accumulating notes from sources in markdown files — becomes a systematic, auditable practice.

Wiring the wiki into Claude Code sessions. Use @import in CLAUDE.md to surface the wiki index as ambient context, and path-scoped rules (.claude/rules/) to load specific wiki pages only for the sessions where they are relevant:

## Wiki
@wiki/_index.md

# .claude/rules/network-analysis.md
---
paths:

  - "analysis/**/*.py"

  - "notebooks/**/*.ipynb"
---
@wiki/concepts/Network_analysis.md
@wiki/concepts/Complicitas.md

This way, entity and concept pages enter Claude's context automatically when they are relevant, without loading the whole wiki every session. The approach is the same pattern described in A.setup.settings-local for path-scoped rules.

When this is worth setting up

The wiki pattern pays off when:

It is overkill for a single-session literature review or a one-off question about a document. The overhead of structuring a wiki is worth it when the knowledge compounds across sessions.

A wiki also changes what kind of work becomes possible. A knowledge base answers questions about what sources say. A wiki with structured, cross-referenced pages that Claude can reason across becomes something closer to a decision-support system: comparing arguments against structured criteria, surfacing contradictions between sources you had forgotten about, identifying what is missing from the corpus. The three-layer split is what makes this possible — Claude always has ground truth (the sources) to reason from, a synthesis to reason with (the wiki), and your interpretive framework (the schema) to reason through.

A note for historians

The pattern has a predecessor: Vannevar Bush's 1945 Memex proposal, which described a personal desk-device for storing and associatively linking documents — the intellectual ancestor of hypertext. Bush's central observation was that the human mind operates by association rather than by index, and that knowledge stores should work the same way. The wiki pattern is a working implementation of the Memex idea: a personal, curated knowledge base with cross-references and associative trails.

Bush could not build it in 1945 because the maintenance problem was intractable: keeping a large cross-referenced store consistent and up to date is exactly the kind of tedious bookkeeping that humans abandon. LLMs solve the maintenance problem. The ingest and lint operations are what make the Memex viable.

The question underneath this pattern

Everything in this document assumes you are the primary reader of your sources. The wiki externalises knowledge you have built; Claude maintains the cross-references and structure. This is one end of a spectrum.

At the other end, Claude does the reading. You ingest sources — PDFs, articles, primary documents — and the tool extracts, structures, and connects. The knowledge base grows faster than you can read. The connections it surfaces are real, but they are the tool's connections, not yours. Tools like SwarmVault are built for this end of the spectrum.

Graphify: the graph-first variant. Built within 48 hours of Karpathy's gist going viral, Graphify replaces the flat wiki-of-markdown-pages with an actual knowledge graph, clustered with Leiden community detection, queried via a /graphify command inside Claude Code and similar tools. Its extraction is mixed, not uniformly deterministic: code files get a free tree-sitter AST pass (functions, classes, call graphs — no LLM needed), but PDFs, documents, and images go through LLM extraction ("via Claude subagents") — the same fundamental step as the wiki pattern above. So it is not code-only; a deposition-register corpus is a supported input. The difference from the wiki pattern is what you get afterwards: a queryable graph structure rather than markdown pages, with claimed large token savings (Graphify cites ~71.5x) on repeated queries against an already-built graph, not on the initial extraction pass itself.

Neither end is inherently wrong. But the choice has consequences for what you can defend, what you own intellectually, and how errors enter and propagate through your knowledge base. That choice is worth making deliberately rather than accidentally.

→ C.llm-as-reader — the full treatment of this spectrum: what changes at each end, when each is appropriate, and how to work responsibly when Claude is doing the reading.

Related