How the LLM Wiki pattern works
Follow raw sources into a persistent, linked wiki that an agent can ingest, query, lint, and improve instead of rebuilding context.
The whole story in 7 lines
See how sources are ingested, compiled into a maintained wiki, queried, linted for gaps, and improved after every answer.
- Plain retrieval starts over for each question, while a maintained wiki preserves structure that later questions can reuse.
- Raw sources preserve evidence, the schema defines maintenance rules, and linked wiki pages hold the compiled knowledge.
- Ingestion connects each new source to every affected page instead of storing one isolated summary.
- Compilation refreshes indexes, links, and syntheses so the wiki remains coherent as its evidence changes.
- Queries begin with the wiki index and open only the linked pages needed to answer with traceable evidence.
- A lint pass surfaces stale claims, contradictions, missing pages, and thin evidence as explicit maintenance work.
- Ingest, query, and lint form a flywheel because each useful interaction can improve the maintained knowledge base.
Setup
Most people's experience with AI and documents looks something like this: you upload a pile of files, ask a question. And the AI digs through the pile to find an answer. It works, but the AI is rediscovering knowledge from scratch on every question. Ask something subtle that requires combining five different papers, and it has to piece together the fragments every single time. Nothing is built up. Nothing accumulates.
Two terms on the left, which completes this part of the mechanism. RAG stands for Retrieval-Augmented Generation. It is how most AI-plus-documents tools work today: look up relevant chunks, then generate an answer. A wiki is a collection of interlinked pages, each covering one topic and linking to related ones. The core idea of this pattern is that the AI incrementally builds and maintains. A wiki for you, instead of re-deriving everything from raw documents on every question.
Two more. A schema is a configuration file you and the AI write together over time. It says how to name pages, what to do when sources disagree, and what workflows to follow. Think of it like the training manual for a new employee. Ingestion is the full process of reading a new document, extracting what matters, and weaving it into the existing wiki. A single source might touch ten to fifteen wiki pages.
The roadmap now adds two maintenance actions. Compiling revises pages, strengthens links, and keeps the index current. Linting checks for stale facts, orphan pages, and claims that newer sources have replaced. Think of linting as a health check that catches small cracks before they become wrong answers.
Here is the key idea behind these four terms. You never write the wiki yourself. The AI writes and maintains all of it. Your job is to curate sources, ask good questions, and direct the analysis. The AI does the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time.
This pattern works for all kinds of projects. Research deep-dives across hundreds of papers. Personal knowledge bases for health, goals, or self-improvement. Reading a book and building a companion wiki with characters, themes, and plot threads. Business teams fed by Slack threads, meeting transcripts, and project documents. Anything where you accumulate knowledge over time and want it organized, not scattered.
The roadmap on the right shows our seven stops. We will start by seeing why plain RAG falls short. Then we will build the three-layer architecture, follow a document through ingestion, see a maintenance pass, run a query, learn about linting. And watch the whole flywheel spin. Let us start with the most basic question: what goes wrong when every answer is built from scratch.
Why Plain RAG Resets
★ If you remember one thing · Plain retrieval starts over for each question, while an LLM Wiki preserves compiled structure that later questions can reuse.
A question arrives at the top and the system goes straight to the RAW SOURCES panel to hunt for relevant pieces. This is how NotebookLM, ChatGPT file uploads, and most RAG tools work. You ask, it searches, it answers. Seems fine.
The system stitches together an answer from raw fragments and hands it over. Then it forgets everything it just figured out. Next question. Same pile, same digging, same cost. Every cross-document connection, every synthesis, rebuilt from scratch. Nothing from the last answer carries forward.
The stage has reached the decision that determines its next state. Which question can one maintained wiki page answer without joining several pages?
Now look at the PERSISTENT WIKI column on the right. When a wiki exists, the hard work of reading, connecting, and synthesizing documents has already been done in earlier sessions. The cross-references are already built. The contradictions have already been flagged. The synthesis already reflects everything you have read.
Switch the Question control through every choice. Compare the downstream outcome while the earlier input and system boundary remain fixed.
The problem with plain RAG is not speed. It is that nothing accumulates. The wiki is the fix: a persistent layer where knowledge is compiled once and kept current, not re-derived on every question. Now let us see what that wiki actually looks like inside.
Three-Layer Stack
The source sheets on the left preserve your curated documents: articles, papers, transcripts, and images. These originals are immutable, so the AI reads them without rewriting the evidence. The separate shapes matter because a source archive is not yet a wiki. It is the stable material the other layers transform.
Different projects can fill those sheets with academic papers, journals, Slack threads, transcripts, or customer calls. The content changes, but the ownership boundary stays intact. Keeping the originals recognizable and separate gives every later page a trail back to its evidence.
The middle layer is the SCHEMA. In practice, a file like CLAUDE.md or AGENTS.md tells the AI how to name pages and handle ingestion or contradictions. You and the AI refine these rules as you learn what works for the domain. A lighter schema narrows the rule set without changing the raw evidence.
The stage has reached the decision that determines its next state. Which layer should preserve imported evidence without rewriting it?
The compiler now emits a small graph of folded pages. That graph is the wiki: summaries, entity pages, concept pages, and the links between them. The AI creates and updates this compiled layer while you inspect it through your reading tool. Unlike the source sheets, these pages are designed to evolve.
Three layers, three owners. Raw sources are yours and stay untouched. The schema is co-owned and evolves with your needs. The wiki is the AI's domain. The whole thing is just a git repo of markdown files, so you get version history, branching, and collaboration for free. Now let us see what happens when a new document arrives.
Ingest a Source
A new document has landed in the SOURCE panel. Maybe you clipped an article from the web using Obsidian Web Clipper, or dropped a paper PDF into the raw directory. In the plain RAG world we saw in Stage 1, this file would just sit in the pile. Here, something very different happens.
The AI reads the full document rather than matching only keywords. It extracts claims, important details, and metadata, then discusses the takeaways with you. A transcript emphasizes speakers and decisions, while another source type carries different evidence.
Next the AI writes a SUMMARY page in the wiki. This is not a filename sitting in a folder. It is a real wiki page that captures what the source says and why it matters, with links to the related concept and entity pages. You read the summary in Obsidian, check it, and guide the AI on what to emphasize.
Now the most important part. The AI walks through every existing wiki page that overlaps with this source and updates each one. A new finding about a concept lands on that concept's page, while a detail about a person lands on that person's page. Batch ingestion can process several sources with less hand-holding, but every update still needs traceable evidence.
The final fragment lands in a chronological log strip. That entry records when the source arrived, which pages changed, and what was added. The source remains intact on the left while the summary, related pages, and log preserve separate views of the same ingest. That trace makes later maintenance auditable.
The document has been read, summarized, and woven into the existing wiki across multiple pages. The knowledge is compiled once, not waiting to be re-derived on every future question. But those updated pages now need a consistency check. Let us see what a maintenance pass looks like.
Compile the Wiki
Now that ingestion touched several pages, compilation checks the connected page graph as one maintained artifact. Remember how plain RAG rebuilt links for every question. Here the links persist, so the job is to revise pages and verify that the connections still match the evidence.
Every page that overlaps with the new material gets revised. A single new article can ripple through half the wiki, updating topic summaries, entity pages, and syntheses. This is the tedious bookkeeping that kills hand-maintained wikis. The AI does it in one pass.
Cross-links between pages get strengthened when the evidence supports a relationship. Sparse links leave more isolated pages, while dense linking creates more navigation paths. The graph view then exposes hubs, orphans, and clusters without replacing the source citations behind them.
Here is where the wiki earns trust. When new evidence contradicts an existing claim, the affected page develops a visible conflict seam and a repair item appears below the graph. The AI does not silently overwrite the old claim. It preserves the disagreement so a human can decide what the evidence supports.
The index.md file gets refreshed. This file is content-oriented: a catalog of every page with a one-line summary, organized by category. When the AI answers a question later, it reads this index first to find relevant pages, then drills in. This works surprisingly well even at around a hundred sources without needing any embedding-based RAG infrastructure.
A dated entry in log.md closes the pass. The log is chronological: what happened and when. Ingests, queries, lint passes, all timestamped. You can grep through it to see recent activity. Now the wiki is maintained, the index is current, and contradictions are surfaced. Let us actually use it to answer a question.
Query the Wiki
A question arrives at the ASK boundary. Plain retrieval would search raw documents again, but this path starts from the maintained wiki index and its persistent links.
It goes to index.md, the catalog refreshed during compilation. The index points the AI toward relevant pages so it opens only the ones it needs. A focused question may use one page, while a thesis requires a broader linked set.
Here is the payoff for all the earlier work. Those pages were written during ingestion and kept current during compilation. The synthesis is already there. The cross-references are already built. The contradictions have already been flagged, which completes this part of the mechanism. The AI reads what exists instead of rebuilding it from raw fragments. All that maintenance was the investment. This is the return.
The ANSWER panel assembles a response with citations pointing back to specific wiki pages. You can click through to the cited pages in Obsidian and read the full context. No vague references to documents you would have to hunt down.
Answers do not have to be plain text. The same compiled pages can support a comparison grid or a Marp slide deck in Obsidian. The output format changes, but the maintained wiki and its source links remain the evidence base.
Here is the crucial insight: good answers should not disappear into chat history. If an answer is worth keeping, it can be filed back into the wiki as a new page. A comparison you asked for, an analysis, a connection you discovered. Your explorations compound in the knowledge base just like ingested sources do. But a growing wiki can also develop problems. Let us see how to catch those.
Lint for Gaps
The GRAPH SLICE panel shows a piece of your wiki as a network of nodes and connections. This is what Obsidian's graph view looks like in practice: you can see which pages are hubs, which are orphans, and where the connections are thin. Remember the schema from Stage 2. It keeps conventions consistent, but it cannot prevent every kind of drift over time.
The LINT pass walks through every page systematically. One check finds claims that newer sources have superseded, while another finds pages that contradict each other. Both produce maintenance work instead of silently rewriting uncertain knowledge.
What it finds becomes a concrete list in the ISSUES panel. These are specific problems you can act on, not vague hunches. One page may contradict another. A concept may appear repeatedly without its own page. A claim may not have been revisited after several new sources arrived.
With more pages visible you can see where connections are dense and where they are sparse. The AI is good at noticing structural gaps that are hard to spot by reading pages one at a time.
The AI can also suggest what to read or search for next. A thin spot in the wiki becomes a concrete reading list with questions to investigate and sources to seek. These suggestions remain hypotheses until new evidence is actually ingested.
Linting keeps the wiki healthy as it scales. At a hundred sources and hundreds of pages, you cannot manually check everything. But the AI can run a health check in one pass and surface the problems worth your attention. Now we have all four operations: ingest, compile, query, and lint. Let us see what happens when they run together.
Compound the Flywheel
Every cycle starts with human direction. You bring a source, a question, or a suspicion that part of the wiki needs repair. The eye at the top represents that judgment, while the timeline below preserves the wiki after each session. Your choices determine what enters the system.
The reading window beside you is how the maintained pages become useful. You browse pages, follow links, inspect the graph, and check updated summaries. Obsidian can provide that window, while the AI maintains markdown under your rules and the wiki remains the shared artifact.
The timeline now shows a second wiki snapshot with more pages and links. Ingestion adds material, compilation revises connections, querying follows them, and linting exposes weak spots. All four operations act on the same shared markdown structure, so their gains survive into the next session.
A useful answer now appears below the timeline, and one of its evidence strips travels back toward the wiki. This is the compounding trick from the query stage. A comparison, analysis, or connection worth keeping can become a maintained page instead of disappearing into chat history.
The third snapshot makes the payoff visible. It contains more pages and more connections than either earlier version, while the returned answer fragment has become part of that structure. Each visit can leave reusable knowledge behind, so later questions traverse a richer graph instead of rebuilding the same synthesis.
The reason most hand-maintained wikis die is that the maintenance burden grows faster than the value. Updating cross-references, keeping summaries current, noting contradictions, maintaining consistency across dozens of pages. Humans give up. The AI does not. It never gets bored, never forgets to update a cross-reference, and can touch fifteen files in one pass. You bring the curiosity and judgment. The AI brings the patience. Let us step back and see the whole picture.
Recap
We started with the problem. Plain RAG forgets everything between questions. It digs through raw documents, stitches together an answer, and throws away all the work. NotebookLM, ChatGPT uploads, most RAG tools. Same pattern, same limitation. Nothing accumulates, which completes this part of the mechanism.
The fix was a three-layer stack. Raw sources at the bottom stay immutable, your source of truth. The schema in the middle turns the AI from a generic chatbot into a disciplined wiki maintainer. The wiki at the top is a persistent, compounding artifact of markdown files that the AI writes and you browse.
Ingestion is how new knowledge enters. The AI reads a source, writes a summary page, and updates every related page across the wiki. A single source can touch ten to fifteen pages. The knowledge is compiled once and kept current, not re-derived on every future question.
Compilation is the maintenance pass. Pages get revised, cross-linked, and indexed. Contradictions get flagged, not buried. The index.md catalog gets refreshed so the AI knows what exists. This is the tedious bookkeeping that kills hand-maintained wikis, and the AI does it every single time.
Querying is where the investment pays off. The AI reads the wiki first, not the raw pile. The synthesis is already there, the links are already built. Answers come back as markdown pages, comparison tables, slide decks, whatever fits the question. And good answers get filed back into the wiki so your explorations compound.
Linting catches the cracks before they cause wrong answers. Contradictions between pages, stale claims, orphan pages, concepts mentioned everywhere but lacking their own page. The AI turns vague unease into a concrete checklist and even suggests what to search for next.
The flywheel connects all four operations. Each ingest adds knowledge. Each query can grow the wiki with a new page. Each lint pass removes rot. The wiki compounds because the AI does the maintenance that humans would skip. The ten-source wiki becomes a hundred-source wiki, and the answer path gets cheaper every time.
Here is the one idea worth remembering. The LLM Wiki Pattern works because it pairs human judgment with machine patience. You choose what matters, curate sources, ask the right questions, and direct the analysis. The AI handles the summarizing, cross-referencing, filing, and bookkeeping that nobody wants to do by hand. Together, the knowledge base gets smarter every single time you use it.
The whole story in 7 lines
See how sources are ingested, compiled into a maintained wiki, queried, linted for gaps, and improved after every answer.
- Plain retrieval starts over for each question, while a maintained wiki preserves structure that later questions can reuse.
- Raw sources preserve evidence, the schema defines maintenance rules, and linked wiki pages hold the compiled knowledge.
- Ingestion connects each new source to every affected page instead of storing one isolated summary.
- Compilation refreshes indexes, links, and syntheses so the wiki remains coherent as its evidence changes.
- Queries begin with the wiki index and open only the linked pages needed to answer with traceable evidence.
- A lint pass surfaces stale claims, contradictions, missing pages, and thin evidence as explicit maintenance work.
- Ingest, query, and lint form a flywheel because each useful interaction can improve the maintained knowledge base.