Instead of making the LLM rediscover knowledge from raw documents on every query — the RAG way — Karpathy proposes having the LLM compile a structured, interlinked wiki once at ingest time. Knowledge accumulates. The LLM maintains the wiki, not the human.
-↓ Tap any row to expand analysis
| Dimension | -LLM Wiki | +memex / LLM Wiki | RAG |
|---|---|---|---|
| Knowledge Accumulation | ✦ Compounds with each ingest | Stateless — restarts every query | |
| Maintenance Cost | ✦ LLM does the filing | Chunking pipelines need upkeep | |
| Scale Ceiling | ~50–100K tokens hard limit | ✦ Millions of documents, no ceiling | |
| Human Readability | ✦ Plain markdown, fully auditable | Black-box vector space | |
| Semantic Retrieval | Explicit links only | ✦ Fuzzy semantic matching | |
| Error Persistence | Errors compound into future pages | Errors are ephemeral per query | |
| Multi-user / RBAC | None — flat file system | ✦ Supported by most platforms | |
| Query Latency | ✦ Fast at personal scale | Embedding search overhead | |
| Setup Complexity | ✦ Just folders & markdown | Vector DB, chunking, embeddings | |
| Vendor Lock-in | ✦ Zero — any model, any editor | Often tied to embedding provider | |
| Cross-reference Quality | ✦ Rich, named wikilinks | Implicit via similarity score | |
| Fine-tuning Pathway | ✦ Wiki becomes training data | Raw chunks are poor training data | |
| Knowledge Accumulation | +✦ Compounds with each ingest | +Stateless — restarts every query | +|
| Maintenance Cost | +✦ LLM does the filing | +Chunking pipelines need upkeep | +|
| Scale Ceiling | +~50–100K tokens hard limit | +✦ Millions of documents, no ceiling | +|
| Human Readability | +✦ Plain markdown, fully auditable | +Black-box vector space | +|
| Semantic Retrieval | +Explicit links only | +✦ Fuzzy semantic matching | +|
| Error Persistence | +Errors compound into future pages | +Errors are ephemeral per query | +|
| Multi-user / RBAC | +None — flat file system | +✦ Supported by most platforms | +|
| Query Latency | +✦ Fast at personal scale | +Embedding search overhead | +|
| Setup Complexity | +✦ Just folders & markdown | +Vector DB, chunking, embeddings | +|
| Vendor Lock-in | +✦ Zero — any model, any editor | +Often tied to embedding provider | +|
| Cross-reference Quality | +✦ Rich, named wikilinks | +Implicit via similarity score | +|
| Fine-tuning Pathway | +✦ Wiki becomes training data | +Raw chunks are poor training data | +
Reading papers, articles, and reports over weeks or months on a single topic. Karpathy's primary use case — his ML research wiki has ~100 articles and 400K words, all compiled without writing a line manually.
+Reading papers, articles, and reports over weeks or months on a single topic. Karpathy's primary use case — his ML research wiki has ~100 articles and 400K words, all compiled without writing a line manually.
Goals, health tracking, journal entries, podcast notes — building a structured picture of yourself over time. The LLM creates concept pages for recurring themes and connects them across months or years.
+Goals, health tracking, journal entries, podcast notes — building a structured picture of yourself over time. The LLM creates concept pages for recurring themes and connects them across months or years.
Offloading the maintenance bottleneck — the work that kills all human-maintained wikis — to an LLM is elegant and correct. The pattern solves a real problem people actually have.
+Offloading the maintenance bottleneck — the work that kills all human-maintained wikis — to an LLM is elegant and correct. The pattern solves a real problem people actually have.
+The flat-file architecture has no access control by default. The cleanest mitigation is to expose the wiki through an MCP server rather than as raw files. The open-source llmwiki project (lucasastorian/llmwiki) does exactly this: it wraps the Karpathy pattern with a FastAPI backend, Supabase auth, and MCP endpoints. Claude connects via MCP and has read/write tools — but only through the authenticated layer.
+For self-hosted setups: build a minimal FastAPI wrapper that authenticates via JWT before allowing MCP tool calls. The markdown files stay on disk; the API layer enforces who can read and write. This pattern is already used in production implementations like Hjarni.
+For small teams, a simpler pattern than full RBAC: separate wiki/shared/ from wiki/private/ directories, with git branch-level access control. The MCP server only exposes the shared/ tree to team members; personal pages stay in private/ on a branch only you merge from.
The LLM Wiki v2 pattern calls this "mesh sync with shared/private scoping." The schema file defines what can be promoted from private to shared and the conditions for that promotion.
+Make uncertainty explicit. Every factual claim carries metadata: confidence level, last verified date, source count. Confidence decays with time and strengthens with reinforcement from new sources.
-In memex: Implemented with confidence: high|medium|low + last_verified + sources: fields. The hygiene script auto-decays stale pages and flags them for re-verification.
-The LLM Wiki v2 pattern solves persistent errors by making uncertainty explicit. Every factual claim in a wiki page carries metadata: how many sources support it, when it was last confirmed, and a confidence score (e.g., 0.85). Confidence decays with time and strengthens with reinforcement from new sources.
+Implement this in YAML frontmatter on each page:
++ confidence: 0.85 + sources: 2 + last_confirmed: 2026-04-01 +
+The lint pass checks for pages with decayed confidence scores and flags them for re-verification. The LLM can say "I'm fairly sure about X but less sure about Y" — it's no longer a flat collection of equally-weighted claims.
+When new information contradicts an existing claim, the wrong pattern is leaving the old claim with an appended note. The right pattern: the new claim explicitly supersedes the old one, which moves to archive with a link to its replacement.
-In memex: Pages with status: Superseded by ... are auto-archived. The archive retains the full history with archived_date, archived_reason, and original_path fields.
+When new information contradicts an existing wiki claim, the wrong pattern is leaving the old claim with an appended note. The right pattern: the new claim explicitly supersedes the old one. The old version is preserved but marked stale with a timestamp and link to what replaced it — version control for knowledge, not just for files.
+Define supersession in your schema: the LLM's ingest instructions should check for contradictions against existing pages before writing, and when found, issue a formal supersession record rather than a quiet edit.
+Community implementation ELF (Eli's Lab Framework) uses a strict typed-entity system where every page is declared as a type (library, project, person, concept, decision) and every link between pages has a typed relationship (uses, depends-on, contradicts, caused, fixed, supersedes). This prevents the LLM from creating duplicate concept pages under different names.
+A 5-step incremental ingest pass: diff → summarize → extract → write → image. The extract step enforces entity typing before the write step creates any new page — if a typed entity already exists, it merges rather than duplicates.
+Community analysis of 120+ comments on Karpathy's gist converged on one clear finding: most people who try this pattern get the folder structure right and still end up with a wiki that slowly becomes unreliable, redundant, or abandoned. The difference between a wiki that compounds and one that quietly rots comes down to operational discipline — not technical setup. This is why memex's automation layer exists.
+Community analysis of 120+ comments on Karpathy's gist converged on a clear finding: most people who try this pattern get the folder structure right and still end up with a wiki that slowly becomes unreliable, redundant, or abandoned. The difference between a wiki that compounds and one that quietly rots comes down to operational discipline — not technical setup.
The instinct is to have the agent write directly into the wiki. This creates the rot. The principle: your curated/verified vault and the agent's working vault (speculative writes, messy drafts, exploratory connections still being tested) must be physically separate directories. Only the human promotes content from agent-working to vault.
+Structure: wiki/verified/ (human-promoted, high trust) vs wiki/staging/ (agent writes here first). The lint pass reviews staging and proposes promotions. You approve them. The signal-to-noise ratio in your verified wiki stays high permanently.
+The number one reason wikis rot: the human stops ingesting because life gets busy. The fix is removing the human from the trigger loop. Set up a cron job or a filesystem watcher on raw/ that automatically triggers the ingest command whenever a new file lands. The human's job shrinks to: drop file, walk away.
+Implementations: inotifywait on Linux, fswatch on macOS, or a Node.js chokidar watcher. On drop, the watcher calls your ingest script which runs the LLM compilation pass. You get a notification when it completes.
+Lint passes don't happen if you have to remember to run them. The solution is automating them on a schedule — a weekly cron job that runs the lint command, writes a report to a lint-reports/ directory, and sends you a summary notification. The report tells you: N orphan pages found, N contradictions flagged, N pages with decayed confidence.
+You review the report (5 minutes), decide which flagged items to address, and optionally run the LLM to resolve them. The system is telling you what needs attention rather than you having to inspect everything.
+A community-evolved enhancement to Karpathy's original: add an identity-aware filter to your schema. A prompt section that tells the LLM exactly who the wiki is for, what their goals are, and what "high-signal" means in that context. The LLM then scores sources before ingesting and rewrites that filter over time based on what has proven useful.
+This prevents the wiki from becoming a neutral encyclopedia of everything you've read. It stays opinionated, relevant, and tuned to your actual work. Over months, the schema itself becomes a reflection of what you find worth knowing — a second-order artifact of the system.
+Not everything should live forever. A wiki that never forgets becomes noisy — important signals buried under outdated context. Implement a retention curve: facts that were important once but haven't been accessed or reinforced in months gradually fade to "archived" status. The lint pass executes this curve automatically.
+Frontmatter fields to add: last_accessed, access_count, status: active|fading|archived. The lint pass updates status based on time-since-access and reinforcement count. Archived pages aren't deleted — they move to wiki/archive/ where they're out of the active index but still traceable.
+Standard Karpathy wiki is fed by sources you manually drop into raw/. Your setup replaces that bottleneck with an automated conversation pipeline: every AI session gets mined into MemPalace, summarized, and fed into raw/ on a continuous basis. The wiki stops being a project you maintain and becomes an organism that grows from your daily work. Combined with qmd replacing ChromaDB for indexing, you have a genuinely novel hybrid that addresses the core limitations differently than any single pattern alone.
+Note: You are skipping MemPalace's ChromaDB storage layer and using qmd for indexing instead. The implications of that choice are documented throughout this tab.
+Conversation mining + auto-save hooks make the feed automatic. You no longer have to remember to drop files into raw/. Every Claude Code session is mined. The PreCompact hook fires before context compression. The Stop hook fires every 15 messages.
+Drawers preserve verbatim originals permanently. When a wiki claim is flagged as low-confidence, you have an exact traceable source to verify against — not just "raw/source-2026-04.md" but a wing-scoped, room-tagged original with a drawer ID.
+MemPalace's wing+room metadata filtering means qmd doesn't have to search the entire corpus — it searches a pre-narrowed wing/room scope first. This extends the effective scale ceiling because retrieval is structurally guided before the BM25+vector pass fires.
+Conversations are the primary source — they're inherently current. Every session you have becomes a potential ingest. Staleness now depends on how actively you use AI tools (which you do constantly), not on whether you remember to read and clip articles.
+The combination of MemPalace structural navigation (wing → room → closet → drawer) plus qmd's BM25+vector search covers both explicit structural navigation and fuzzy semantic matching. You have the best of both retrieval patterns without a full vector database.
+Not every conversation deserves to enter the wiki. Debugging rabbit holes, exploratory dead-ends, and casual exchanges are valuable in MemPalace's verbatim drawers but would pollute the wiki if compiled directly. The summarization/filtering step before raw/ is now load-bearing.
+| Dimension | +qmd (your choice) | +ChromaDB (MemPalace default) | +
|---|---|---|
| Storage format | +Markdown files (same as wiki) | +✦ Proprietary vector DB | +
| Semantic recall (LongMemEval) | +Not benchmarked on this task | +✦ 96.6% R@5 raw mode | +
| Wiki integration | +✦ Native — indexes wiki/ directly | +Separate store, no wiki awareness | +
| Single index to maintain | +✦ Yes — one qmd collection | +No — wiki + ChromaDB separate | +
| MCP exposure | +✦ qmd mcp — native tool for Claude | +Via MemPalace MCP server | +
| Hybrid search (BM25 + vector) | +✦ Built in — qmd query | +ChromaDB semantic only | +
| Dependencies | +✦ npm only, local GGUF model | +Python, chromadb, potential version pin issues | +
| Verbatim drawer retrieval | +Not designed for this | +✦ Core feature — drawers are ChromaDB entries | +
| Architectural simplicity | +✦ One search layer for everything | +Two parallel search systems | +
| Limitation | +Before MemPalace | +With MemPalace + qmd | +Residual Work | +
|---|---|---|---|
| Active Upkeep | +Manual — wikis rot | +✦ Auto-hooks feed continuously | +Summarization quality tuning | +
| Error Persistence | +No traceable ground truth | +✦ Drawers = verbatim source | +Confidence scoring in schema | +
| Scale Ceiling | +~50–100K token hard limit | +Extended by wing+room filtering | +qmd still needed at 200+ articles | +
| Semantic Retrieval Gap | +Explicit links only | +✦ Structure + qmd BM25+vector | +Some ChromaDB recall lost (see above) | +
| Knowledge Staleness | +Depends on manual curation | +✦ Continuous from session mining | +Retention curve still needed | +
| Cross-check | +Raw docs only, imprecise | +✦ Drawer-level verbatim traceability | +fact_checker.py not yet wired (v3) | +
| Access Control | +Flat file, none | +Still needs MCP wrapper layer | +Tailscale boundary is your fastest path | +
| Cognitive Outsourcing | +Valid concern | +Unchanged — wiki is still reference only | +Design intent: reference, not replacement | +
In the original pattern, you curated sources manually — only deliberate, quality inputs entered raw/. With conversation mining, the filter is your summarization scripts. If those scripts surface debugging dead-ends, exploratory rabbit holes, or noise, it enters the wiki compilation pipeline. Garbage-in still applies — it's just at a different point in the flow.
+Mitigation: Tune your conversation scripts to filter by memory type (hall_facts and hall_discoveries are high-signal; hall_events is medium; raw session transcripts are low). Only promote closet summaries tagged as decisions, discoveries, or recommendations. Use MemPalace's --extract general mode to auto-classify before staging.
+MemPalace's contradiction detection (fact_checker.py) exists as a standalone utility but is not currently called automatically during knowledge graph operations — the authors acknowledged this in their April 7 correction note. This means cross-wing contradictions won't be auto-flagged at ingest time yet.
+Mitigation: Call fact_checker.py manually as part of your lint pass script until Issue #27 is resolved. Wire it as a pre-commit hook on wiki/ changes: any new page goes through fact_checker before being promoted from staging to verified.
+MemPalace's taxonomy (wings, rooms, halls) and the wiki's taxonomy (domains, concept pages, page types in CLAUDE.md) are separate schemas. If they drift — MemPalace calls something "wing_taskforge/hall_facts/auth" while the wiki calls it "infrastructure/auth-decisions" — the structural navigation loses coherence. Tunnels and wikilinks stop reinforcing each other.
+Mitigation: Define a canonical mapping document (a simple markdown table) that maps MemPalace wing/room names to wiki domain/page paths. Reference it in both CLAUDE.md and your MemPalace wing_config.json. Review quarterly — schemas co-evolve, but they need to co-evolve together.
+