LLM Wiki

Definition

The large language model (LLM) Wiki is a design pattern introduced by Andrej Karpathy in April 2026 in which an LLM agent maintains a persistent, interlinked set of markdown files — a wiki — as the primary layer of a personal knowledge base. Instead of retrieving from raw documents at query time (as in Retrieval-Augmented Generation (RAG)), the LLM pre-compiles source material into structured, cross-referenced concept pages. Knowledge accumulates and compounds across sessions rather than being re-derived from scratch each time. The pattern is explicitly designed to be implemented with an agentic command-line interface (CLI) tool (Karpathy named Claude Code and OpenAI Codex) operating against a local folder structure.

Karpathy's framing: "Obsidian is the integrated development environment (IDE), the LLM is the programmer, the wiki is the codebase." The user's role is to curate inputs and review outputs. All structural maintenance — cross-referencing, tagging, backlink management, logging — is delegated to the LLM.

Key Ideas

• The pattern solves two simultaneous failures: RAG's statelessness (no accumulation between queries) and human-maintained wikis' maintenance collapse (bookkeeping burden grows faster than value).
• The value of each ingest is primarily in the cross-linking, not the per-source summary. A single new source updates $10$–$15$ related existing concept pages with new connections, not just produces one new summary file.
• Queries are not read-only: if a new connection is discovered during a query session, the LLM files it back into the wiki as a permanent page.
• The schema file (typically CLAUDE.md at the repo root) is the operating manual — it defines page formats, linking conventions, ingestion workflow, and how the agent answers questions. This is where the user's intelligence is imprinted on the system.
• The architecture is locally owned and human-readable. Every page can be opened, verified, and corrected. There is no proprietary lock-in, no black-box retrieval pipeline, no vector database to debug.

Architecture: Three Layers

Layer 1 — Raw Sources (Immutable)

Portable Document Format (PDF)s, articles, transcripts, images. The LLM reads these but never modifies them. This is the source-of-truth layer — if a wiki page is ever wrong, the raw source is the ground truth for correction.

Layer 2 — The Wiki (LLM-Maintained)

A directory of markdown files entirely written and maintained by the LLM:

• Concept pages (wiki/concepts/) — one page per idea, with definition, key ideas, mechanisms, implications, open questions, and wikilinks
• Entity pages (wiki/entities/) — one page per person, organization, or product, with overview and key contributions
• Source pages (wiki/sources/) — one page per ingested source, with summary, key claims, quotes, and critical assessment
• Index (wiki/index.md) — master index of all pages, updated on every ingest
• Log (wiki/log.md) — append-only record of all operations

Layer 3 — The Schema (Rules)

A configuration file (CLAUDE.md) specifying: page types and their markdown templates, slug and title naming conventions, the ingest protocol (step-by-step), the query protocol, the lint protocol, and general rules (never delete a page; prefer updating over creating near-duplicates; sources first). The schema is what makes the LLM's maintenance behavior reproducible and consistent across sessions. Without it, each session would invent different conventions.

Three Operations

Ingest

Triggered when a new source is added to the raw folder.

1. Read the source
2. Discuss key takeaways with the user
3. Write a source page in wiki/sources/
4. Create or update all concept and entity pages the source touches
5. Update wiki/index.md
6. Extract and merge new bibliography entries
7. Append to wiki/log.md

The critical step is 4: each new source is cross-linked into the existing knowledge structure. A paper about manufacturing decline updates pages on marriage market, mortality, intergenerational mobility, and commuting zones — not just the paper's own summary page. This is where compounding happens.

Query

Triggered when the user asks a question.

1. Read wiki/index.md to locate relevant pages
2. Read those pages
3. Synthesize an answer with [wikilink](/wiki/demography) citations
4. Offer to file the answer as a new concept page if it represents a new synthesis

The query operation can itself produce new wiki pages — insights discovered during conversation become permanent entries rather than being lost at session end.

Lint

Triggered periodically as a health-check.

• Flag orphan pages (no inbound links from any other page)
• Flag contradictions between pages
• Suggest missing concept pages implied by existing content
• Suggest gaps: concepts mentioned in sources but not yet extracted

Lint is not a per-ingest operation — it is a periodic audit designed to catch structural decay before it accumulates.

Contrast with RAG

Dimension	RAG	LLM Wiki
Knowledge layer	Vector database of document chunks	Human-readable markdown concept pages
Per-query work	Retrieve and synthesize from scratch	Read pre-compiled, cross-linked pages
Accumulation	None — stateless between sessions	Persistent — each ingest compounds the structure
Cross-document synthesis	Re-derived each query	Pre-compiled at ingest time, stored permanently
Auditability	Black-box retrieval pipeline	Every page is human-readable and correctable
Ownership	Often cloud-hosted, proprietary	Local files, no vendor lock-in
Failure mode	Missing relevant chunks, inconsistent answers	Hallucination baked into permanent pages; schema drift
Best for	Lookup tasks, single-document question and answer (Q&A)	Multi-source synthesis, compounding research

RAG's strength is breadth and setup speed — it can handle large unstructured document collections without human curation. The LLM Wiki's strength is depth and accumulation — it is optimized for domains where the relationships between ideas matter as much as the individual documents themselves.

The Schema as the User's Intelligence

The schema file is the most underappreciated component of the pattern. A raw LLM without a schema will produce inconsistent page formats, invent different conventions across sessions, and fail to enforce rules like "never delete a page" or "prefer updating existing pages over creating near-duplicates." The schema converts a general-purpose LLM into a specialized, disciplined knowledge-base maintainer.

Key schema elements:

• Page templates — enforces consistent structure across all concept, entity, and source pages
• Naming conventions — kebab-case slugs, title-case page titles, year suffixes for ambiguous sources
• Ingest protocol — step-by-step ordered instructions ensuring nothing is skipped
• General rules — "sources first" (every claim traces back to a source page), "one concept per page" (prevents bloat), "never delete" (marks deprecated pages with status: deprecated and points to replacement)

Without these constraints, the wiki becomes inconsistent over time — pages drift in format, links break, and the accumulated structure loses reliability as a reference.

Failure Modes (Not Covered by the Source Article)

• Hallucination baked in permanently. Unlike RAG, where a bad retrieval produces a bad answer that disappears, an LLM Wiki ingest can write incorrect claims into concept pages that persist and propagate into future answers until caught by lint or user review.
• Schema drift. If the schema is updated but old pages aren't audited, the wiki develops inconsistent formatting and linking conventions across cohorts of pages.
• Page proliferation without pruning. Without a lint discipline, stub pages and near-duplicate concepts accumulate, fragmenting the knowledge structure.
• Source recency. The wiki is only as current as its ingests. Unlike a live RAG pipeline over a frequently updated document corpus, the LLM Wiki requires explicit re-ingestion when sources change.
• Token budget scaling. As the wiki grows, the index and individual pages become longer. Operations that require reading many pages simultaneously (lint, complex multi-page queries) may hit context limits.

Why It Matters

The LLM Wiki represents a shift in how LLM agents are used — from stateless question-answering tools to persistent knowledge infrastructure maintainers. The compounding property is the key value: the 100th source ingested benefits from the structure built by the first 99, producing cross-links and updated pages that no single-session RAG query could replicate. Over time, the wiki becomes an asset that is qualitatively more valuable than the raw document collection it was built from — because it contains the synthesized, cross-referenced understanding of all those documents, not just the documents themselves.

Open Questions

• How should the wiki handle sources that update over time (living documents, revised papers)?
• At what scale does the index become too long for efficient navigation, and how should it be paginated or hierarchically organized?
• How should multi-user or team wikis handle conflicting edits or concurrent ingests?
• Can lint be automated on a schedule (e.g., weekly) rather than requiring explicit user invocation?
• What is the right balance between page granularity (one concept per page) and page density (more content per page for richer context)?

This Wiki's Schema (CLAUDE.md)

This wiki is itself an instance of the LLM Wiki pattern. The schema file (CLAUDE.md at the repo root) is reproduced below for reference — it is the document that governs all ingest, query, and lint operations in this knowledge base.

# Wiki Schema

## Structure
- `raw/`             → immutable sources, never modified
- `wiki/sources/`    → one .md per ingested source
- `wiki/concepts/`   → one .md per concept/topic
- `wiki/entities/`   → one .md per person/org/product
- `wiki/index.md`    → master index, updated on every ingest
- `wiki/log.md`      → append-only log

## Page Format

Each wiki page uses `[Wikilinks](/wiki/demography)` to cross-reference other pages.
Link text must match the `title:` field of the target page exactly.

**Frontmatter (all page types):**
---
title:
tags: []
sources: []
updated: YYYY-MM-DD
---

### Concept page — `wiki/concepts/<slug>.md`
---
title:
tags: []
sources: []
updated: YYYY-MM-DD
---

## Definition
One precise paragraph.

## Key Ideas
- ...

## How It Works
Mechanistic explanation if applicable.

## Why It Matters
Significance, use cases, implications.

## Open Questions
Things still uncertain or debated.

## Related
- [Other Concept](/wiki/demography)
- [Entity Name](/wiki/demography)

### Entity page — `wiki/entities/<slug>.md`
---
title:
tags: []
sources: []
updated: YYYY-MM-DD
---

## Overview
One paragraph.

## Key Contributions / Features
- ...

## Related
- [Concept](/wiki/demography)
- [Other Entity](/wiki/demography)

### Source page — `wiki/sources/<slug>.md`
---
title:
tags: []
sources: []
updated: YYYY-MM-DD
kind: paper | article | book | video | note
author:
date: YYYY-MM-DD
url:
---

## Summary
2–4 sentences in your own words.

## Key Claims
- ...

## Concepts Introduced or Extended
- [Concept](/wiki/demography)

## Entities Mentioned
- [Entity](/wiki/demography)

## Quotes
> "..."

## My Take
Critical assessment, caveats, disagreements.

---

## Operations

### Ingest
When I say "ingest [file]":
1. Read the source in `raw/`
2. Discuss key takeaways with me
3. Write `wiki/sources/<slug>.md`
4. Create or update concept and entity pages it touches
5. Update `wiki/index.md`
6. Extract the paper's reference list and merge new entries into `wiki/bibliography.md`
7. Append to `wiki/log.md`

### Query
When I ask a question:
1. Read `wiki/index.md` to find relevant pages
2. Read those pages
3. Synthesize an answer with `[page](/wiki/demography)` citations
4. Ask if I want to save the answer as a new wiki page

### Lint
When I say "lint the wiki":
- Flag orphan pages (no inbound links from any other page)
- Flag contradictions between pages
- Suggest missing concept pages implied by existing content
- Suggest gaps: concepts mentioned in sources but not yet extracted

---

## Naming Conventions
| Item | Rule | Example |
|---|---|---|
| Concept slug | kebab-case | `attention-mechanism` |
| Entity slug | kebab-case | `andrej-karpathy` |
| Source slug | kebab-case, year suffix if ambiguous | `attention-is-all-you-need-2017` |
| Page title | Title Case | `Attention Mechanism` |

## General Rules
- **Never delete** a page. Mark `status: deprecated` in frontmatter and point to the replacement.
- **Prefer updating** existing pages over creating near-duplicates. Check the index first.
- **Sources first.** Every claim in a concept page should trace back to a source page.
- **One concept per page.** Split pages that grow unwieldy; link the parts.

Related

• Retrieval-Augmented Generation
• Andrej Karpathy

Sources

• Ditto 2026 — Why Andrej Karpathy's LLM Wiki is the Future of Personal Knowledge