Google published a standard for AI knowledge. We were already compliant — by accident.
In 2026, Google introduced the Open Knowledge Format (OKF): an open, vendor-neutral standard for the knowledge AI agents need. We read the spec the week it landed, compared it against our own vault, and found we had been building to it for years without knowing it would exist. Compliance took one script.
What OKF actually is
Strip away the announcement and OKF is refreshingly small: plain markdown files with YAML front-matter, linked to each other, versioned in a git repository. No SDK, no proprietary account, no translation layer between your knowledge and the model reading it. Readable by humans and by every AI model. As Google Cloud put it when introducing v0.1, OKF “formalizes the small set of conventions needed to make these patterns interoperable” — the patterns being the Obsidian-, Notion-, and Hugo-style wikis people have been building for years.
That shape was already our shape. Every decision, runbook, pricing rationale, and hard-won lesson across our six businesses lives as linked markdown with front-matter in git. When the spec appeared, aligning meant normalizing a handful of front-matter keys — one script run over the vault, done. If you built the right thing, standards catch up to you.
Why open formats beat platforms
Every knowledge platform makes the same trade: convenience today, custody never. Your notes live behind an API, in a schema someone else controls, exportable only in whatever shape the vendor permits this quarter.
An open format inverts that. The files are the contract; every tool on each end is swappable. Your editor, your sync, your AI model, your search layer — each can be replaced without touching the knowledge itself. Fire your tools, or fire us, and you keep everything: the entire vault exports with a single git clone, and the format is readable by any LLM or markdown tool directly.
For AI specifically, this matters more than it did for note-taking. Models change fast. The knowledge they should ground on shouldn’t have to migrate every time the model does. Plain files in an open format are the one layer of the stack that can outlive every tool attached to it.
Where it goes next: catalogued, then grounded
The spec describes the files. What we run in production goes two deliberate steps further — and they are different jobs.
First, governance: the vault’s manifest registers into BigQuery, where Knowledge Catalog holds a metadata record for every note — what exists, who owns it, when it changed. That is registration and discovery, nothing more.
Second, grounding: the notes index into a dedicated search data store attached to Gemini Enterprise. That data store — not the catalog — is what the assistant searches, and every answer cites the exact notes it came from. In our own install, 1,038 documents indexed with zero import failures, and 100% of answers are cited.
Keeping those two jobs separate is the honest architecture. It’s also why grounding is opt-in per tier: a dedicated, scoped data store you can remove without touching the vault itself.
For the full argument — how the vault predates the spec and what the standard changes for buyers — read the deep dive on the Emerge hub: Knowledge before OKF.
See the standard in practice
We publish exactly how VaultOS maps to OKF, layer by layer, on our standard page. Or skip ahead and book a free walkthrough — the system you’ll see is the live one, not a demo.
