# Self-describing knowledge: why the Open Knowledge Format matters, and what enterprises must add By Muthukrishnan (Muthu) Bommiah · Context engineering · Sep 15, 2026 > In June, Google Cloud published the Open Knowledge Format: knowledge as plain Markdown with a little structured metadata. It is the right foundation. Regulated enterprises need the next step: knowledge that states its own owner, provenance, freshness and trust. **Knowledge for AI agents should live in plain files that state, on their face, who owns them and how far to trust them.** Throughout this series I have argued that context is the asset AI runs on, that it is fragmented, that it should be curated rather than collected, and that it can be captured from the work itself. The last question is the most practical one: what format should that knowledge take? On June 12, 2026, Google Cloud published a candidate answer: the [Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing), or OKF v0.1. I think it gets the foundation right. I also think regulated enterprises need to build on top of it carefully, and together. ## What OKF is OKF v0.1 is deliberately small. Knowledge is a directory of Markdown files, one concept per file, where the file path is the concept's identity. A concept can be a table, a dataset, a metric, a runbook or an API. Each file carries YAML frontmatter, and only one field is required: `type`. Optional fields cover a title, a description, a link to the live resource, tags and a timestamp. Concepts link to each other with ordinary Markdown links, which turns the directory into a graph. Optional index files support progressive disclosure, and optional log files record history. The [spec and reference code](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf) are public. Google's principles are the important part: minimally opinionated, producers and consumers independent of each other, and a **format, not a platform**, with no required cloud, database, model provider or SDK. Google describes OKF as formalizing the [LLM wiki pattern](https://noqta.tn/en/blog/karpathy-llm-wiki-knowledge-base-beyond-rag-2026) Karpathy popularized, and places it in the same family as convention files like AGENTS.md. I find it useful to think of three pieces: instructions for agents (AGENTS.md), executable workflows (skills), and reference knowledge. OKF fills the third. ## Why plain files are the right foundation - **People and agents read the same thing.** Markdown renders in any editor and on GitHub, and models read it natively. - **Version control comes free.** Put knowledge in Git and you get history, diffs, review, blame and rollback, the controls engineering already trusts. - **Retrieval stays flexible.** The same files can feed keyword search, vector indexes or a graph. The format does not lock you into one retrieval strategy. - **Switching models stays cheap.** Knowledge outlives any one model, vendor or agent framework when it lives in an open format you own. ## What enterprises must add: knowledge that vouches for itself Here is my main argument. OKF's minimal core says what a concept *is*. A regulated enterprise also needs every concept to say whether it can be **trusted**. The optional fields in v0.1 stop at title, description, resource, tags and timestamp. None of them names an owner, a source or a verifier. That is a sensible choice for a minimal core, because the spec explicitly lets producers choose their own fields. Enterprises should use that freedom deliberately and converge on a common set. These are the fields I would standardize on, as an enterprise profile on top of OKF: - **Identity:** a canonical identifier that ties the concept to the system it describes, so two sets of files never disagree about which application they mean. - **Owner:** the accountable team or person. - **Provenance:** the sources the knowledge was derived from, with links. - **Generator and verifier:** whether a person or an agent wrote it, and which human approved it. - **Freshness:** when it was last verified and when it must be reassessed. - **Confidence:** a trust tier, so consumers can tell verified fact from inferred draft. - **Classification:** sensitivity and handling rules that travel with the knowledge. In practice, an enterprise-profiled concept might look like this. The first block is plain OKF, and the rest are producer-defined fields, which the format explicitly allows: ```yaml --- type: Application title: Payments Gateway description: Routes card authorizations between channels and processors. resource: https://catalog.example.com/apps/payments-gateway tags: [payments, tier-1] timestamp: 2026-09-02T10:15:00Z # Enterprise profile (producer-defined) id: app:payments-gateway owner: team-payments-platform sources: - https://git.example.com/payments/gateway - https://tickets.example.com/browse/PAY-1042 generated_by: agent verified_by: j.doe verified_on: 2026-09-01 review_by: 2026-12-01 confidence: verified classification: internal --- ``` Everything here is human-readable and diffable, and none of it requires a proprietary platform. An agent can decide at a glance whether to trust the content below it. ## Agents that check before they answer Self-describing knowledge changes agent behavior. An agent that can read trust signals can be told to prefer verified knowledge, label drafts as drafts, refuse to act on expired content, and cite its sources by default. That is the difference between an assistant that sounds right and one an auditor can work with. It also makes governance computable, which I think is the underrated benefit. You can measure how much of your knowledge is owned, fresh and verified, and where the gaps sit, with a script instead of a survey. Governance that can be counted gets funded. Governance that lives in a policy document gets audited once a year. ## Consistency and progressive disclosure Format is half the answer, and consistency is the other half. For a technology organization I would pair the format with a standard set of sections that every application's knowledge covers: purpose and business context, architecture and dependencies, what depends on it, security and data handling, resiliency and failure modes, operations and runbooks, recent changes and incidents, and AI readiness. A standard outline lets agents move through any application the same way and lets you measure completeness across a portfolio. OKF's index files make that structure cheap to use. An agent reads a short index for an application, sees what exists, and opens only the concepts it needs. That is the file-system version of the just-in-time loading [Anthropic recommends](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), and a direct answer to context rot. Log files add the history of what changed, when and why, which is exactly the decision trace that systems of record lose. ## How it fits with what you already run Self-describing knowledge does not replace your catalogs, repositories or configuration database. It sits on top of them and points back to them through the resource and source fields. Serve the files through an MCP server and every coding agent, chat assistant and operations tool reads the same governed knowledge. Each convention does one job, and together they give agents instructions, abilities and understanding. Most importantly, the format makes knowledge portable across the next model change. When the frontier moves, and it will, the investment you made in curated, verified, self-describing knowledge moves with you. ## Keep the profile small Once teams see the value of metadata, the temptation is to keep adding fields. I have watched this happen with data catalogs: dozens of attributes per table, most of them empty, and the empty ones quietly teaching everyone that the metadata cannot be trusted. A field that is filled in for a third of concepts can be worse than no field, because consumers cannot tell missing from unknown. My rule is that a field earns its place only if an agent or a control will act on it. Owner, freshness, confidence and classification pass that test easily, because each one changes what an agent is allowed to do. A field such as business criticality might pass if your incident tooling reads it. Most other details belong in the body of the file, where people can read them, rather than in frontmatter that implies someone maintains them. Enforce the profile where files are written, not where they are read. A check on the pull request that rejects a concept without an owner or a review date costs almost nothing, and it stops decay before it starts. ## Cautions OKF is at v0.1, and it is early. An [independent review of the spec](https://agentic-ai.readthedocs.io/en/latest/Standards/open-knowledge-format/) notes that it has no formal governance body yet, unlike [AGENTS.md](https://agentic-ai.readthedocs.io/en/latest/Standards/agents-md/), which now sits with the Agentic AI Foundation under the Linux Foundation. Validators and ecosystem tooling are still forming, and there are no published benchmarks of retrieval or agent gains. Because the core is minimally opinionated, consistency inside a large organization depends on your own conventions. Treat it as a strong direction rather than a finished standard: adopt the core, keep your enterprise fields in a documented profile, and contribute back. The worst outcome would be every enterprise inventing its own incompatible extensions and recreating the fragmentation the format was meant to solve. **What to do Monday** - Pick ten knowledge files for one critical application and check whether each could state its owner, sources and last verified date. - Draft an enterprise profile of no more than seven fields on top of the OKF core and circulate it to architecture and risk. - Add a pull request check that rejects any knowledge file missing an **owner** or a review-by date. - Instruct one internal agent to label unverified content as draft and to decline actions based on expired knowledge. In the end, the format question is a readiness question. If your organization published its enterprise profile tomorrow, which of these fields would your current knowledge actually be able to fill in? **Bottom line:** Knowledge for the AI era should be plain, portable and self-describing: Markdown people can read, structure agents can parse, and metadata that says who owns it, where it came from, when it expires and how far to trust it. OKF gives us the first two. Enterprises should build the third, together. *Part 5 of the Context Engineering series.* --- Muthukrishnan (Muthu) Bommiah · https://muthub.org · Views are my own and do not represent my employer.