Google's Open Knowledge Format Doesn't Replace Vector Search — It Fixes What Embeddings Were Never Good At

Strip away the framing and the Open Knowledge Format is specific and small. An OKF bundle is a directory of markdown files. Each file that isn't one of two reserved filenames (index.md, log.md) is a concept — one knowledge artifact, one file. A concept can be a database table, a business metric definition, an incident runbook, a deprecated API notice, anything an organization wants an AI agent to know without guessing.

Every concept file needs exactly one thing: a YAML frontmatter block with a non-empty type field. That's the entire mandatory surface of the spec.

Concepts link to each other with plain markdown links, which turns the directory into a graph richer than the parent-child structure the filesystem alone implies — the customer_id join path above is a real, traversable edge, not a comment. Google's own framing of the design goal is direct: "What's missing is a format, not another service." No SDK, no required cloud account, no proprietary API to read or write a bundle — it renders on GitHub, ships as a tarball, and mounts on any filesystem as-is.

Worth being precise about where this stands: Google's own post calls v0.1 "a starting point, not a finished standard," and the spec has already moved to v0.2 within months of the initial release, adding provenance and trust fields the original version didn't have. Treat the conformance details below as current, not fixed — this is a young spec, not a settled one.

The claim making the rounds — that OKF is Google quietly deprecating Retrieval-Augmented Generation (RAG), the technique of retrieving relevant text at query time and feeding it to an LLM as context — doesn't survive contact with Google's own blog post, which never makes that claim. What it actually says is closer to: *stop making agents re-derive facts you already know, from documents, every single time.*

RAG and vector search exist because most organizational knowledge is unstructured, high-volume, and not fully known in advance — support tickets, chat transcripts, freeform wiki pages, PDFs. There is no schema to write a type: field against. Similarity search over embeddings is the correct tool for "find content related to this query" when *related* is a fuzzy, semantic notion, and it will always be probabilistic: the retrieval step ranks chunks by similarity, not by correctness, so a wrong or outdated chunk can outrank the right one.

OKF targets a narrower, different failure mode: knowledge an organization already has, already knows the shape of, and would rather encode once than have an LLM re-guess from a table name or a stale comment. A join path between two tables isn't "semantically similar" to anything — it's either documented or it isn't. Chunking a schema into 512-token windows for embedding is how RAG systems mangle exactly this kind of structured fact in the first place, which is the real, specific failure OKF is a direct answer to.

Put the two failure modes side by side and the actual boundary is clear:

Neither tool is more advanced than the other — they're addressing retrieval problems that don't share a failure mode, which is why "replacing" is the wrong verb.

Most first-look coverage of OKF fixates on the markdown-plus-frontmatter format itself, which is the least interesting part — plenty of internal wiki tooling already does that. The part worth an engineer's attention is buried in the conformance criteria: permissiveness isn't a suggestion, it's a requirement consumers must implement to be spec-compliant.

From the GitHub SPEC.md: consumers MUST tolerate unknown type values, missing optional frontmatter fields, unknown additional frontmatter keys, and broken cross-links — the spec is explicit that a link whose target doesn't exist in the bundle "is not malformed." Type values aren't centrally registered either; producers pick descriptive strings, and consumers are required to degrade gracefully on anything they don't recognize.

This is a deliberate, load-bearing design choice, not an oversight. A centrally-registered schema (the kind most internal metadata catalogs eventually grow) requires every consumer to be updated in lockstep with every producer's changes, or reads start failing. OKF's permissive-by-mandate conformance means a team can add a new concept type, restructure a directory, or start linking to files that don't exist yet — mid-migration — without a coordinated release across every system that reads the bundle. That's the same operational property that makes semantic versioning's "additive changes are non-breaking" convention useful at scale, applied to a knowledge graph instead of an API.

Once OKF and RAG are understood as answers to different retrieval problems, the practical design isn't a migration — it's a split, based on the same question for every piece of context an agent needs: is this a known fact, or a fuzzy search?

Known facts → OKF, loaded deterministically. Table schemas, join paths, metric definitions, runbooks, API deprecation notices — anything with an owner who could write it down once and have it stay true until someone updates it. These get read directly by file path or walked via the concept graph, and injected into an agent's context without a similarity search in the loop at all. There's nothing to rank; the agent asked for the orders table's schema and got the orders table's schema.

Fuzzy retrieval → RAG, unchanged. Support tickets, chat transcripts, freeform documentation, anything where "relevant" is inherently a matter of degree rather than an exact match. This is still embeddings, still chunking, still a vector index — OKF doesn't touch this half of the system, because it isn't built to.

The connective layer is the interesting engineering work. An OKF concept file can *point at* the unstructured corpus a RAG pipeline indexes — a runbook's frontmatter resource field linking to the incident channel it was written from, a metric definition linking to the dashboard that computes it — without OKF trying to represent that corpus itself. The graph traversal answers "what do we know," and hands off to vector search for "what does everyone say about it." Building both into the same agent's tool surface — one deterministic lookup tool, one similarity-search tool, and letting the agent (or a router in front of it) pick per query — is the shape of system this actually points toward, not a replacement of one with the other.