General 16 min read

Google Just Standardized 'Your Knowledge Is Plain Markdown Files'

MMNMNOTE
open-knowledge-formatmarkdownyaml-frontmatterknowledge-managementfile-over-app

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 was humble — it launched as v0.1, and the spec is now at v0.2.2 The idea behind it is not humble at all. 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 — launched at v0.1 and now at v0.2 — 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 and portable: Apache-2.0 licensed, so anyone can read, implement, or fork it.3 That removes the trade — convenience now, lock-in later — that every proprietary knowledge tool quietly asks you to accept.1

Worth being precise about the limit of that, though: open-licensed is not the same as independently governed. OKF is authored and controlled by Google. The repository carries no GOVERNANCE.md, contributions run through a Google Contributor License Agreement, and a community request for an authoritative OKF site, opened on July 26, 2026, has no reply yet.3

What you are guaranteed is the right to fork, not a seat at the table. For a format whose whole value proposition is that it outlives its author, that distinction is the one to watch.

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 names exactly one required frontmatter field and four recommended ones. The spec is blunt about it: "type is the only always-required key; a concept carrying just type is fully conformant."2 The four recommended keys are title, description, resource, and tags. Everything else is yours.2

As the launch blog puts it, "OKF requires exactly one thing of every concept: a type field."1 Here is a real OKF concept document, abridged from the current 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]
generated: { by: reference_agent/gemini-2.5-pro, at: 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.          |

(In v0.1 that last line was a bare timestamp: field. v0.2 supersedes it with generated, which records who produced the concept alongside when.2)

The minimalism is the durability. The spec instructs that consumers "SHOULD preserve unknown keys when round-tripping and MUST NOT reject documents with unrecognized fields."2 You can add any field you like; nothing breaks. A format that is forbidden from rejecting your data is a format you can still read in ten years.

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 graph4, 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 5

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."5 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 at v0.2 it is still a pre-1.0 spec that can change.6 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).6

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."6 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.

Update: what v0.2 added on July 25, 2026

Six weeks after the launch, Google shipped OKF v0.2 in a post titled "Open Knowledge format v0.2 tackles agentic trust."7 The addition is a trust layer, and it is all frontmatter — no new machinery. New optional keys let a reader ask where a concept came from, who checked it, whether it is current, and how its numbers were computed.7

None of it is mandatory. type remains the only always-required key, and all of the above are optional keys whose absence is itself meaningful — an unverified concept stays readable rather than being rejected.2

The cost of moving is low, though not quite zero: "v0.2 is a minor version bump that is additive, backward-compatible, with two deliberate renames."7 The spec files those two renames under breaking changes (timestamp and the body # Citations list) and gives consumers a v0.1 fallback for each.2

The personal-notes read on this is small but real. The questions v0.2 makes answerable — where did this come from, who checked it, is it stale — are the same questions you ask of a two-year-old note. Google's answer is that they belong in the file's own frontmatter, not in a database beside it. That is a convention you can adopt today with a plain .md file and four extra lines.

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:

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 that Google Cloud published on June 13, 2026, at v0.1 and updated to v0.2 on July 25, 2026.7 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 AGENTS.md?

No — same family, different scope. AGENTS.md is a single readme-for-agents file describing one project or repo. OKF is a multi-file format: a whole directory of typed concept documents that link into a graph. Google's own launch post places them side by side, naming "the AGENTS.md / CLAUDE.md family of convention files" among the patterns OKF generalizes.1 If you know the AGENTS.md convention,10 think of OKF as that idea scaled 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.4

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?

Treat it as maturing, not finished. The spec is at v0.2,2 still pre-1.0, and its reference implementations target enterprise data pipelines rather than personal use.6 It is also authored and controlled by Google, with no independent governance body.3 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.5

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

  1. 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 13

  2. "Open Knowledge Format (OKF) Specification, Version 0.2," GoogleCloudPlatform/knowledge-catalog. Verified against commit 3fcbb9f (July 24, 2026). https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  3. Licensing and governance verified against GoogleCloudPlatform/knowledge-catalog at commit 3fcbb9f (July 24, 2026): Apache-2.0 (okf/LICENSE.md); no GOVERNANCE.md present in the repository tree; CONTRIBUTING.md requires a Google Contributor License Agreement; issue #231, "Do you have any plans to have authoritative site for OKF?" (opened July 26, 2026), remains open with no replies. https://github.com/GoogleCloudPlatform/knowledge-catalog 2 3

  4. "GraphRAG Over Your Own Notes: Your Wiki-Links Already Are a Graph," MNMNOTE. https://blog.mnmnote.com/posts/graphrag-over-your-own-notes 2

  5. Andrej Karpathy, "LLM Wiki," GitHub gist, 2026. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 2 3

  6. 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

  7. Sam McVeety and Amir Hormati, "Open Knowledge format v0.2 tackles agentic trust," Google Cloud Blog, July 25, 2026. https://cloud.google.com/blog/products/data-analytics/okf-v0-2-adds-trust-signals 2 3 4 5 6 7 8

  8. "YAML Frontmatter: The Metadata Header for Your Notes," MNMNOTE. https://blog.mnmnote.com/posts/yaml-frontmatter-the-metadata-header

  9. "Markdown Notes as AI Memory," MNMNOTE. https://blog.mnmnote.com/posts/markdown-notes-as-ai-memory

  10. "AGENTS.md: A README for Your AI Agents," MNMNOTE. https://blog.mnmnote.com/posts/agents-md-readme-for-agents