Operational Guide: Building a Compounding Knowledge Base with LLMs¶
1. The Paradigm Shift: From Ephemeral RAG to Persistent Wiki¶
Most contemporary implementations of Large Language Models (LLMs) rely on Retrieval-Augmented Generation (RAG). While functional for isolated lookups, RAG is fundamentally ephemeral; the system is forced to "rediscover" knowledge from scratch for every query. The LLM Wiki pattern represents a transition from volatile retrieval to long-term knowledge compilation.
| Dimension | Ephemeral RAG | Persistent LLM Wiki |
|---|---|---|
| Knowledge Retention | Volatile; knowledge is discarded after the session. | Permanent; grows as a compounding, interlinked artifact. |
| Synthesis Depth | Surface-level; limited to retrieved fragments. | Deep; reflects an evolving, citable, and interlinked thesis. |
| Cost of Curiosity | High; requires re-processing and re-billing for same data. | Low; knowledge is "pre-compiled" for immediate utility. |
For the learner, the wiki acts as a persistent repository where understanding compounds. Instead of forcing an LLM to piece together fragments of several documents every time a question is asked, the wiki ensures those connections are already established, contradictions are flagged, and summaries are current. This structural approach allows the user's intellectual capital to accumulate rather than reset with every new chat window.
Architecture is the prerequisite for automation; to support this compounding growth, we must move from a single prompt to a structured, three-layer system design.
2. The Three-Layer Architecture¶
A professional-grade LLM Wiki is organized into three distinct structural layers. Each layer is governed by specific rules of ownership and mutability to ensure data integrity and system reliability.
- Layer 1: Raw Sources (The Data Substrate)
- Primary Owner: Human (Curator)
- Mutability: Immutable (The LLM reads these; it never modifies them)
- Function: This is the absolute "Source of Truth," consisting of original articles, research papers, image assets, and data files.
- Layer 2: The Wiki (The Knowledge Layer)
- Primary Owner: LLM (Maintainer)
- Mutability: Mutable (The LLM creates, revises, and deletes these files)
- Function: A structured directory of Markdown files. It contains entity pages, concept summaries, and comparative analyses that represent the compiled understanding of Layer 1.
- Layer 3: The Schema (The Instructional Logic)
- Primary Owner: Human + LLM (Collaborators)
- Mutability: Mutable (Co-evolved over time)
- Function: The configuration layer (e.g.,
AGENTS.mdorCLAUDE.md). It defines the Ontology (naming conventions), Provenance (how we track sources), and the specific workflows the LLM must follow to remain a disciplined maintainer.
"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
Once the structural layers are established, the system moves from static storage to a dynamic data flow through its core operations.
3. Core Operation I: Ingestion and Integration¶
Ingestion is an active synthesis process, not a passive file transfer. When new information enters the ecosystem, it triggers a ripple effect across the entire knowledge graph.
- Source Entry: The human curator places a new document into the Raw Sources directory.
- Dialogue Phase: Before writing, the LLM reads the source and discusses key takeaways with the human. This Human-in-the-loop (HITL) gate ensures the synthesis aligns with the user's specific intent and goals.
- Active Integration: The LLM executes "downstream effects." A single source might touch 10-15 different wiki pages. The LLM will:
- Draft a dedicated summary page.
- Update the
index.mdcatalog with a one-line summary and metadata. - Revise existing entity or concept pages to integrate new insights.
- Identify and flag contradictions where new data challenges existing claims.
- Audit Logging: The LLM appends a chronological entry to the
log.md.
Incremental building is superior to batch processing because it allows for high-fidelity quality control during the dialogue phase. This meticulously integrated storage serves as the high-context foundation for all subsequent queries.
4. Core Operation II: Querying and Recursive Filing¶
Asking questions against a wiki is a multi-stage search operation that prioritizes the "Global Map" of the index before drilling into specific data.
- The Query Flow: The LLM is instructed to look at the
index.mdfirst to gain a bird's-eye view of the knowledge base. It then selects relevant wiki pages to synthesize a citable answer. - Recursive Filing: High-quality outputs—such as a complex comparison table or a novel connection discovered during a chat—should never be lost to chat history. The LLM should automatically convert these outputs into new wiki pages, allowing emergent themes to compound the system's value.
Common query output formats include: * Markdown Pages: Deep-dive articles or thematic summaries. * Comparison Tables: Side-by-side evaluations of entities or technologies. * Slide Decks: Presentations (often in Marp format) generated from the accumulated context.
As the knowledge base expands through ingestion and recursive filing, the system requires periodic maintenance to prevent the decay of data integrity.
5. Core Operation III: Linting and Health Checks¶
"Linting" is the systematic review of the knowledge codebase to ensure health and consistency. Beyond standard checks, advanced users implement Adversarial Review, where a second, independent LLM is tasked with interrogating wiki pages for overreach or unsupported generalizations.
The LLM should follow this health-check checklist during every linting pass:
- Contradictions: Identify and surface conflicts between new data and legacy entries.
- Stale Claims: Highlight claims that have been superseded by more recent ingestions.
- Orphan Pages: Detect pages lacking inbound links to ensure the graph remains connected.
- Data Gaps: Identify concepts mentioned in text that lack dedicated pages or require external research.
- Three-State Status: Verify if pages are in the correct state (Draft → Verified → Published).
Rigorous maintenance ensures that navigation remains fluid and the "Global Map" remains accurate.
6. The Navigational Spine: Indexing and Logging¶
To eliminate the immediate need for resource-heavy "embedding-based RAG" at a moderate scale (~100 sources), the system utilizes two specialized files that provide the LLM with immediate context.
| index.md (Content-Oriented) | log.md (Chronological) |
|---|---|
| Role: A global catalog and roadmap for the LLM. | Role: An append-only audit trail of system activity. |
| Structure: Organized by category (Entities, Sources, Concepts). | Structure: Chronological entries with Unix-parseable prefixes. |
| Requirement: Each entry includes a link, a one-line summary, and metadata (e.g., date, source count). | Example: ## [2026-04-02] ingest \| Title (Allows for grep parsing and timeline analysis). |
The index.md allows the LLM to fit the entire scope of the knowledge base into its context window, providing a superior navigational logic compared to standard chunked retrieval. Enhancing this system requires integrating specialized tools from the wider ecosystem.
7. The Tooling Ecosystem and Best Practices¶
Obsidian Integration¶
Obsidian is the primary "IDE" for the wiki. Use the Web Clipper for clean Markdown ingestion. Crucially, set up Local Image Downloading (Settings → Files and Links → Attachment folder path). Downloading images locally ensures Image Provenance; it prevents broken URLs and allows the LLM to reference visual assets via local paths, ensuring long-term persistence.
Visualization and Logic¶
The Graph View is used to identify hubs of knowledge and isolated orphans. To treat the wiki like a database, utilize the Dataview plugin. By having the LLM add YAML frontmatter (tags, source quality, dates), you can generate dynamic tables that update automatically as the wiki grows.
Scaling and Token Economics¶
At scale, use CLI tools like qmd for local search or MCP servers to turn wiki operations into native agent tools. For cost efficiency, utilize tools like sqz for de-duplication. When an agent reads the same file multiple times in a session, sqz replaces the repeated text with a 13-token reference, significantly reducing context usage and billing.
These tools collectively minimize the "Human Maintenance Burden," which is the primary reason personal wikis historically fail.
8. Conclusion: The Zero-Cost Maintenance Future¶
The dream of a personal, associative knowledge store dates back to Vannevar Bush’s 1945 "Memex." Historically, these systems were abandoned because the manual bookkeeping—updating cross-references and revising summaries—outpaced the value of the knowledge itself.
By offloading the "grunt work" of summarization and filing to LLMs, the cost of maintenance drops to near zero. Your role is elevated from bookkeeper to Senior Architect and Strategist, focusing on high-level curation and the discovery of novel connections.
Call to Action: Begin today by sharing this operational guide with your LLM agent and collaboratively drafting your first AGENTS.md schema to transform your fragmented notes into a compounding asset of intelligence.