Your LLM Wiki Will Invent Facts Unless a Human Owns the Source of Truth

A developer working on AFFiNE argues that self-writing LLM wikis suffer from "meaning drift," where a finding true under specific conditions gets rewritten as a universal claim and then cited by later generated pages, compounding the original error. The proposed fix is a three-layer architecture: a human-owned source of truth the team already edits, a review loop giving synthesized pages owners, review dates and changelogs, and agent synthesis that is read-only by default via scoped credentials such as MCP. AFFiNE positions its open-source, local-first workspace with a BYOK AI layer and read-only MCP server as one option for the source-of-truth layer.

This week, X is again circulating "five GitHub repos to build your AI second brain." Karpathy's LLM Wiki is on every list, next to personal memory projects and Claude-plus-Obsidian hooks. Those repos are useful. They are also incomplete in a way that only shows up after the wiki has been writing itself for a couple of weeks. The failure is not "the model forgot." The failure is meaning drift: a result that was true under specific conditions becomes a general fact, and later pages cite that generalization as if it were settled. On November 8, a builder described the wall clearly: even with citations, meaning drifts. A finding that applied under one setup gets rewritten as a universal claim. The next generated page builds on it. A week later, the wiki is confident, interlinked, and slightly wrong. That is a different problem from the usual goldfish-chat complaint. Persistence is necessary. Persistence without a reviewable source of truth just compounds the first error. The same week, people were also shipping shared, git-backed wikis so one teammate's coding agent does not start from zero. That instinct is right. Shared agent memory without ownership and review just shares the drift faster. An LLM wiki works by synthesizing pages from sources, then treating those pages as context for the next synthesis. That loop is the product. It also creates a citation graph that slowly leaves the evidence: Humans do this too, in meeting notes. Agents do it faster, more politely, and at 2 a.m. A personal vault can tolerate some of this. You still have the original PDF on disk and a memory of what you meant. A team cannot. The person who ran the eval leaves. The next agent only sees the pages. X still frames the choice as Notion versus Obsidian: share in the cloud, or own the files. That is a real trade-off for a personal knowledge base. It is the wrong frame for a team that wants agents in the loop. What you need is a source of truth people already edit, with: That is closer to Knowledge base Software https://affine.pro/ than to a weekend vault hook. If the AI layer can search and cite those pages, you have AI knowledge base Software https://affine.pro/ . If you can run the workspace yourself, you also get the ownership people usually want from an Open source Notion https://affine.pro/ alternative — without pretending a folder of agent-written markdown is a product. Keep synthesis above the source of truth, not in place of it. Layer 1 — Human source of truth. The docs, specs, RFCs, and run logs the team already maintains. Corrections happen here. If you self-host this layer, the documents stay in infrastructure you control, and the model provider stays swappable. AFFiNE's guide to self-hosted AI for teams https://affine.pro/blog/self-hosted-ai treats this as its own layer for a reason: the knowledge workspace is not the model server, and it is not the chat UI. Layer 2 — Review loop. Every important synthesized page gets an owner, a review date, and a changelog. New claims must link to a source document, not only to another wiki page. If the source is a generated page, it is a draft until a human accepts it. Layer 3 — Agent synthesis, read-only by default. This is the LLM wiki: topic pages, briefings, "what we believe about X." Agents read through a scoped credential MCP is the current pattern . They do not get write access on day one. The write-up on an LLM wiki for teams https://affine.pro/blog/llm-wiki is explicit about this: start read-only, test with real questions, and fix the documents — not the prompt — when an answer is wrong. AFFiNE, which I work on, is one option for layer 1: an open-source, local-first workspace with docs, whiteboards, and databases, plus an optional BYOK AI layer and a workspace MCP server that is read-only by default. It is not the only option, and it is a weak fit if you only need a read-mostly handbook or if you need agents to write into the workspace on a stable release today. Pick one topic your agents already answer: pricing, architecture, or an on-call runbook. If step 2 is mostly wiki-to-wiki links, you do not have a retrieval problem. You have a drift problem. A second-brain repo can give one person a writing loop. A team needs a source of truth that outlives the loop. Let the LLM wiki summarize, link, and brief. Do not let it become the only place a fact lives. The moment a generated page is the sole citation for a later generated page, meaning has started to drift — and the wiki will sound more sure of itself every day. If you are evaluating Knowledge base Software https://affine.pro/ you can actually run and review, start at the homepage and read the LLM wiki and self-hosted AI pieces before you wire write access to any agent.