The Open Knowledge Format, or OKF, is an open specification from Google Cloud that stores what an organisation knows about its data and systems as a folder of plain markdown files. Each file describes one thing, such as a table, a metric or a runbook, and starts with a short block of structured fields that any AI agent can read. Since version 0.2 those fields also record who wrote a piece of knowledge, who checked it and until when it can be trusted. That last part matters most for European organisations, because the moment agents start writing your knowledge base, accountability becomes the hard problem.
What the Open Knowledge Format is, in one minute
Google Cloud announced OKF on 12 June 2026, written by Sam McVeety and Amir Hormati of the BigQuery and data analytics teams. Their diagnosis was blunt. Table schemas, metric definitions, join paths and deprecation notices sit in catalogs with their own APIs, in wikis, in code comments and in the heads of a few senior engineers. Every team building agents solves the same context problem from scratch. Their conclusion: “What’s missing is a format, not another service.”
The format itself is small. A bundle is a directory tree. Every markdown file in it is a concept, and its path is its identity. The YAML block at the top of each file needs exactly one field, type, and is recommended to carry a title, a description, a link to the underlying resource and tags. Two filenames are reserved: index.md lists what a folder contains so an agent can read top-down, and log.md keeps a dated change history. Concepts point to each other with ordinary markdown links, which turns the folder into a graph.
No SDK, no runtime, no account. You can read a bundle in any editor, ship it as a git repository and review changes with the tools your engineers already use. One of Google’s design principles is “Format, not platform”, and its own Knowledge Catalog can ingest bundles and serve them to agents. The spec and samples live in the knowledge-catalog repository on GitHub under an Apache 2.0 licence.
The idea will feel familiar if you have read about AGENTS.md files. The difference is scope. AGENTS.md tells an agent how to behave in one repository. OKF describes what the organisation knows, in a shape that should travel between tools.
Why trust became the real feature
Version 0.1 had no way to tell knowledge written by an agent from knowledge a person had reviewed. That gap mattered from day one, because Google’s own reference tooling includes an agent that walks a BigQuery dataset and drafts a concept for every table and view. Generating a thousand pages of documentation overnight is now cheap. Knowing which of those pages are correct is not.
The authors put the problem plainly in the v0.2 announcement of 24 July 2026:
“A human-authored wiki page comes with an implicit guarantee: a person wrote it, and you can hold them accountable if it is wrong. When an agent generates ten thousand concepts overnight, that guarantee is gone.”
Sam McVeety and Amir Hormati, Google Cloud
So v0.2 adds vocabulary for five questions any consumer of a concept should be able to answer. Every new field is optional, type is still the only requirement, and v0.1 bundles keep working.
The five trust signals and what they mean for governance teams
| Question | OKF v0.2 field | What it gives a governance team |
|---|---|---|
| What was this created from? | sources |
A list of the documents and systems behind a concept, with author and last modified date |
| How much should I trust it? | generated and verified |
Who or what produced it, who confirmed it, and a tier: unverified, machine-confirmed or human-reviewed |
| Is it still true? | stale_after |
A fixed date after which the concept must be checked again before use |
| Is it the current version? | status |
Draft, stable or deprecated, so an old metric stays documented without being reused |
| Was this number produced the way we said? | Attested Computation |
A sanctioned calculation plus a check that a specific run followed it |
In practice the fields look like this, combined from two concepts in Google’s acme_retail sample bundle, which describes a fictional company:
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }
verified:
- { by: human:kliu@acme, at: 2026-07-01T16:00:00Z }
status: stable
stale_after: 2026-12-31
sources:
- id: revenue-policy
resource: policies/revenue-recognition.md
author: human:jsmith@acmeTwo design choices deserve attention. Google deliberately did not add a credibility score, because “a score is subjective, doesn’t port across consumers, and goes stale the moment it’s written.” And freshness is an absolute date rather than a time-to-live, which turns staleness into a simple date comparison. Both choices make the fields easier to audit. The spec is also explicit that trust tiers are advisory and are not access control. Who may read a concept is still decided by your platform, not by the file.
Attested computation and the numbers you have to defend
The most interesting addition is a new concept type, Attested Computation. It targets a familiar failure: an agent asked for year-to-date revenue that quietly writes its own SQL, joins the wrong table and returns a confident number.
With an attested computation, the approved query lives in the bundle. The agent may only fill in the declared parameters, such as the year. An executor runs the query and returns a receipt with the job id, the SQL that actually ran and the result. A deterministic attester, plain code with no language model involved, then compares the executed SQL with the approved version. Google’s description is precise: “A swapped table name, an added filter, a dropped JOIN all fail attestation.” A failed check means the consumer refuses to show the value.
For finance teams, regulated reporting and anyone who presents figures to a board, this is the part of OKF worth piloting first. It separates two things that are often blurred: verified says the definition still matches policy, attestation says this particular run followed that definition. OKF itself never executes anything. It records the computation and how to check it.
What European organisations should check before adopting it
Personal data sits in the frontmatter
Actor ids such as human:kliu@acme and author fields in sources identify people. Under article 4(1) of the GDPR, identifiers like these make information personal data. A bundle with a full verification history is therefore also a record of who reviewed what, and it falls under the usual rules on purpose, retention and the right to erasure in article 17. Git history makes deletion harder, not easier. Contributors have proposed an optional erasure conformance profile for OKF, but it is a proposal, not part of the spec. Decide up front whether you record names, pseudonymous ids or roles, and what happens when someone leaves.
Traceability is helped, not solved
For high-risk AI systems, the AI Act sets rules on data governance for training, validation and testing data in article 10 and on automatic logging in article 12. Neither maps directly onto a knowledge bundle. Provenance, verification and lifecycle fields can still support the documentation around such a system, by showing where context came from and who approved it. They do not make a system compliant, and nothing in OKF checks that the recorded events are true.
Open licence, not yet open governance
Gianluca Fiorelli summed up the status well: “open license, not yet open governance.” The spec sits in a Google repository and has no standards body behind it. There are signs of a wider community. Kurt Cagle, who chairs the W3C Holon Community Group, has proposed a semantic profile that adds formal typing on top of OKF. The rules also protect portability: consumers must not reject a bundle for unknown types, unknown fields or broken links, so your extensions travel. Because a bundle is markdown in git, the exit cost stays low even if Google loses interest.
A bundle is text an agent acts on
Treat bundles like code, not like data. An agent reads the prose and follows it, which makes a bundle a possible route for indirect prompt injection. Changes should go through the same review as any other instruction you give an agent, especially when external contributors or other agents can write to it.
Discovery is the missing layer
OKF packages knowledge but says nothing about how an agent finds it. A bundle on a server is, by design, invisible. Google published a separate specification, Agentic Resource Discovery, five days after OKF, in which organisations list their tools and agents in an ai-catalog.json file on their own domain. The two specs do not mention each other. Joost de Valk connected them on specification.website, publishing a 604-file bundle and listing it in an ARD catalog, and still rates both as optional while they remain drafts. For now, inside an organisation, discovery is a decision you make: point your agents at the bundle through their instructions, a skill or an MCP server.
What OKF is not
- Not an SEO tactic. The announcement came from Google Cloud and is about internal knowledge. Google nowhere presents OKF as a search or ranking signal, whatever some agencies claim.
- Not a replacement for retrieval. Direct reads suit stable, known facts. Search over large document sets still needs retrieval, which can index a bundle too.
- Not a typed knowledge graph. Links carry no relationship type. For reasoning over formal relations you still need a context graph or an ontology on top.
- Not a data catalog. It is an exchange format that catalogs, agents and wikis can read and write.
A 90-day pilot that tells you whether it is worth it
- Weeks 1 to 2. Pick one domain where wrong answers hurt, such as revenue metrics or customer data definitions, and one owner.
- Weeks 3 to 4. Let an agent draft concepts from your existing schemas and documentation. Mark everything as draft and record
generated. - Weeks 5 to 7. Have domain experts review and add
verified. Agree on astale_afterpolicy per type and on what goes in actor ids. - Weeks 8 to 9. Put the bundle in git with mandatory review, run the three conformance checks in CI and write one attested computation for your most disputed number.
- Weeks 10 to 13. Connect one agent and compare its answers with and without the bundle on a fixed set of questions. Track wrong answers, refused answers and time spent on verification.
The bundle is also a concrete way to act on the idea that models are rented and context is owned. If the model behind your agents changes next quarter, a well-kept bundle comes along unchanged.
FAQ
Do we need Google Cloud to use OKF?
No. A bundle is markdown in a folder. Knowledge Catalog can ingest it, but any tool or agent that reads files can use it.
How is OKF different from Agent Skills?
Agent Skills package how to do a task. OKF describes what is true about your data and systems. A skill can tell an agent to look something up in a bundle.
Is OKF stable enough to build on?
It is at version 0.2 and still changing. Two fields were renamed in v0.2, but consumers fall back to the old form, so v0.1 bundles still work. The risk is low because your content stays readable markdown.
Does publishing a bundle on our website help us in search?
There is no evidence that it does. OKF was designed for internal knowledge, and nothing in Google’s announcements links it to search.
The format is the easy part
Anyone can write a folder of markdown files by Friday. What OKF really asks of an organisation is a habit: someone with a name or a role signs off on what agents wrote, and a date says when that signature expires. The verified field is where your accountability lives. If nobody is willing to fill it in, the bundle will be fast, tidy and quietly wrong.
