The Substrate Gets a Spec
In April I wrote that the substrate has to change before the intelligence layer can be trusted. I was describing a problem. In June, Google shipped a specification that is trying to solve it.
The Open Knowledge Format — OKF, published June 12 by Google Cloud — is a vendor-neutral standard for representing enterprise knowledge as plain markdown files with YAML frontmatter. No proprietary runtime. No required SDK. A directory of files you can cat, git clone, and open in any editor. The format itself is the contribution.
I want to be careful about what that means and what it doesn't.
What OKF actually is
OKF formalizes the LLM Wiki pattern that Andrej Karpathy sketched in a GitHub gist in April — the same pattern I have been watching emerge in personal knowledge management for years and writing about as the missing model for enterprise KM. The idea is not complicated: instead of pointing a language model at a pile of raw documents and re-deriving answers on every query, you compile the knowledge once. An agent reads new sources, integrates them into a persistent, cross-linked wiki, and the synthesis accumulates. The wiki gets richer. The queries get cheaper. The contradictions get flagged at ingest, not discovered mid-answer.
OKF's contribution is an interoperability contract on top of that pattern. Karpathy's gist is compelling, but every team that implements it builds something slightly different — different frontmatter fields, different reserved filenames, different conventions about what an index is and what a log is. The result is that your wiki and my wiki and a vendor's catalog export all look alike on the surface and cannot cooperate in practice. OKF pins down the small set of rules needed to fix that. One required field. Two reserved filenames. The rest is yours.
Where I saw this coming
"RAG fails twice on a legacy knowledge base. It fails computationally. And it fails semantically."
The Substrate Problem, as I named it, is not a retrieval problem. It is a precondition problem.
RAG fails twice on a legacy knowledge base. It fails computationally because the corpus was never shaped for machine retrieval — the SharePoint sites, the nested wiki pages, the decade-old shared drives all have to be ingested, chunked, embedded, and indexed at cost, with diminishing returns as the corpus grows. And it fails semantically because those artifacts were written for human readers navigating digital paper, not for machines extracting grounded answers. Documents assume context the reader brings. Policies contradict themselves across versions nobody reconciled. Tribal knowledge was never written down to begin with.
A language model inherits whatever it retrieves from. If the substrate is fragmented and machine-hostile, the output will sound better than the input deserves.
OKF is the industry's first formal acknowledgment that this is the right framing. Google's announcement states it plainly: RAG re-derives knowledge at query time from raw chunks. An OKF bundle stores curated, cross-linked concepts that an agent reads and updates directly. That distinction — compiled versus retrieved — is the whole argument.
The part nobody has answered yet
"OKF specifies the format. It does not specify governance."
Here is where I want to be honest about what OKF does not do.
OKF specifies the format. It does not specify governance. It tells you what a concept file looks like and what fields it must carry. It does not tell you who reviews the agent's edits before they become canonical. It does not tell you what happens when two agents write conflicting entries into the same bundle. It does not tell you how permissions travel from the source system to the compiled concept — so that the knowledge surface an employee sees reflects only what they are authorized to see.
These are not edge cases. They are the reason enterprise knowledge management has always been hard. Governance is where the maintenance burden lives. It is where the tribal knowledge stays tribal. It is where the migrations fail.
OKF v0.1 is explicitly a draft. The spec says it will evolve as more producers and consumers emerge and as we collectively learn what knowledge representations agents actually need in practice. That is the right posture. But it means the hard work — the enterprise work — is still ahead.
What this means for the knowledge worker in 2026
"The closest thing to healthy knowledge management running anywhere today is not inside enterprises. It is running on individual workers' laptops."
The closest thing to healthy knowledge management running anywhere today is not inside enterprises. It is running on individual workers' laptops. The PKM tools — Obsidian, Notion, Logseq — already do a compressed version of what the enterprise needs: capture in the flow of work, light structure, AI assistance without ceremony. OKF's design explicitly acknowledges this. The spec notes its intentional proximity to personal knowledge tools that use hierarchical markdown with cross-links, and to LLM wiki repositories that use markdown and frontmatter as agent-readable knowledge bases.
The problem is that these tools stop at the edge of the individual. The bridge to team and enterprise requires governance, permissions, review workflows, and trust infrastructure that personal tools were never designed to carry.
That bridge is not a format problem. OKF solves the format problem well. The bridge is an organizational design problem — and solving it requires rethinking how knowledge is produced, reviewed, owned, and retired inside an enterprise, not just how it is stored.
The substrate still has to change. Now we have a spec for what the healthy substrate looks like. The harder question is who builds it, how, and for whom.