The knowledge base is the maintenance. Everything else is packaging. Six months ago I wrote about what an LLM wiki looks like after six months of actually running one, and I hedged the claim; since then several teams have independently converged on the same architecture, one open-sourced a ten-thousand-star implementation of it, and the debate has acquired a vocabulary, so this working thesis can afford to be blunt.
The failure mode has a name now. A widely shared reading of Karpathy’s knowledge-base design put the hypothesis plainly: knowledge systems fail not because people collect too little, but because the maintenance burden is unsustainable. You collect, you organise, you update, and eventually you stop, and the wiki quietly rots. I can confirm the mechanism from the other side, because I recently spent one Saturday finding every version of that rot in my own estate. A message queue held forty-two unread messages including a real defect report, because delivery was switched off on both ends. A health file had been frozen at a reassuring “ok” for three days because its writer died at the same line every hour. A status record described five monitoring checks where two remained. None of these were retrieval failures. Every one was a truth failure, a record that had silently stopped describing the world.
The tempting response is machinery, and vendors are happy to sell it: self-maintaining knowledge graphs, memory daemons, semantic layers. I tested that road twice in one day. A memory daemon I had been running turned out never to have extracted a single memory in its life. Its status said running; its work said never. And the most credible minimalist alternative, tried in a sandbox, turned out to be my own system with the curation removed and a summarisation tax added at every session start. Meanwhile the strongest measured result in the current conversation points somewhere more precise than machinery-versus-no-machinery: on GBrain’s own benchmark, a 240-page test corpus, its regex-built link graph was worth thirty-one points of precision over the same system with the graph turned off, and beat plain vector search by a similar margin on relational queries. One benchmark, its own corpus, but the direction is striking. The winning component is the humblest one, a graph built from links a person wrote, and the losing one is the expensive centrepiece, embeddings a model computed. Structure that humans curate beats structure that models infer, on the relational queries that in my own use matter most in a personal base.
There is a fresh wound in the practitioner community that makes the point better than any benchmark. One person reported that their AI-managed knowledge base quietly accumulated four hundred and ninety-seven duplicate files, the snowball effect of agent-generated notes. Agents have made writing free, and free writing makes rot faster, not slower. The scarce resource was never storage or even search; it is reading. A system that writes reliably but is never read, a phrase I found asked verbatim as an open question this month, fails in a way no retrieval upgrade can fix.
What has survived six more months of daily use is a short list of boring disciplines, and they compound in a particular order. Dating every claim comes first, because a date turns silent staleness into visible age. Dates make supersession possible: when something changes, I write the change into the old record at that moment, so the record that people actually find carries its own correction. Records I can trust let me demand the same of instruments, so no new check or automation earns trust until it has caught one real defect. A commissioned instrument still needs a witness, so every scheduled job names its reader, because an unread alarm is not an alarm. And trustworthy instruments with named readers finally make consolidation safe: capture freely, hold each lesson to being the one authoritative note for it, and merge duplicates the moment contact reveals them. At personal scale the count of notes matters very little for retrieval, because search carries thousands of files without strain. It is the whole ballgame for truth, because every kept note is one more claim that can quietly go wrong.
If you are building one of these systems, the test I now apply to every shiny candidate is a single question: does this improve the truth of the base, or only the machinery around it? Machinery can pass that test, when it genuinely lowers the cost of keeping records true, the way a link checker or a duplicate detector does. What fails it is machinery that only makes the base bigger, faster, or more searchable while the records inside drift. Those candidates go to the reference shelf. The knowledge base is Markdown files. The product is that they are true.