LLM-as-Compiler Knowledge Base

Sources#

• An open-source spec for Codex orchestration: Symphony.
• Beyond RAG: Building Agentic Document Workflows with LlamaIndex
• Knowledge-Centric Self-Improvement
• LLM Knowledge Bases
• llm-wiki
• The New Physics of Business — Garry Tan, Y Combinator
• The State of Agent Wikis

Summary#

An architecture pattern originated by Andrej Karpathy where an LLM functions as a compiler: it reads raw source documents and incrementally produces a structured, interlinked markdown wiki. Unlike traditional RAG systems that rely on embeddings and vector databases, this approach uses the wiki's own index files and the LLM's context window for retrieval, which is sufficient at personal knowledge base scale (~100 articles, ~400K words).

Details#

Four-Phase Pipeline#

The system operates as a continuous cycle:

1. Ingest — Raw content (web articles via Obsidian Web Clipper, papers, repo notes) lands in a raw/ staging directory as markdown files.
2. Compile — The LLM reads raw/ and builds index files (summaries of all documents), concept articles (organized by topic with backlinks and cross-references), and derived outputs (slides, charts, filed query answers). The LLM auto-maintains the link graph between concepts.
3. Query & Enhance — Users browse the wiki in Obsidian, ask research questions via a Q&A agent, or search via a CLI/web tool. Critically, all outputs from queries are filed back into the wiki, so every exploration compounds.
4. Lint & Maintain — The LLM audits for inconsistencies, imputes missing information via web search, discovers new inter-concept connections, and suggests further questions. After linting, the cycle returns to compile.

Key Design Decisions#

• No vector database — At personal scale, index files + LLM context window are sufficient for retrieval. This eliminates embedding pipeline complexity. At larger scale, a local search engine like qmd (hybrid BM25/vector search with LLM re-ranking, available as CLI and MCP server) can supplement the index.
• Incremental compilation — New raw documents are integrated into existing wiki structure; already-indexed documents are never reprocessed.
• Explorations always compound — Every query answer, chart, and derived artifact is filed back into the wiki. This is the core differentiator vs. RAG: knowledge is compiled once and kept current, not re-derived on every query.
• LLM does the writing — The human rarely edits the wiki directly; the LLM compiles, links, and maintains it. The human's job is sourcing, exploration, and asking the right questions.
• Wiki as persistent, compounding artifact — Cross-references are already there, contradictions already flagged, synthesis already reflects everything read. The wiki gets richer with every source added and every question asked.

Three-Layer Architecture (from Karpathy's Gist)#

Karpathy's original design document makes the architecture explicit:

1. Raw sources — curated, immutable source documents (articles, papers, images, data). The LLM reads but never modifies these. This is the source of truth.
2. The wiki — LLM-generated markdown files: summaries, entity pages, concept pages, comparisons, synthesis. The LLM owns this layer entirely — creates, updates, cross-references, maintains consistency. The human reads it.
3. The schema — a configuration document (CLAUDE.md / AGENTS.md) that tells the LLM how the wiki is structured, what conventions to follow, and what workflows to execute. Human and LLM co-evolve this over time.

Indexing and Navigation#

Two special files help navigate the wiki at scale:

• index.md — content-oriented catalog of every page with one-line summaries, organized by category. The LLM reads this first when answering queries, then drills into relevant pages. Works well at moderate scale (~100 sources, ~hundreds of pages).
• log.md — chronological, append-only record of operations (ingests, queries, lint passes). Parseable with unix tools if entries use consistent prefixes (e.g., ## [2026-04-02] ingest | Article Title).

Use Cases#

The pattern applies broadly:

• Personal: goals, health, psychology — filing journal entries, articles, podcast notes
• Research: reading papers over weeks/months, building a comprehensive wiki with an evolving thesis
• Reading a book: chapter-by-chapter companion wiki with characters, themes, plot threads (like a personal fan wiki)
• Business/team: internal wiki fed by Slack threads, meeting transcripts, customer calls, with humans reviewing updates
• Any knowledge accumulation: competitive analysis, due diligence, trip planning, course notes

Why It Works#

The bottleneck of knowledge bases is not reading or thinking — it's bookkeeping. Updating cross-references, keeping summaries current, noting contradictions, maintaining consistency across dozens of pages. Humans abandon wikis because maintenance burden grows faster than value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass.

Intellectual Lineage#

Karpathy draws a connection to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with connections between documents as valuable as the documents themselves. The part Bush couldn't solve was who does the maintenance. The LLM handles that.

Variations#

Elvis Saravia describes a variant where ingestion is automated: a tuned Skill agent curates research papers daily, indexes them with the qmd CLI tool, and feeds the indexed knowledge base into an interactive artifact generator built with MCP tools. This produces explorable, interactive visualizations across hundreds of papers.

Future Direction#

Karpathy mentions using the wiki to generate synthetic training data and fine-tune an LLM so it "knows" the data in its weights — turning a personal knowledge base into a personalized model.

The agent-wiki landscape: four implementations in three months (July 2026)#

A vendor survey (mem0's In Context #17, "The State of Agent Wikis," 2026-07-21, practitioner-opinion — COI: mem0 sells the user-memory layer its closing section advocates) gives the pattern its field name — agent wikis — and its first landscape: within roughly three months of the April 2026 gist, four teams shipped the same three-layer structure (immutable sources; model-written markdown wiki; schema file, "usually CLAUDE.md or AGENTS.md") against four different corpora. The survey's convergence argument: "Four teams solved four different problems and made the same structure. This agreement is good evidence that the structure is correct."

System	Corpus	Currency	Written for
DeepWiki (Cognition)	any public GitHub repo; 50K+ largest pre-indexed (URL-swap github.com → deepwiki.com)	re-indexed; grounds Devin	agents, and humans browsing
AutoWiki (Factory)	your org's repos	CI refresh, every push	engineers and Droids together
OpenWiki / Brains (LangChain)	repos (Code Brain) + Gmail, Notion, git, X, HN (Personal Brain)	re-run to refresh	"LLM context, not human prose"
GBrain (Garry Tan)	personal sources	manual or scheduled runs	a person and their agent

(Table from the survey's matrix figure. Its prose flattens the last column to "the reader of the wiki is a model"; the matrix itself contradicts that for three of the four systems — only OpenWiki is model-only.)

What each implementation adds beyond the gist:

• DeepWiki: the wiki as agent infrastructure, not documentation. "The wiki is not the product. The wiki is retrieval infrastructure for the agent" — Devin uses DeepWiki as the compiled layer below its code search. This is the ingest-time counterpart of Repository Exploration Subagent's query-time explorer: both decouple repo grounding from solving, one by precomputing a per-repo artifact every agent shares, the other by searching per task in a disposable window.
• AutoWiki: maintenance moved into infrastructure. Documentation as a build artifact — /install-wiki writes a CI workflow that regenerates the wiki on every push to the default branch. Generation is two-pass (structural scan of README/manifests/CI config/entry points, then semantic scan of routes/endpoints/service classes/schemas/feature flags), fanned out across specialized agents so no single agent documents a whole large repo. See Code as Source of Truth for how this composes with checking truth into the repo.
• OpenWiki: the leap from repo to everything. Personal Brain compiles Gmail, Notion, git, X, and Hacker News into one local markdown wiki — "documentation of your work," not of a repository.
• GBrain: the minimal-infrastructure proof. No vector database, no service — markdown in git, a schema file, an auto-maintained link graph. (The survey files GBrain as the personal-scale member; Tan's own talk presents it as a company brain with his ~220K-page personal instance as the exhibit — the two agree on the artifact and differ on the ambition. Full treatment below.)

The axis the survey calls "the maturity tell": Factory treats staleness as a build problem and solves it in CI; the other three — and this vault — are exactly as current as the last time someone ran the command.

The survey's four limits, worth recording because this wiki lives them: (1) scale — the gist's ~100-source ceiling before search must be added (DeepWiki, at 50K+ repos, ships search per wiki); (2) compile-time loss — "an early summary can remove a detail from the source. Each later answer has this error. Retrieval from the raw parts does not have this problem. You exchange the cost of repeated work for the risk of lost data" — the architectural risk this vault's parse-warning discipline manages, and exactly the L2-condensation omission that Layerwise Omission Attribution shows how to count with canary taps; (3) staleness — "an incorrect wiki is worse than no wiki. The incorrect information has the format of correct information"; (4) cost — tokens spent compiling pages nobody reads and linting pages that did not change.

A wiki is not memory (the vendor's boundary)#

The survey's closing distinction — self-interested but real: corpus knowledge ("what does this material contain": scoped to a corpus, accumulated from ingestion) versus user/experience memory ("what did this person decide, prefer, try": scoped to an identity, accumulated from interaction, obligated to handle per-user contradiction, staleness, provenance, and deletion). A wiki does the first and not the second: "Your Gmail wiki tells the agent what is in your Gmail. It does not tell the agent that you changed a decision in a conversation on Tuesday. It does not tell the agent that a method already failed for you." The kicker: "The mistake is not choosing a wiki. It is believing you solved memory because you compiled a corpus."

Attribute the boundary's placement to its author — mem0 sells the memory layer, so the line is drawn exactly where its product begins — but the vault's own stack already embodies the split: this wiki is corpus knowledge, the harness's auto-captured memory directory (Agent Context Files's system-captured memory channel) is the interaction-scoped store, and When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time adjudicates when they disagree.

Company Brains: the pattern at organizational scale (Garry Tan's GBrain)#

The most prominent in-the-wild sibling of this architecture (July 2026, practitioner-opinion): Garry Tan's company brain — his MIT-licensed open-source GBrain, "effectively Postgres for agents." His formulation is "the library plus the librarian": the organization's full record (email, meetings, decisions and their reasoning, postmortems) is the library, and the load-bearing component is the librarian — the retrieval layer that decides, per task, which "three books" go into the agent's context (his working-memory image: an agent holds ~1M tokens ≈ three Harry Potter books, against the human 7±2; "the question that determines whether your agents are geniuses or goldfishes is who decides which three books are open on that desk"). His personal instance: ~220,000 pages, compiled mostly by his agents from 20 years of email, meetings, and notes.

Tan pre-empts the "this is just RAG" objection exactly as this page does — "retrieval is the primitive, the same way Postgres is just B-trees… Retrieval is easy. Being worth retrieving from is the product." What's worth keeping from his account is the hygiene doctrine, an independent convergence on this vault's own design:

Tan's failure mode / prescription	This vault's mechanism
"Provenance on every fact"	evidence: tiers + per-source citation (Non-Malleable Memory Authority (TMA-NM) proves content-trust without origin-binding is unsound in the adversarial case)
"Contradiction checks when new information collides with the old"	the flag-contradictions-explicitly compile rule
"A librarian, human plus agent, whose actual job is pruning"	the lint pass
"A brain nobody curates becomes a garbage dump with great search"	why compile/lint exist at all — retrieval over an uncurated store surfaces stale facts "with total confidence"

His summary — "treat the brain like production infrastructure and it compounds; treat it like a dumping ground and you get a very confident agent that is wrong in ways nobody can trace" — is the operational version of this page's "explorations always compound," with the failure branch made explicit. His economic framing is also worth recording: "model quality is rented, but if you build your brain, you own that brain" (Compounding Data Moat at the level of a knowledge store).

The first external empirical corroboration (Caltech, July 2026)#

Until now this page's thesis rested on Karpathy's design document, one practitioner talk, and this vault's own practice — self-referential evidence at best. Knowledge-Centric Self-Improvement (Wang et al., Caltech, arXiv 2607.19592, empirical) is the first controlled measurement of the underlying bet: that a curated, compiled knowledge artifact is worth more than the system that produced it.

The setup is not a wiki — the agents are benchmark solvers and the store is machine-read — but the architectural boundary is identical. Raw experience is immutable and never edited; a compile step turns it into scoped, evidence-grounded claims; the compiled artifact is the only thing that persists. The measured result: a knowledge bundle frozen at generation 10, separated from the tasks and the model family that produced it, lifts zero-shot solve rates on held-out tasks in all eight donor-recipient cells (Polyglot 8.3%→20.0%, ARC-AGI-1 23.3%→43.3% for the strongest pairing) — and generic agents reading it beat DGM, HyperAgents, GEPA and OpenEvolve on five benchmarks at lower dollar cost. "Explorations always compound" now has a number attached to it, produced by people who had never heard of this vault.

What is worth keeping is a second independent convergence on the same hygiene doctrine — this time from a group optimizing for machine consumption, which makes the agreement harder to explain away as shared taste:

Their protocol rule	This vault's mechanism
Distillation is "a selection step, not a generic summarization step" — keep claims that are actionable and scoped, drop advice that does not name its condition	the compile rule against filler; the granularity rubric
Every Insight carries applies_when / does_not_apply_when	scope conditions in article prose; the supersede-don't-overwrite rule
Claims must cite prior posts by id and quote ≥ 40 verbatim characters of grounding	per-source citation and the evidence: tier
anti_meta_self_check — a schema field that drops posts whose primitive cannot be defended as non-generic	the thin-article check; "dense, precise, no filler"
A retrieval gate rejects a post unless the agent has already read the store for that task	read the index first
Conflicting claims are preserved as FALSIFIED / UNTRIED with both sides' evidence rather than averaged to consensus	flag contradictions explicitly; When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time
Per-task and cross-task bundle inputs kept disjoint so local curation is not polluted by global speculation	concept pages vs derived query outputs

Their formulation of why the last row matters is the sharpest statement of it the corpus has: "when the evidence is genuinely conflicting, the protocol's job is to keep the conflict legible to future agents, not to average it away."

One finding cuts against a natural instinct here. Their knowledge-transfer adapter bounds every field at 0-3 items and is instructed to return short or empty lists when the prior is only weakly relevant — added after they observed that transferring a fixed quantity made recipient memory "overly noisy or detrimental." More compiled knowledge is not monotonically better; what is delivered has to be selected against the task at hand.

Spec-as-Compilation Source (Symphony's Cross-Language Fuzz)#

The most concrete extension of LLM-as-compiler in the wild so far: OpenAI's Symphony team treated their SPEC.md as the source and asked Codex to implement it in Elixir, TypeScript, Go, Rust, Java, and Python. They then used divergences across the implementations to identify ambiguities in the spec and simplify it.

What this technique does that's genuinely new:

• The LLM is the compiler (markdown → working orchestrator in N target languages).
• Multiple implementations are a spec-fuzzing signal — anywhere implementations diverge, the spec is under-constrained. This is analogous to differential fuzzing in compiler verification, but with English/markdown as the source language.
• The spec is the durable artifact, not the compiled output. OpenAI explicitly said they don't plan to maintain Symphony as a standalone product — it's a reference implementation that users point their own coding agent at.

Implications for this vault:

• _system/compiler-prompt.md is structurally analogous to Symphony's SPEC.md — both define how an agent should turn one kind of artifact (raw docs / Linear tickets) into another (wiki articles / running orchestrators).
• Spec-fuzzing-via-multi-language is overkill for a knowledge base, but the idea generalizes: if compiler-prompt.md produces meaningfully different wikis when run by different model families (Claude vs. GPT vs. local), the divergences point to under-specification.
• The schema layer (Karpathy's term) is the same artifact category as SPEC.md/WORKFLOW.md — repo-versioned markdown that defines agent behavior. See cross-link to Claude Code Best Practices (CLAUDE.md), Hermes Agent (AGENTS.md/SOUL.md), Symphony (WORKFLOW.md).

The retrieval counter-case, and where it actually bites (Doulcet, May 2026)#

This page's founding move is "replace RAG with compilation." The strongest opposing view now in the corpus is Document Parsing as the Retrieval Bottleneck — a 116-slide LlamaIndex workshop (practitioner-opinion, direct vendor COI) whose thesis is that retrieval not only survived the long-context era but won it. Its argument is worth stating precisely, because only one of its three legs is about token budgets:

1. Cost — 1M tokens per query at frontier rates; caching helps, the arithmetic still fails for any nontrivial corpus. (Dissolves if inference gets cheap enough.)
2. Governance — stuffing the corpus means stuffing documents the requester should not be allowed to see. "'Model promised to ignore' is not a boundary."
3. Auditability — "'Why did the AI say this?' Retrieval gives a citation log. Long context gives a vibe."

Legs 2 and 3 are not about capacity at all, and leg 3 is the one that lands here. A compiled wiki answers from the wiki, not from the page. This vault's articles cite ... documents, but an individual sentence in an article does not resolve to a page and a region in the source — which is exactly the property the deck spends its parsing section building (bbox grounding, per-field page citations, "cite back to pixels"). The compile step converts a citable corpus into a readable one and pays for it in traceability.

Where the two architectures agree, and it is the load-bearing agreement. The survey's compile-time-loss limit above — "an early summary can remove a detail from the source; each later answer has this error" — is the deck's structure loss moved one layer later. The deck's version of the sentence is blunter: "none of it recovers a document that was parsed badly in the first place." Both architectures are lossy compressions of an immutable source, both put the loss at a step nobody re-examines, and both are defended by keeping the raw layer immutable so the step can be redone.

But only one of them actually redoes it. The deck's rule is "parsing is a stage, not a step — you will reparse, you will re-extract with new schemas, you will rerun retroactively when the parser improves; build for that, store every intermediate, make parsing idempotent." A retrieval pipeline pays the ingest tax per query and can re-pay it better later; a compiled wiki pays it once and keeps the result. This vault has the precondition (immutable raw/, recorded parse warnings, docling: blocks naming the parser configuration) and not the practice: no compiled article is regenerated when a source's parse is later found to be damaged, and _system/backfill/known-bad.md exists precisely because that backlog has nowhere to go. The reparse-and-recompile path is the concrete thing this page owes the counter-case.

The synthesis is supplied, unintentionally, by the deck's own extract vs parse slide: use schema-first extraction when you know what you want, the fields recur across documents, and downstream is structured — use parse + retrieval when you don't know what you want and the question shapes have a long tail. That is the compile/retrieve boundary in the deck's own vocabulary. A personal wiki over ~100 curated sources read by one person is the first case; an arbitrary-Q&A surface over an enterprise corpus with per-tenant permissions is the second. "Most real systems use both" is the deck's answer, and it does not contradict this page so much as bound it.

Evidence weighting: the counter-case is a vendor talk without measurement, against this page's design document plus one controlled study (Knowledge-Centric Self-Improvement) plus this vault's own practice. It is not authority to demote the compile thesis. What it does supply is a well-specified requirement the compile thesis has not met — citation granularity and reparse currency — and those are checkable regardless of who raised them.

Connections#

• Document Parsing as the Retrieval Bottleneck — the architectural rival, treated above. Retrieval as audit trail rather than capacity workaround; the shared irreducible risk (structure lost at ingest is unrecoverable downstream, whether the consumer is a retriever or a compiler); and the two requirements it raises that this architecture does not currently meet — sentence-level citation granularity, and recompiling when a source's parse is found damaged
• Code as Source of Truth — checking specs/skills into the repo is the compiler-wiki pattern applied to code
• This concept is the foundational architecture of this Obsidian vault (see _system/compiler-prompt.md)
• Agent Harness Engineering — shares the pattern of repository-local knowledge as system of record; OpenAI's AGENTS.md-as-table-of-contents mirrors this wiki's schema layer
• Claude Code Best Practices — CLAUDE.md files serve as the schema layer in Claude Code's implementation of this pattern
• LLM-Driven Vulnerability Research — the vulnerability research scaffold uses SHA-3 cryptographic commitments as a form of verifiable knowledge compilation; Claude Code's agentic capabilities power the discovery pipeline
• Client-Side Agent Optimization — the wiki's compile / query / lint phases are themselves an agent pipeline; different phases could be assigned to different models (cheap model for index drift checks, strong model for cross-reference synthesis) and the combo optimized
• Symphony — the most concrete extension of LLM-as-compiler beyond knowledge bases: OpenAI compiled SPEC.md into 6 language implementations and used the divergences as a spec-fuzzer to remove ambiguity
• Ticket-Driven Agent Orchestration — Symphony's WORKFLOW.md is structurally the same artifact category as the schema layer here; both are repo-versioned markdown that the LLM "compiles" into action
• Agent Context Files — the spec-as-document pattern is LLM-as-compiler applied to a context file; Symphony's compile-SPEC.md-into-6-languages spec-fuzzing is the clearest instance
• Design Concept Grilling — Brooks's "design concept" (shared understanding before any artifact) is the alignment-layer analog: a wiki captures what is true, a grilling session captures what we agree on, both treat the LLM as a partner in compilation rather than a generator of one-shot output
• Andrej Karpathy — originated this pattern (the llm-wiki gist) and, in his May 2026 interview, re-endorses it as his daily practice — building a wiki from articles he reads and querying it
• Software 3.0 — Karpathy's canonical example of a "new information-processing task that wasn't a program before": recompiling documents into a wiki is impossible in Software 1.0/2.0
• Outsource Your Thinking, Not Your Understanding — why this pattern works for Karpathy: "anytime I see a different projection onto information, I gain insight" — the wiki is a tool for building understanding, not just retrieval
• Memory and Context Poisoning — the adversarial threat surface this pattern inherits: any system that lets an agent write to durable memory needs the integrity-validation and source-attribution controls that keep a compiled store trustworthy
• LLM-Assisted Grey-Literature Theory Building — the same architectural boundary run for research synthesis: an LLM compiles thousands of raw documents into a structured, quote-grounded artifact (a causal theory), but the interpretive step stays with the human — automating the codes→theory synthesis produced 15,029 shallow, redundant statements, the negative-result echo of "the LLM does the bookkeeping, not the judgment"
• Garry Tan — GBrain as the organizational-scale sibling (library + librarian, memory-plus-hygiene); an independent convergence on this vault's provenance/contradiction/pruning design
• AI-Native Organization — the company brain is the memory layer of Tan's AI-native org; the org's skills route work, the brain supplies what the org already knows
• Non-Malleable Memory Authority (TMA-NM) — the adversarial-case proof behind "provenance on every fact": authority derived from memory content or lineage is launderable; origin must be bound at write time
• Compounding Data Moat — "model quality is rented, but you own your brain": the curated knowledge store as the durable asset over model access
• Latent vs. Deterministic Space — this vault as the worked example: deterministic generators/linters (build.py/lint.py) around a latent compiler
• Layerwise Omission Attribution — this vault located inside someone else's taxonomy. "OCR table-structure loss" is the first mechanism listed under its L0 ingestion layer, and it is exactly the docling table-collapse/shift failure documented in _system/compiler-prompt.md; the ingest-time table-collapse and table-shift checks are L0 checkpoint taps in everything but name. The technique the vault does not have is the canary — a known token planted in the source and exact-matched after parsing, which converts "are these tables suspect?" from a heuristic net into a countable per-document loss rate. Its L2 layer (string slicing, metadata stripping, condensation) is the compile step itself
• Knowledge-Centric Self-Improvement — the first external, controlled measurement of this page's central bet: a curated knowledge artifact outperforms the systems that produced it, and keeps working after the tasks and the model family are gone
• Owning Your Externalized Cognition — the ownership argument for running this architecture personally rather than renting it, plus the hygiene doctrine that matches this vault's: "a brain nobody curates is a garbage dump with great search," so the primitive is memory plus provenance, contradiction checks, and pruning. Its "retrieval is easy, being worth retrieving from is the product" is the compile-vs-pile boundary in one line
• Repository Exploration Subagent — the query-time counterpart to DeepWiki's compile-at-ingest: FastContext grounds a solver by searching per task in a disposable explorer window, DeepWiki by precomputing a per-repo wiki all agents share; same decoupling, opposite ends of the ingest/query cost trade

Open Questions#

• At what scale does the no-vector-database approach break down? Karpathy's ~100 articles fit in context, but what about 1,000+?
• What's the optimal granularity for concept articles — one concept per article, or clustered by theme? Partially answered (2026-08-03): Knowledge-Centric Self-Improvement answers a machine-read version of this and its answer is neither — granularity is carried by scope conditions attached to each claim (applies_when / does_not_apply_when) rather than by article size, with two levels of store (per-task and cross-task) whose inputs are kept disjoint. It also supplies a measured caution: transferring a fixed quantity of knowledge made recipient memory "noisy or detrimental," so their adapter bounds delivery at 0-3 items per field and returns empty lists when the prior is weakly relevant. Suggestive, not settling — bundles consumed by a solver agent are not articles read by a human.
• How effective is the synthetic training data → fine-tuning pipeline in practice?

Resolved Questions#

• How to handle conflicting information across sources during compilation? Answered: When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time — a five-step protocol extracted from this vault's own practice and worked cases: (1) align constructs before declaring conflict (most contradictions dissolve into metric/population/time-axis/unit non-comparability — the Faros-vs-CMU worked example); (2) attach provenance and evidence tier, weigh by method and incentive, never average; (3) stage genuine conflicts explicitly on every affected page, bidirectionally — silent choice is the compile-time form of laundering; (4) convert staged conflicts into tracked open questions with named resolution conditions; (5) resolve at compile/lint time (Tan's librarian), so queries inherit the staged conflict with weights visible rather than re-adjudicating per query.

Derived#

• What Are AI Tools? — query exploring what AI tools are covered in this wiki
• When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time — the compile-time contradiction protocol, grounded in this page's hygiene doctrine and the vault's staged-conflict history
• Authority and Audit Survive Abundance — why the retrieval counter-case's governance and audit legs survive free context, and why they bind this architecture too: compilation and retrieval are both selection-with-a-record, corpus-stuffing is the only option the audit leg eliminates, and the citation-granularity debt this page already concedes is that requirement arriving here

Sources#

• LLM Knowledge Bases
• llm-wiki
• The New Physics of Business — Garry Tan, Y Combinator — Garry Tan, AI Engineer talk (2026-07-17, practitioner-opinion): the company-brain section (GBrain, library + librarian, memory plus hygiene)
• Knowledge-Centric Self-Improvement — Wang, Yoon, Qu, Wang, Sehgal, Mazumdar & Yue (Caltech, arXiv 2607.19592, 2026-07-21, empirical): the held-out transfer result (§4.4, Table 4) and the curation-protocol rules that converge on this page's hygiene doctrine (§3, Appendix E). Full treatment and parse notes on Knowledge-Centric Self-Improvement
• Beyond RAG: Building Agentic Document Workflows with LlamaIndex — Pierre-Loic Doulcet, AI Engineer Singapore 2026 (practitioner-opinion, LlamaIndex vendor COI): the three-legged case for retrieval surviving long context, and the "parsing is a stage, not a step" rule this page's compile phase does not follow. Full treatment and parse warnings on Document Parsing as the Retrieval Bottleneck — the raw file deliberately contains corrupted parser output as demo material and no number may be taken from it
• The State of Agent Wikis — mem0, In Context #17 (2026-07-21, practitioner-opinion; memory-vendor COI on the wiki≠memory boundary): the agent-wiki landscape, the maintenance-currency axis, the four limits. Technique-matrix and wiki-vs-memory figures viewed; the matrix carries per-system corpus/currency/audience data absent from the prose