OKF vs RAG for Data Warehouse Context: Why We Chose a Living Knowledge Base
Google's Open Knowledge Format (OKF) formalizes the "LLM Wiki" pattern: give an agent a curated markdown knowledge base instead of RAG over raw chunks. We've run a variation of that for warehouse context since 2025. Here's why a living knowledge base beats RAG, and where RAG still wins.
If you want an AI agent to answer questions about your data warehouse, you have two ways to give it context. You can embed your warehouse metadata into a vector database and retrieve chunks at query time, which is RAG. Or you can maintain a curated knowledge base the agent reads directly, which is what Google's new Open Knowledge Format (OKF) standardizes. For stable, structured knowledge about how a warehouse actually works, the second approach wins, and it's the one AnomalyArmor has used since late 2025.
That's not a prediction about where the industry is heading. It's a description of a bet we already made and shipped, months before Google gave the pattern a name.
What is the Open Knowledge Format (OKF)?
OKF is a spec that Google Cloud published on June 12, 2026. Sam McVeety and Amir Hormati wrote it, it's Apache 2.0, and it's currently a v0.1 draft. The format itself is deliberately boring: a folder of Markdown files, each with YAML frontmatter and a required type field, where every file represents one "concept" your organization knows about. APIs, metrics, runbooks, system behavior. An agent reads those files directly. No embedding step, no vector search, no re-ranking.
It's a formalization of what Andrej Karpathy called the "LLM Wiki" pattern: instead of pointing an agent at raw documents and asking it to re-derive the same facts on every query, you build a living wiki that the agent (and humans) read and update over time. The wiki gets more useful as it accumulates knowledge. A pile of PDFs behind a vector index does not.
OKF vs RAG: the actual difference
The two aren't competitors so much as answers to different questions. RAG is built for "I know the answer is somewhere in this large corpus, go find it." OKF is built for "here is what we already know, stated plainly, go read it."
| RAG | OKF (and OKF-style KBs) | |
|---|---|---|
| Source shape | Large, changing document corpus | Curated, structured, stable knowledge |
| Access pattern | Embed, retrieve, re-rank at query time | Direct read of the relevant file |
| Latency | Embedding + vector search + re-rank | File read |
| Hallucination surface | Model reconstructs an answer from retrieved chunks | Model reads a fact that's already written down |
| Best at | Unstructured search across many documents | Known facts about how your systems work |
| Failure mode | Retrieves the wrong chunk, or a stale one | KB goes stale if nothing keeps it fresh |
The last row is the whole game. RAG's hard problem is retrieval quality. A knowledge base's hard problem is staleness. Pick the approach whose hard problem you can actually solve for your data.
For a data warehouse, staleness is the solvable one, because we already know the moment a fact changes.
How AnomalyArmor's knowledge base works
AnomalyArmor builds a markdown knowledge base for every monitored table. Not one global wiki, one KB per asset, assembled from nine domain generators that each write a section:
- Schema drift: column changes over the last 90 days, bucketed by time
- Freshness: update patterns, SLA violations, the schedule we've learned for the table
- Lineage: upstream and downstream dependencies, dbt-backed
- Data quality: unified metrics and validity checks
- Alert rules: what's configured, what fired, how it resolved
- Tags, job history, git changes, and an LLM-written summary of business and technical context
Each generator produces plain markdown. Stitched together, that's a readable document describing everything the system knows about one table. When you ask "why is orders stale," the agent reads that KB, not a set of vector-retrieved fragments it has to reassemble.
Here's the part that makes it a "living" knowledge base rather than a stale one. The KB regenerates lazily, and only when it's actually out of date. Every domain's KB carries a timestamp. When the underlying feature data changes (a new schema diff lands, a freshness check fires, lineage shifts), that domain is marked stale. The next time anything reads the KB, the stale domain regenerates from current data and the fresh domains are served as-is. A table whose schema hasn't moved in a month doesn't get its schema section rebuilt on every question. A table that just broke does.
That's the difference between our version and a hand-maintained wiki. Nobody writes these files. The warehouse's own monitoring signals write them, and staleness detection keeps them honest. It's OKF's shape (curated markdown, read directly, growing more useful over time) fed by a monitoring pipeline instead of a human editor.
Why we didn't use RAG for this
We tried the obvious thing first, because everyone does. Dump the schema, the recent changes, the lineage edges, and the alerts into a vector store, retrieve the relevant bits per question, hand them to the model. Three problems showed up fast.
The chunks lie about structure. A foreign key relationship, a lineage edge, a "this column changed type three days ago" fact: these are relationships, and vector retrieval flattens them into text fragments that lose the connections. The model then guesses at structure it should have been handed directly.
Retrieval adds a failure mode you can't see. When the agent gives a wrong answer, you can't tell whether the model reasoned badly or the retriever fetched the wrong chunk. That's two suspects for every bug. Reading a KB directly removes one of them.
We already know when facts change, so retrieval is wasted work. RAG earns its cost when you can't predict what's relevant. But we run the monitoring. We know the instant a schema drifts or a table goes stale. Paying the embed-and-search tax on every query, to rediscover facts we already detected, is effort spent solving a problem we don't have.
None of that means RAG is bad. It means RAG is the wrong tool for structured knowledge you already track.
Where RAG still fits
If your context lives in a big, messy, unpredictable pile (support tickets, Slack history, a decade of Confluence, arbitrary PDFs) RAG is the right call and a KB is the wrong one. You can't curate what you can't predict, and you shouldn't try to hand-shape a corpus that changes faster than you can read it. OKF's own authors are explicit that the two are complementary. OKF handles the known knowns. RAG handles "it's in there somewhere."
Our own system isn't RAG-free either. There's still a projection step that budgets tokens across domains before a call, because even a curated KB can outgrow a context window. The point isn't purity. The point is that the knowledge layer is a living KB, not a vector index, and that choice is why an AnomalyArmor investigation can cite the exact row behind a claim instead of gesturing at a retrieved fragment. That citation layer, EvidenceCapsule, only works because the knowledge underneath it is structured and addressable in the first place.
The takeaway
Before you reach for a vector database to give an AI agent context about your data, ask one question: do you already know when the underlying facts change? If yes, you don't need retrieval, you need a knowledge base that updates itself the moment they do. Google just standardized that pattern as OKF. For data-warehouse context specifically, it's the right shape, and it has been since before it had a name.
OKF vs RAG FAQ
Is OKF a replacement for RAG?
No, and its authors don't claim it is. OKF is for stable, curated, structured knowledge that an agent reads directly. RAG is for searching large, changing, unstructured corpora. Most real systems use both: a knowledge base for what you know, retrieval for what you have to go find.
Does AnomalyArmor implement the OKF spec literally?
No. We built a variation of the same pattern in late 2025, before OKF existed. Our knowledge base is per-asset markdown, generated from monitoring signals and refreshed on staleness, rather than the exact file layout OKF's v0.1 draft specifies. Same idea, different plumbing, and ours predates the spec.
What makes a knowledge base "living" instead of stale?
Something has to detect when a fact changes and rewrite the relevant part. In a human wiki, that's an editor. In AnomalyArmor, it's staleness detection wired to the monitoring pipeline: when a schema diff, freshness event, or lineage change lands, the matching KB section is marked stale and regenerated on next read. Nothing rebuilds until the underlying data actually moves.
Why is direct read better than retrieval for warehouse metadata?
Because warehouse structure is relational, and retrieval flattens relationships into disconnected text chunks. Reading a curated KB hands the model the structure directly. It also removes retrieval as a hidden failure mode, so when an answer is wrong you have one suspect instead of two.
Does this only work with your own data?
The knowledge base is built from the metadata AnomalyArmor already collects from your warehouse and integrations. It needs no extra instrumentation beyond the existing connection.
AnomalyArmor is in private beta. If you want to see a self-updating knowledge base answer questions about your own warehouse, reach out and we'll get you access.
