Open Knowledge Format (OKF): What It Is and How to Adopt It

Open Knowledge Format (OKF) is Google Cloud's open, vendor-neutral specification for packaging organizational knowledge as linked Markdown files with YAML metadata. It gives people and AI agents one portable body of context they can read without a proprietary SDK. As of 12 August 2026, the current version is OKF v0.2, which supersedes v0.1.

That definition needs two guardrails. This OKF is not the Open Knowledge Foundation, which shares the acronym. And it is not a new database, model, retrieval engine, agent protocol, or confirmed Google ranking signal. It is a deliberately small interchange format: a common envelope for the knowledge those systems use.

What problem does OKF solve?

Most companies do not have a knowledge shortage. They have a context assembly problem. The definition of active customer sits in a BI dashboard; the calculation lives in SQL; the exception is buried in Slack; the API contract is in OpenAPI; the incident procedure is in Confluence; and the reason behind all of it still lives in one senior engineer's head.

An agent can search these systems, but every integration returns a different shape. Each new assistant rebuilds the same connectors, chunking, metadata mapping, and permissions logic. When a team changes catalog or model vendor, the curated knowledge is often trapped in the old surface. Google Cloud introduced OKF on 12 June 2026 to formalize the recurring “LLM wiki” pattern: a shared Markdown library that humans and agents can maintain together. The Google Cloud announcement describes the missing layer as a format rather than another service.

If you are evaluating a concrete implementation rather than the format, our OpenKB review and RAG comparison examines one open-source knowledge compiler, the independent evidence and the enterprise controls it still needs.

If your broader question is how employees and agents should share one governed source of truth, the AI-ready company wiki architecture guide covers canonical knowledge, permissions, retrieval, controlled writes and a 30-day pilot.

How does Open Knowledge Format work?

An OKF knowledge bundle is a directory tree. Each durable unit of knowledge is a concept, stored as one UTF-8 Markdown file. Its path without the .md suffix is its concept ID. Standard Markdown links connect concepts into a graph, while folders provide a browsable hierarchy.

company-knowledge/
├── index.md
├── log.md
├── metrics/
│   ├── index.md
│   └── monthly-recurring-revenue.md
├── systems/
│   └── billing-api.md
└── playbooks/
    └── failed-payment.md

A concept combines small, queryable metadata with human-readable detail:

---
type: Metric
title: Monthly Recurring Revenue
description: Contracted recurring revenue normalized to one month.
resource: https://analytics.example.com/mrr
tags: [finance, saas, board]
status: stable
generated: { by: human:finance-owner, at: 2026-08-12T09:00:00Z }
verified: { by: human:controller, at: 2026-08-12T10:00:00Z }
stale_after: 2026-11-12
sources:
  - id: finance-policy
    resource: https://docs.example.com/finance/mrr
    title: Finance policy
---

# Definition

MRR includes active subscriptions and excludes one-off services.[^finance-policy]
Refund logic is defined in the [billing playbook](/playbooks/refunds.md).

[^finance-policy]: Finance policy

Only type is always required. title, description, resource, and tags remain recommended. Version 0.2 adds optional provenance, trust, lifecycle, freshness, and computation fields. Producers may still add their own keys; consumers should preserve fields they do not understand. That loose contract remains the core design choice in the official OKF v0.2 specification.

What are the three rules for an OKF v0.2 bundle?

1. Every non-reserved Markdown file has parseable YAML frontmatter.
2. Every frontmatter block contains a non-empty type. There is no central registry of types.
3. Reserved files follow their defined structure when present. index.md lists a directory for progressive navigation; log.md records dated changes. Both are optional.

Almost everything else is soft guidance. A conforming consumer should tolerate missing optional fields, unknown types, producer-specific keys, broken cross-links, and missing index files. This is intentional: a partially generated, moving knowledge base should degrade gracefully instead of becoming unreadable.

What changed from OKF v0.1 to v0.2?

Version 0.2 keeps the three-rule conformance surface but makes agent-maintained knowledge easier to inspect. It introduces optional field families rather than a central schema:

• Provenance: sources records the material behind a concept. Each source can include a stable id, title, author, usage count, and last-modified date. Markdown footnotes can use the source ID for claim-level attribution.
• Trust: generated records who or what produced the current content; verified records later checks. Consumers derive unverified, machine-confirmed, or human-reviewed tiers from those verification actors. These are advisory signals, not access control.
• Lifecycle and freshness: status can be draft, stable, or deprecated; stale_after gives consumers an absolute date after which they should warn or refuse.
• Attested computations: the new Attested Computation concept type binds a sanctioned calculation to a runtime, typed parameters, executor, receipt fields, and deterministic attester. OKF stores the contract and checking method; it does not execute the calculation.

There are two migration-breaking field changes. generated.at supersedes v0.1's timestamp, and frontmatter sources supersedes a body # Citations list. A v0.2 consumer may fall back to both legacy forms, so teams can migrate incrementally. A root index.md may now declare okf_version: "0.2".

What is OKF: and what is it not?

OKF vs RAG vs MCP vs OpenAPI vs llms.txt

These are layers, not substitutes. The clean architecture is often OKF with retrieval and tools, not OKF instead of them.

One practical stack is: domain owners edit OKF in Git; CI validates it; a RAG pipeline indexes the bundle; an MCP server exposes search plus live systems; the agent retrieves a small set of concepts and follows links when it needs depth. OKF becomes the durable source, RAG the selection mechanism, and MCP the runtime doorway.

"OKF does not solve retrieval or governance. It solves a quieter problem first: whether your knowledge survives the tool that created it and remains readable to the next human or agent."

Where does OKF create real business value?

• Agent context that survives vendor changes. A move from one model, vector database, catalog, or agent framework does not require rewriting the curated knowledge.
• Knowledge reviewed like code. Pull requests, diffs, blame, CODEOWNERS, release tags, and rollback work without buying a new governance UI.
• Faster onboarding and incident response. The same linked concepts can feed an assistant, render as documentation, and remain directly readable during an outage.
• A common export target. Data catalogs, wikis, repositories, and internal tools can each produce OKF instead of every consumer integrating with every source.
• Progressive context loading. An agent can read an index.md, select a concept, then follow links. It does not need the entire wiki in its context window.
• Queryable trust and freshness. Consumers can distinguish unverified content from human-reviewed content and warn when a concept has passed its stale_after date.

The business case is strongest when multiple agents or systems need the same curated context, knowledge changes often, and lock-in or auditability matters. If you have one static FAQ and one chatbot, a normal documentation site plus good search may be enough.

What should you put in an OKF bundle?

Start with high-value, durable concepts, not a bulk dump of everything employees ever wrote. Good first candidates are:

• business metrics, definitions, owners, calculation rules, and exceptions;
• sanctioned calculations that need typed parameters, execution receipts, and deterministic checks;
• systems, APIs, datasets, tables, event schemas, and dependencies;
• product rules, architectural decisions, runbooks, and escalation paths;
• compliance controls, evidence locations, policies, and review dates;
• customer-support playbooks with clear boundaries for automated action.

Avoid copying secrets, personal data, raw support conversations, contracts, or unrestricted credentials into a Git-readable bundle. “Plain files” is an interoperability advantage and a data-leak advantage. The bundle needs the same classification, least-privilege, retention, and review discipline as any other knowledge system.

How do you implement OKF in an enterprise?

1. Choose one decision-heavy domain. A revenue metric, customer-support process, or production service is a better pilot than “all company knowledge.”
2. Inventory sources and owners. Record the authoritative source, accountable owner, sensitivity, update trigger, and downstream consumers for each concept.
3. Define a small local profile. OKF leaves types open. Agree on perhaps 5–10 types, required local fields, naming conventions, and body templates without pretending they are part of the base spec.
4. Generate a first bundle, then curate it. Exporters and LLMs are good at drafting. Domain owners must resolve contradictions, remove secrets, and approve claims.
5. Validate in CI. Check YAML, required type, reserved files, duplicate resources, broken internal links, actor and date formats, source IDs, stale concepts, computation contracts, sensitive patterns, and owner presence.
6. Connect one consumer. Index the bundle for RAG or expose it through an agent resource. Measure answer correctness, source traceability, retrieval precision, and time to update, not just demo quality.
7. Set an operating model. Decide who reviews changes, what makes a concept stale, how access maps to bundle boundaries, and how deletions propagate to indexes and caches.

What does OKF leave unsolved?

The minimalism is both its advantage and its bill:

• Permissions: the spec does not define document- or field-level access control.
• Renames and deletion: a path is the concept ID, so moves need migration conventions. Version 0.2 adds deprecated status but still does not define deletion propagation or tombstones.
• Validation depth: conformance proves three structural rules, not truth, freshness, completeness, or safety.
• Relationship semantics: links are directed but untyped; “depends on,” “owned by,” and “replaces” live in prose unless your profile adds structure.
• Concurrency and scale: Git is excellent for review but awkward for high-frequency, multi-writer operational state.
• Discovery: a bundle must still be delivered to or exposed for a consumer. OKF does not make agents on the public internet find it automatically.

That is why we would pilot OKF as a curated knowledge layer, not declare it the new system of record. Operational data stays in operational systems; OKF documents what it means, how it connects, and how people and agents should use it.

Will OKF improve SEO or make LLMs cite your website?

Not automatically. Neither the Google Cloud announcement nor v0.2 specification defines OKF as a web-crawling, ranking, or citation signal. Publishing an /okf/ directory may make content easier for a consumer that already knows where to look, but there is no basis for promising higher Google rankings, AI Overview inclusion, or ChatGPT citations.

For public visibility, keep doing the proven work: indexable HTML, clear answer-first sections, stable URLs, named authors, primary-source citations, structured data, internal links, and genuinely useful original analysis. OKF can be an additional machine-readable export. It should not replace the website. This article itself follows that discipline, including direct claims, comparison tables, visible FAQs, and links to the canonical sources.

Should your company adopt OKF now?

Our recommendation in August 2026: run a bounded, reversible pilot. Pick 20–50 concepts, one owner group, one agent use case, and one measurable workflow. Use the v0.2 provenance and freshness fields where they answer a real operating question, and keep the source material intact. If the format changes, Markdown and YAML are cheap to migrate; if the pilot fails, the curated documents still have value.

Primary sources

1. Google Cloud: Introducing the Open Knowledge Format; announcement, motivation, design principles, and reference implementations.
2. Official Open Knowledge Format v0.2 specification; v0.2 fields, v0.1 migration, conformance, versioning, and worked examples.
3. GoogleCloudPlatform/knowledge-catalog OKF repository; reference producer, visualizer, tests, and project status.
4. Official sample OKF bundles; GA4, Stack Overflow, Bitcoin, and Acme Retail examples.
5. Andrej Karpathy's LLM wiki pattern; the workflow OKF formalizes.
6. OKF Apache 2.0 license; the license covering the published specification and reference materials.

Status checked 12 August 2026. OKF is moving quickly; verify the version and open issues before committing a long-lived enterprise profile.