The LLM-wiki, formalised
The pattern spread as folklore before it had a specification. Now that it has one, it is worth asking what formalising a folk practice actually buys you, and what it costs.
Some time in the last couple of years, a particular folder started appearing in repositories. It had different names in different places. docs/context. .ai/. knowledge/. notes/. Inside it were markdown files, usually written in a slightly unusual register: not quite documentation, not quite comments, more like somebody explaining the system patiently to a competent stranger who has no history with it.
Nobody mandated these folders. They were not part of anyone’s methodology. They appeared because engineers working with language models noticed the same thing independently: the model was much better when it had been told the things everyone on the team already knew, and the cheapest place to put those things was a markdown file next to the code.
Andrej Karpathy gave the pattern a name and a shape, and the phrase LLM-wiki stuck: a living library of markdown files that language models can read, update, cross-reference and maintain over time. That framing was doing a lot of work. It said this is not documentation for humans that models happen to read. It is a knowledge base whose primary reader is a model, and whose maintenance can be partly performed by that model.
Version 0.1 of the Open Knowledge Format, published by Google Cloud on 12 June 2026, formalises that pattern. One concept per file. The file path is the concept’s identity. Front matter with a required type. Markdown links between concepts. Plain directories, no vendor.
Which raises the question worth an entire article: what does formalising a folk practice actually add? Folk practices usually work precisely because nobody standardised them.
What the folk version got right
Start by giving the informal version its due, because it earned its spread.
It required no tooling. You made a folder and wrote files. There was no adoption cost, no procurement, no integration, no migration. The barrier between noticing the problem and doing something about it was approximately zero, which is why it spread through practice rather than through anyone’s platform roadmap.
It used the substrate the model was already fluent in. Language models are extraordinarily good at markdown. It is close to their native register: headings, lists, links, prose. Feeding a model a markdown file is not translation, it is just reading. Every structured alternative (a knowledge graph in a triple store, an ontology in OWL, a catalogue behind a REST API) required a conversion step, and each conversion step was a place for meaning to leak.
It lived in version control. This one is underrated. Putting the knowledge next to the code meant it got branches, diffs, reviews, blame, history and rollback for free. A change to the definition of churn became a pull request that somebody could argue with. That is a governance property that most dedicated knowledge platforms, with their in-place editing and their revision histories nobody reads, do not really have.
And it was honest about the reader. Documentation written for humans is full of things a model does not need and missing things a model does: it assumes shared context, it gestures at the obvious, it says “as discussed in the last section” rather than linking. Writing explicitly for a machine reader forced a plainness that turned out to help human readers too.
Documentation written for people
- Assumes shared background
- Narrative order, one path through
- Cross-references by prose ("see above")
- Optimised for a first read
- Goes stale invisibly
Knowledge written for a machine reader
- States the obvious explicitly
- Random access, one concept per file
- Cross-references as real links
- Optimised for the thousandth read
- Goes stale in a diff you can see
What the folk version got wrong
The problem with a folk practice is that everyone implements it slightly differently, and the differences turn out to matter more than they look.
Granularity was arbitrary. Some teams wrote one enormous file with forty headings. Others wrote three hundred files of two sentences each. Both fail, in opposite directions: the giant file means every question loads everything, so relevance collapses; the shredded files mean no single document holds a complete idea, so the model reassembles the concept from fragments and gets it subtly wrong. Nobody had a rule.
Identity was unstable. A concept lived at docs/notes/billing.md until somebody reorganised the folder, and then every reference to it broke, and nobody noticed because markdown links do not fail loudly. Without a convention that says the path is the identity, paths get treated as filing convenience, and filing convenience changes constantly.
Relationships were prose, not structure. “This depends on the ingestion pipeline” is a sentence. It is not a link. A human reads that and knows where to look next. A model reads it and has to guess whether the ingestion pipeline is a file, a service, a team or a metaphor. The folk version was full of implied relationships that no traversal could follow.
There was no way to say what a document is. A runbook and a metric definition and a policy are different kinds of thing, and an agent should treat them differently. A runbook is a procedure to follow. A metric definition is an authority to obey. A decision record is history, potentially superseded. Without a type, everything is undifferentiated prose and the model has to infer the genre from tone.
That last point is why a spec requiring exactly one field chose type as the field. It is the single most useful thing you can know about a document before reading it.
Folk: one giant context file
Everything loads for every question. Relevance collapses, the model averages across unrelated material, and edits collide.
Folk: hundreds of fragments
No document holds a whole idea. The model reassembles concepts from pieces and gets the joins subtly wrong.
Folk: prose relationships
"Depends on the ingestion pipeline" is a sentence, not an edge. Nothing can traverse it, nothing can validate it.
Formalised: one concept, path identity, real links, typed
A unit of meaning with a stable address, navigable edges, and a declared genre the reader can act on.
Formalisation as a coordination device
There is a general thing worth saying about specifications, and it applies here.
Most specs do not make an individual team better at something. A disciplined team that had already settled on one-concept-per-file with stable paths gains almost nothing from being told to do that. What a spec does is let different teams, and different tools, assume the same shape without negotiating it.
That matters in an agentic setting in a specific way. When your agent, your CI job, your editor plugin, your documentation site and your colleague’s completely different agent all read the same directory, the value of them agreeing on what a file means grows faster than linearly. A shared shape is what lets you swap the agent without rewriting the knowledge, and swap the knowledge without rewriting the agent.
That is the actual promise of vendor-neutrality here, and it is worth being precise about it. The promise is not that OKF is better than a proprietary knowledge platform at any given task. It is that nobody can hold the knowledge hostage. There is no licence, no API key, no platform requirement. If a tool that reads your knowledge base disappoints you, you replace the tool, and the knowledge does not move, because it was never inside the tool. It was in a folder.
The test for whether knowledge is really portable is not whether an export button exists. It is whether you would notice, six months later, that the vendor was gone.
Self-maintenance is the load-bearing claim
The part of the LLM-wiki framing that gets least scrutiny is the word “maintain.” A living library that models can read and update.
This is either the most important property of the pattern or the most dangerous one, depending on how it is implemented, and I do not think anybody has fully worked out which.
The optimistic version is genuinely appealing. An agent working on a change notices that the code no longer matches what services/billing.md claims. Instead of silently working around it, it opens a pull request that updates the document alongside the code. Knowledge maintenance stops being an unfunded chore performed by whoever feels guiltiest and becomes a side effect of doing the work.
The pessimistic version is that you have just built a machine that writes plausible things into your source of truth at speed, and reviewing knowledge-base diffs is even less rewarding than reviewing code diffs, so approvals become rubber stamps, and eighteen months later your definitive internal reference is a large corpus of confident text that nobody wrote and nobody checked.
The difference between those two futures is entirely a question of whether the updates are gated. Which is the same argument this whole publication keeps making about status, about acceptance criteria, about merges: automation is fine, and automation without a verifiable gate and a reversible trail is not automation, it is abdication. GroundTruth exists because we think that argument applies to the record of work. It applies at least as strongly to the record of meaning.
Where this breaks down
The spec is v0.1 and formalisation can arrive too early. Standardising a practice before the practice has finished evolving freezes accidents into rules. The single required field is a good sign that the authors know this, but it also means the spec currently formalises very little, and much of what teams argue about (granularity, typing vocabulary, how to express relationships beyond a link, what to do about conflicts) is left open. Treat it as a well-argued convention, not as an answer.
Formalising folk practice can kill the thing that made it spread. The reason the LLM-wiki caught on is that it cost nothing to start. Every rule added raises that cost. There is a version of the next two years where the format accumulates required fields, validators, linters and a conformance badge, and the practice quietly reverts to people keeping a scratch file, because the scratch file is allowed to be imperfect. Whatever tooling grows around this should be permissive by default.
Self-maintaining knowledge is unproven and the failure mode is severe. I have written the optimistic and pessimistic versions above as though they are equally likely. Honestly, without a gate, the pessimistic version is the default, because reviewing prose for factual drift is harder and less rewarding than reviewing code for bugs, and humans reliably under-invest in unrewarding review.
A stale wiki beats no wiki only while it is true. After that it inverts, and it inverts hard, because a document confers authority. An agent citing an internal knowledge file is more persuasive to a reviewer than an agent reasoning from nothing, regardless of whether the file is right. You have made wrongness more convincing. That is a real cost and it should be weighed before the first file is written.
The takeaway
The LLM-wiki worked as folklore because it was free to start, native to the model, and lived in version control. It failed as folklore because granularity, identity, relationships and document type were all left to taste, and taste varies.
Version 0.1 of the Open Knowledge Format answers those four questions and almost nothing else, which is roughly the right amount of specification for a practice this young. What it buys you is coordination: many tools, many agents and many people assuming the same shape without negotiating it each time.
The next piece takes the first of those four answers seriously and asks what it actually means to put one concept in one file, why the filesystem turns out to be a decent schema, and how to tell when you have cut a concept in the wrong place.