Google Just Standardized 'Your Knowledge Is Plain Markdown Files'
On June 13, 2026, a trillion-dollar cloud vendor published an open standard whose entire thesis is that knowledge should be plain markdown files with YAML frontmatter, in version control, readable by any tool and parseable by any AI, with no SDK, no account, and no lock-in. Google Cloud calls it the Open Knowledge Format.1
The version number is humble — v0.1 Draft.2 The idea behind it is not. Sam McVeety and Amir Hormati, the Google Cloud engineers who introduced it, frame the problem in one blunt line: "The answer to this problem isn’t another knowledge service. You need a format."1 A directory of markdown files. A handful of agreed conventions. That is the whole specification.
What is the Open Knowledge Format?
The Open Knowledge Format (OKF) is an open specification, currently v0.1 Draft, that represents a body of knowledge as a directory of markdown files with YAML frontmatter. Each file is one concept. A small set of conventions lets knowledge written by one producer be read by any tool or AI agent without translation.1 2
Google Cloud's own description is precise: "OKF v0.1 represents knowledge as a directory of markdown files with YAML frontmatter, with a small set of agreed-upon conventions that let wikis written by different producers be consumed by different agents without translation."1 The spec lists four design goals. Knowledge that is "Readable by humans without tooling," "Parseable by agents without bespoke SDKs," "Diffable in version control," and "Portable across tools, organizations, and time."2
Read that last list again. It is not a feature comparison. It is a description of what a plain text file already does. The standard's most quoted line makes the point with no ceremony: "If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it."2
Why does it matter that the format is "just files"?
It matters because Google is a vendor with every incentive to sell you a service, and it chose to publish a format instead. The format is open, portable, and owned by no one. That removes the usual trade — convenience now, lock-in later — that every proprietary knowledge tool quietly asks you to accept.1
McVeety and Hormati spell out the alternative they rejected. Today, they write, "Every vendor offers its own catalog, its own SDK, its own knowledge-graph schema, and none of the knowledge is easily portable across products or organizations."1
OKF answers that by being deliberately boring. A bundle is "Just markdown" (readable in any editor, renderable on GitHub, indexable by any search tool). It is "Just files" (shippable as a tarball, hostable in any git repo, mountable on any filesystem). And it is "Just YAML frontmatter" for the small set of structured fields that need to be queryable.1
The governing principle is stated as a design law, not a slogan: OKF "is not tied to any specific cloud, database, model provider, or agent framework. It will never require a proprietary account or SDK to read, write, or serve."1 A vendor wrote that about its own standard. The reason is in the next sentence: "the value of a knowledge format comes from how many parties speak it, not from who owns it."1
How minimal is the spec, really?
OKF reserves six frontmatter fields (type, title, description, resource, tags, timestamp) and requires exactly one of them. As the blog puts it, "OKF requires exactly one thing of every concept: a type field."1 The other five are recommended, in priority order. Everything else is yours.2
Here is a real OKF concept document, copied from the spec. Note the type value, BigQuery Table, because it tells you exactly who this standard was built for:
---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| Column | Type | Description |
|---------------|-----------|-------------------------------------|
| order_id | STRING | Globally unique order identifier. |
| customer_id | STRING | Foreign key into customers. |
| total_usd | NUMERIC | Order total in US dollars. |
The minimalism is the durability. The spec instructs that consumers "SHOULD preserve unknown keys when round-tripping and SHOULD NOT reject documents with unrecognized fields."2 You can add any field you like; nothing breaks. A format that refuses to reject your data is a format you can still read in ten years.
Where do the links go, and why that quietly makes a graph
OKF does not add a graph database. The graph emerges from the markdown itself: an ordinary link from one concept document to another is the edge. The spec says consumers "that build a graph view typically treat all links as directed edges of an untyped relationship."2 Your wiki-links are the structure. No schema required.
This is the same observation we made about your own notes in why your wiki-links already are a knowledge graph3, now arriving from the enterprise side. OKF reserves two filenames, index.md for a directory listing and log.md for update history, which "MUST NOT be used for concept documents"; everything else is a concept.2
A folder of linked markdown files becomes a navigable graph the moment something reads the links. That is true whether the folder holds BigQuery table docs or your reading notes.
The pattern is not Google's invention, and Google says so. Its blog credits Andrej Karpathy, "the prominent AI researcher and educator," with articulating the idea most crisply in his LLM Wiki gist: "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass," he writes.1 4
Karpathy's own framing describes a model that "incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources."4 OKF is the standardization of a pattern that builders, including Obsidian users running Karpathy's wiki against their vaults, were already practicing by hand.
What OKF is not: the honest part
OKF is an enterprise, agent-facing knowledge-catalog standard. It was built for BigQuery tables, data teams, and AI agent pipelines. It is not a personal-notes app, and v0.1 is a Draft that could still change.5 Read it as a signal about where knowledge should live, not as a tool to install.
So the bridge to your own notes is the principle — not the product. MNMNOTE does not implement OKF, and you do not need OKF to take notes. What the two share is a conviction that a trillion-dollar vendor has now written into a spec: knowledge belongs in plain, portable, you-own-it files.
The BigQuery Table type in that example is a reminder of who OKF serves. The format underneath it — markdown a human can read and a machine can parse — is the part that travels.
The launch was not vaporware. Three reference implementations shipped with the spec: a BigQuery enrichment agent that drafts a concept doc per table, a static HTML visualizer, and three ready-to-browse sample bundles built from public datasets (GA4 e-commerce, Stack Overflow, and Bitcoin data).5
One detail from those tools is worth keeping. Google describes its visualizer as "a single self-contained file; no backend, no install on the viewing side, no data leaves the page."5 An enterprise vendor reaching for "no data leaves the page" is reaching for the same instinct that puts your notes on your own device. The direction of travel is consistent, even when the destinations differ.
What to actually do about your own notes
You do not need to adopt a spec to act on its lesson. The lesson is older than OKF and now louder because of it: the most future-proof home for your knowledge is the format the industry is converging on. Three concrete moves:
- Keep the source as plain markdown. A
.mdfile opens in any editor today and will open in any editor in 2036. If your tool can export clean markdown, your knowledge is portable — if it cannot, your knowledge is a hostage. - Put structured facts in YAML frontmatter. A few queryable fields at the top (type, tags, a timestamp) make a file readable by you and parseable by an AI. Our field-by-field walkthrough is in the YAML frontmatter guide6; OKF is the proof that the industry standardized exactly this convention.
- Let the links be the graph. Link notes to notes and you have built a graph without a graph database — the same emergent structure OKF describes2 and the reason your markdown can become an AI's working memory rather than a passive archive.7
That is the whole of it. Files you can read, fields you can query, links you can follow — stored where you control them: locally on your own device, offline, in open Markdown, with no account, and with bring-your-own-key AI when you want it. OKF is the enterprise echo of a choice you can make for your own notes today.
Frequently Asked Questions
What is the Open Knowledge Format?
The Open Knowledge Format is an open specification, currently v0.1 Draft, that Google Cloud published on June 13, 2026. It represents knowledge as a directory of markdown files with YAML frontmatter, with a small set of conventions so that knowledge written by one tool can be read by any other tool or AI agent without translation.1 2
Is OKF the same as llms.txt or AGENTS.md?
No — they are the same family but different scope. llms.txt and AGENTS.md are single readme-for-agents files that describe one project or site. OKF is a multi-file format: a whole directory of typed concept documents that link into a graph. If you know the AGENTS.md convention,8 think of OKF as that idea generalized from one file to an entire knowledge corpus.
Do I need a knowledge graph or a graph database for AI?
No. OKF makes the graph emergent. Ordinary markdown links between files are treated as directed edges,2 so the structure exists without any graph database. At personal scale, the same is true of your notes: linking note to note already builds the graph, no embedding pipeline or graph engine required.3
Does MNMNOTE implement OKF?
No. OKF is an enterprise and agent-facing standard built for things like BigQuery tables and data-team catalogs; MNMNOTE is a personal notes tool. What they share is a principle, that knowledge belongs in plain, portable markdown you own, not feature parity. You do not need OKF to take notes, and MNMNOTE does not claim to implement the spec.
Is the Open Knowledge Format production-ready?
Not yet. It is explicitly v0.1 Draft,2 and its reference implementations target enterprise data pipelines, not personal use.5 The lasting value of the launch is the signal it sends: a major cloud vendor has now formally endorsed plain markdown as the substrate for AI-ready knowledge — a direction independently corroborated by Karpathy's prior LLM Wiki pattern and the ecosystem of implementations it inspired.4
A vendor that could have sold you a service shipped a format instead, building on Andrej Karpathy's LLM Wiki pattern and standardizing it as the Open Knowledge Format. The lesson does not require their spec — only the recognition that your sentences should be readable by cat, shippable by git clone, and owned by you.
mnmnote.com keeps your notes as plain Markdown files on your own device — readable by any tool, ready for any AI.
Footnotes
-
Sam McVeety and Amir Hormati, "How the Open Knowledge Format can improve data sharing," Google Cloud Blog, June 13, 2026. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
"Open Knowledge Format (OKF) Specification, Version 0.1 — Draft," GoogleCloudPlatform/knowledge-catalog, June 13, 2026. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
"GraphRAG Over Your Own Notes: Your Wiki-Links Already Are a Graph," MNMNOTE. https://blog.mnmnote.com/posts/graphrag-over-your-own-notes ↩ ↩2
-
Andrej Karpathy, "LLM Wiki," GitHub gist, 2026. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f ↩ ↩2 ↩3
-
Sam McVeety and Amir Hormati, "How the Open Knowledge Format can improve data sharing," Google Cloud Blog, June 13, 2026 (reference implementations and visualizer). https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/ ↩ ↩2 ↩3 ↩4
-
"YAML Frontmatter: The Metadata Header for Your Notes," MNMNOTE. https://blog.mnmnote.com/posts/yaml-frontmatter-the-metadata-header ↩
-
"Markdown Notes as AI Memory," MNMNOTE. https://blog.mnmnote.com/posts/markdown-notes-as-ai-memory ↩
-
"AGENTS.md: A README for Your AI Agents," MNMNOTE. https://blog.mnmnote.com/posts/agents-md-readme-for-agents ↩