- Three YouTube videos appeared within 96 hours of Google’s Open Knowledge Format announcement. Combined views: nearly 31,000. All three got the core claims wrong.
- The Google Open Knowledge Format is a folder of markdown files with one required field. The full spec fits on a single printed page.
- OKF does not replace RAG. They operate at completely different layers in the same stack.
- Karpathy published the LLM Wiki pattern on April 4, 2026. Google formalized it on June 12. OKF validated Karpathy. It did not replace him.
- If you have an Obsidian vault with YAML frontmatter in a git repository, you were already compliant before the announcement dropped.
- The panic cycle is systemic. Every major platform announcement produces it. Read the source material yourself. It usually fits on one page.
Table of Contents
Google’s Open Knowledge Format dropped on June 12, 2026, and within 48 hours, the hot takes were already wrong. One video pulled over 81,000 views. Another is climbing past 2,600. A third appeared a day later with 16,000 views and counting. I grabbed screenshots of all three thumbnails before writing this. I posted the screenshots above because the thumbnails tell you everything you need to know before you ever hit play. Crumbling logos. A man with broken glasses. “DON’T BUILD” in red text. That is not education. That is panic manufacturing, and it has a business model.
Both channels sometimes put out decent content. These videos are not that.
The claims making the rounds: the Google Open Knowledge Format replaces RAG, it killed the Karpathy wiki, and you need to rebuild your knowledge base from scratch to get compliant. All three are wrong. The actual specification says the opposite of what those thumbnails claim. If you already have an Obsidian vault with YAML frontmatter in a Git repository, you were compliant before the announcement went live. Close the tab.
What the Google Open Knowledge Format Actually Is
Google published Open Knowledge Format v0.1 on June 12, 2026. Sam McVeety and Amir Hormati at Google Cloud wrote it. The spec lives in the GoogleCloudPlatform/knowledge-catalog repository on GitHub, where you can read every word and verify anything in this post yourself.
Here is what the Google Open Knowledge Format actually is. A directory of markdown files with YAML frontmatter. One required field called “type”. Reserved filenames for index.md and log.md. The full specification, including conformance criteria, cross-linking rules, and the complete reserved filename list, fits on a single printed page.
The spec opens with this: “If you can cat a file, you can read OKF. If you can git clone a repo, you can ship it.”
No schema registry. No central authority. No required tooling. OKF is a format, not a platform. It is not tied to any cloud provider, database, model vendor, or agent framework. The spec is explicit that it will never require a proprietary account or SDK to read, write, or serve.
Google shipped reference implementations alongside the announcement. A BigQuery enrichment agent that walks a dataset and drafts a concept document for every table in scope. A static HTML visualizer that turns any OKF bundle into an interactive graph with no backend. Three sample bundles covering GA4 e-commerce, Stack Overflow, and Bitcoin public data. All of it is in the repository.
This is a real standard that solves a real problem. Vendor-neutral interoperability for agent-readable knowledge is worth having. That is exactly why the hot takes that are damaging its reputation deserve a direct response.
Four Builders, One Design Choice
Pattern recognition, not a history lesson. Four builders across sixty years converged on the same architectural decision. None of them invented it from scratch. Each independently discovered why it works, arriving at the same answer from a completely different starting point.
In the 1960s, sociologist Niklas Luhmann built a slip-box with over 90,000 index cards. He separated raw inputs from permanent notes using directional links between them. Connection density between cards created compounding value across the whole collection. His slip-box produced over 70 books and 400 articles. The man built a knowledge engine out of paper and wood, and it outperformed most research teams of his era.
On April 4, 2026, Andrej Karpathy published a GitHub Gist titled “LLM Wiki”. Five thousand stars in 48 hours. That number tells you everything about how hungry the developer community was for this idea. Instead of retrieving raw documents at query time, the LLM builds and maintains a persistent wiki. Knowledge gets compiled once and stays current, rather than being re-derived every time you ask a question. Three layers: raw sources, wiki layer, schema. Three operations: Ingest, Ask, Lint. Luhmann would have recognized the shape immediately.
On April 5, 2026, one day later, Garry Tan open-sourced GBrain under the MIT license. It sits at 24,000 stars and counting. His production deployment manages 146,646 pages across 24,585 people and 5,339 companies. His agent ingests meetings, emails, tweets, and voice calls while he sleeps. Tan describes it as a knowledge system, not retrieval in a box. Same architecture Luhmann proved in the 1960s, and Karpathy adapted for LLMs in 2026.
On June 12, 2026, the pattern got a name: the Google Open Knowledge Format.
Google’s contribution was formalizing what already worked and making it portable across any tooling that needs to consume it. That is a legitimate contribution. It is not the invention. Separate raw sources from compiled knowledge, cross-link between concept pages, and make the structure portable. Four builders. Same answer. Sixty years apart.
Why the Open Knowledge Format Does Not Replace RAG
This is where the YouTube hot takes fall apart on contact with technical reality.
The Google Open Knowledge Format is a folder of files. RAG is how you find what is in the folder at scale. They are not competing technologies. They operate at completely different layers in the same stack.
The architecture looks like this: your agent sits at the query interface. Below that lives the retrieval layer, where RAG runs. Below that is the knowledge layer, where your OKF bundle or wiki is stored. At the bottom sits the source layer with raw immutable documents.
My RAG pipeline does not search notes the way a file browser does. Before retrieval even starts, the LLM generates three reformulated versions of the query, three different angles on the same question, running simultaneously. Then it writes a hypothetical answer to the question and uses that fake answer as an additional search vector, because a plausible answer is semantically closer to real answers than the raw question ever is. That process pulls back 20 candidate chunks across BM25 keyword search and vector similarity search combined. RRF fusion scoring ranks all 20 against both signals at once. The top 7 go to the agent.
OKF is a folder of markdown files with a “type” field. Those are not the same layer of the stack. One is a file cabinet. The other is an intelligence system that finds the right content before you finish asking.
Saying the Google Open Knowledge Format replaces retrieval is like saying a filing cabinet replaces a search engine. A well-built system uses both because they solve different problems at different layers. The hot take channels do not understand the stack. They saw “knowledge format” and assumed it replaced the whole thing.
I Already Built This. So Did You.
I run a 2,600-note Obsidian vault organized across 22 domains in a topic-first structure. Every note has YAML frontmatter with a “type” field. The entire vault is backed up to GitHub, feeds a pgvector RAG pipeline, and gets queried by Hermes, an 11-profile multi-agent system I built and rely on every day for research, writing, and content production.
I was Open Knowledge Format compliant before the standard had a name.
And I am not special. Garry Tan, the president of Y Combinator, runs the same architecture at production scale, managing hundreds of thousands of pages. This is not exotic infrastructure requiring a research budget and a PhD. Markdown files with consistent structure in a git repository. That is it. Anyone with Obsidian and a free GitHub account can do this today.
HHere is why this blog exists. I spent years consuming AI content that generated genuine excitement and delivered zero implementation depth. You finish the video knowing something exists. You still cannot ship anything. The gap between “this technology is interesting” and “here is how a practitioner actually builds, debugs, and ships it in production” is the only gap worth writing about. bradtrnavsky.com exists for the builder who watched six videos on a topic and is still staring at a blank terminal. My readers are the people who weren’t buying the hype and kept looking for something better.
Why This Keeps Happening
This part matters beyond the Google Open Knowledge Format, as the same cycle will repeat in the next announcement. It always does.
A major company publishes a spec. Within hours, creators scan the announcement for keywords that trigger emotional responses strong enough to drive clicks. Titles get built around fear or excitement because those emotions convert better than nuance. The algorithm sees the engagement and promotes the video. The creator sees the views and doubles down on the formula. Revenue compounds. Accuracy is irrelevant to the incentive loop.
Some of these creators are cynical. More of them are just optimizing for what works on their platform. The result is the same either way. Builders consume content that leaves them exactly where they started, anxious about whether their setup is obsolete and no closer to understanding what actually changed.
The cycle is systemic, not individual. Every major platform announcement produces it. What compounds in your feed is not what educates you. It is what triggers you. The next time a company drops a spec and your recommendations fill up with reaction videos claiming everything has changed, read the source material yourself. It usually fits on one page.
What You Should Actually Do
If you have an Obsidian vault with YAML frontmatter in a Git repository, you are done. Your archive is already portable across any tooling that supports the Google Open Knowledge Format standard. Close the video. Go back to building.
If you are not there yet, here is the complete path: structure your notes with consistent frontmatter fields, including at minimum a “type” field; put the directory under version control so every change is tracked; and cross-link between notes so the knowledge graph gets denser with every entry. Three steps. No migration. No subscription. No panic.
Knowledge systems are not tools. They are advantages that compound over time. The builder who has been maintaining a structured knowledge base for three years thinks differently from the one who just watched a YouTube video about it.
The Google Open Knowledge Format (OKF) is an open specification published on June 12, 2026. It represents knowledge as a directory of markdown files with YAML frontmatter. The only required field is “type.” There is no schema registry, no central authority, no required SDK or cloud account. The full spec fits on a single printed page. It is a format, not a platform.
No. The Google Open Knowledge Format and RAG operate at completely different layers of the same stack. OKF is a file format for organizing knowledge at the knowledge layer. RAG is a retrieval mechanism that finds relevant content at query time at the retrieval layer. A well-built system uses both. Saying OKF replaces RAG is like saying a filing cabinet replaces a search engine.
No. Karpathy published the LLM Wiki pattern on April 4, 2026, two months before the Google Open Knowledge Format was announced. Google’s own announcement explicitly says OKF “formalizes the LLM-wiki pattern.” OKF is the interoperability layer built on top of what Karpathy described. It validated the pattern. It did not replace it.
Almost certainly yes. The Google Open Knowledge Format requires two things: markdown files with parseable YAML frontmatter, and a non-empty “type” field in every frontmatter block. If your Obsidian vault uses consistent YAML frontmatter with a type field and is backed up to a git repository, you are already compliant. No migration needed.
Every markdown file must have a parseable YAML frontmatter block, and every frontmatter block must contain a non-empty “type” field. That is the entire Google Open Knowledge Format conformance requirement. Everything else including title, description, tags, timestamp, and resource URL is optional. Consumers must not reject a bundle for missing optional fields.
Want implementation-depth AI takes?
This post is part of the Knowledge & Context Systems pillar on bradtrnavsky.com, a practitioner-first series on PKM, RAG, agentic workflows, and the AI tools that actually ship. If you build with AI and are tired of the hype cycle, subscribe to get new posts as they drop.
Get new posts by email