Home/Blog/Metatron speaks the Open Knowledge Format
Interop

Metatron speaks the Open Knowledge Format

Your codebase's decisions just left the database. As of this release, Metatron can mirror every decision into plain markdown files inside your own git repo — and that bundle is a valid Open Knowledge Format (OKF) bundle, the open standard Google Cloud published this month. Auditable in git, editable with your agent, portable to anything that reads OKF.

The feedback I kept hearing

Metatron has always stored decisions in a local database and let you curate them in a small web UI. The UI is good, but I kept hearing the same thing: I don't want another app to click around in. I live in my editor and my agent. Why can't these just be files?

It's a fair ask. Decisions are some of the most important text in a codebase — the pattern to prefer, the approach you already rejected, the native dependency that must never reach the browser. Text that important deserves to live where the rest of your engineering truth lives: in version control, with history, diffs, blame, and pull requests. Not locked behind a tool's screen.

What the Open Knowledge Format is

On June 12, 2026, Google Cloud published the Open Knowledge Format — OKF for short — an open specification for the knowledge that AI agents need to do useful work. Its premise is refreshingly small: a knowledge bundle is just a directory of markdown files with YAML frontmatter. No SDK, no runtime, no proprietary platform. If you can cat a file you can read it; if you can git clone a repo you can ship it.

Each file is a concept. It needs exactly one required field — type — and may carry any other fields the producer finds useful. That's the whole contract. The point of the standard isn't a rich schema; it's that knowledge written by one tool can be read by another without translation.

OKF is the format I'd have reached for anyway — human-readable, agent-parseable, diffable in git, portable across tools and time. Adopting the standard means Metatron's output isn't a Metatron-shaped silo. It's just knowledge.

Your decisions, as an OKF bundle

One command mirrors a repo's decisions to disk:

metatron mirror sync --okf

You get a tree of markdown under metatron/, one file per decision, with the directory encoding status — candidates under candidate/, canonical decisions under decisions/:

metatron/
├── index.md                         # OKF directory listing
├── candidate/
│   └── prefer-zod-at-boundaries-…md
└── decisions/
    └── isolate-server-only-deps-…md

And each file is an OKF concept — readable in any editor, renderable on GitHub, indexable by any search tool. Here's what that sharp rule from the outage looks like as a concept document:

---
type: Metatron Decision
id: dec_01HZ…
scope: web/api
confidence: high
---

## Pattern
Native, server-only dependencies (e.g. `sharp`) must be structurally
isolated from client bundles — never rely on tree-shaking to keep them out.

## Rationale
Exporting a helper that transitively imports a server-only module pulls it
into the browser chunk, where its init throws. Make the import lazy so it
can never reach the client.

Git is the audit trail — and the editing surface

Because the bundle lives in your repo, the whole lifecycle becomes something git already does well. Reviewing a proposed convention is reading a diff. Asking who changed a decision and why is git blame. And the boundary that matters most in Metatron — what becomes canonical — stays human-gated, the way it always has:

git mv metatron/candidate/isolate-server-only-deps-…md \
       metatron/decisions/
metatron mirror import

Moving a file into decisions/ is the act of promotion. A human did it, deliberately, and it's recorded as a commit. Nothing self-promotes; no agent and no score can cross that line. You can also just open a file and edit the pattern or rationale — or ask your coding agent to — and mirror import applies the human-owned fields back to the database. Machine-derived fields (the helpfulness score, retrieval keywords, timestamps) ride along read-only, so an edit can't quietly overwrite them. The database stays the source of truth; the files are a faithful, two-way mirror.

Why this matters

I think knowledge should outlive the tool that captured it. If Metatron earns a place in your workflow, it shouldn't be because your decisions are trapped inside it — it should be because it's the best place to capture and serve them. Emitting a standard, open bundle is how I keep myself honest about that. Your conventions are yours: a portable OKF bundle you can read without Metatron, hand to another tool, or share across teams.

It also fits the shape of the product. Metatron's job is to give a coding agent a teammate to ask before it acts. The Open Knowledge Format is becoming a common language for exactly that kind of agent knowledge — so speaking it natively means the decisions you curate here can travel as far as the standard does.


It's live now. Point Metatron at a repo, run metatron mirror sync --okf, and watch your team's hard-won decisions become plain, portable, version-controlled files — without giving up the human-gated curation that makes them trustworthy. The docs have the details.