--- title: "Open Knowledge Format (OKF): Enterprise Guide 2026" canonical: https://wavect.io/blog/open-knowledge-format-okf/ language: en description: "How Open Knowledge Format structures agent-ready knowledge, how OKF compares with RAG and MCP, and when your company should adopt it." image: "https://wavect.io/img/blog/headers/header_open-knowledge-format-okf.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 19 min read · 12 Jul 2026 Last reviewed August 12, 2026 [**Next**](/blog/software-maintenance-cost-benchmark-dach-saas/) # Open Knowledge Format (OKF): What It Is and How to Adopt It TL;DR Open Knowledge Format (OKF) is Google Cloud's vendor-neutral v0.2 specification for packaging organizational knowledge as linked Markdown files with YAML frontmatter. Version 0.2 keeps type as the only always-required concept field and adds optional provenance, verification-derived trust tiers, lifecycle and freshness signals, plus attested computations. It supersedes v0.1 by replacing timestamp with generated.at and body citation lists with frontmatter sources, while retaining consumer fallbacks. OKF still does not replace RAG, MCP, OpenAPI, a vector database, permissions, retrieval evaluation, or governance, and it is not a confirmed SEO, crawler, or LLM-citation signal. The pragmatic move is a reversible 20-to-50-concept pilot with CI validation, access controls, named reviewers, stale_after dates, and measured retrieval quality. **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](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) 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](/blog/openkb-review-vs-rag/) 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](/blog/ai-ready-company-wiki/) 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](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md). ## 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 is | OKF is not | | --- | --- | | A portable format for exchanging curated knowledge | A hosted knowledge-management product | | Markdown files plus YAML frontmatter and links | A database, vector store, or graph database | | A producer/consumer contract | A retrieval algorithm or context-ranking system | | Readable by people, Git, search tools, and agents | A permissions model, data-loss prevention layer, or audit system | | Extensible through arbitrary metadata and body sections | A fixed enterprise taxonomy or ontology | | An open v0.2 specification under Apache 2.0 | A mature standard with proven broad adoption | ## 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. | Layer | Question it answers | What it does well | What it does not do | | --- | --- | --- | --- | | **OKF** | How should portable knowledge be packaged? | Human-readable context, metadata, links, versioning, exchange | Retrieve, execute tools, or enforce access | | **RAG** | Which passages should enter this model request? | Search, ranking, chunk retrieval, grounding at query time | Define a portable authoring format | | **MCP** | How can an agent discover and call tools or resources? | Runtime capabilities, typed operations, live system access | Standardize the knowledge stored behind those tools | | **OpenAPI** | How does this HTTP API behave? | Formal endpoints, parameters, schemas, client generation | Capture broad organizational context and decisions | | **llms.txt** | Where should an LLM start on this website? | Public-site discovery and curated navigation | Specify a complete internal knowledge bundle | | **Knowledge graph** | Which entities and typed relationships exist? | Formal semantics, graph queries, inference | Stay effortless to author as plain prose | 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. ![Kevin Riedl](/img/team/kevin.webp) "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? | Pilot OKF now when… | Wait or keep it simpler when… | | --- | --- | | Several agents need the same curated knowledge | You have one small, stable documentation set | | Knowledge is trapped across catalogs and wikis | Your immediate problem is search quality, not portability | | Git review and vendor independence matter | Non-technical editors cannot work through the chosen interface | | You can assign domain owners and governance | Nobody owns freshness or access decisions | | You accept that a young v0.2 specification may keep evolving | You require a finalized standard and certified tooling | 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. ## Frequently Asked Questions ### What is Open Knowledge Format (OKF)? Open Knowledge Format is an open, vendor-neutral Google Cloud specification for representing knowledge as linked Markdown files with YAML frontmatter. People and AI agents can read and exchange the same bundle without a proprietary SDK. The current version is v0.2. ### Which field is required in an OKF concept? Only `type` is always required in each concept document's YAML frontmatter. `title`, `description`, `resource`, and `tags` are recommended; the v0.2 provenance, trust, lifecycle, freshness, and computation families are optional unless their own contract says otherwise. ### Does OKF replace RAG or MCP? No. OKF packages portable knowledge; RAG retrieves the most relevant pieces for a request; MCP connects agents to resources and tools. They can work together in one architecture. ### Does OKF improve SEO or AI citations? There is no official evidence that OKF is a ranking, crawler, or citation signal. It can structure context for systems that already access the bundle, but it does not replace an indexable website, authoritative sources, or web structured data. ### Is OKF production-ready? OKF v0.2 is a young specification with usable structural, provenance, trust, freshness, and attestation conventions. Enterprise deployments still need their own access control, CI enforcement, retrieval evaluation, review workflow, runtime security, and governance. ### Is OKF related to the Open Knowledge Foundation? No. Both use the acronym OKF. This article covers Google Cloud's Open Knowledge Format, introduced in June 2026, not the nonprofit Open Knowledge Foundation. ## Primary sources 1. [Google Cloud: Introducing the Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing); announcement, motivation, design principles, and reference implementations. 2. [Official Open Knowledge Format v0.2 specification](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md); v0.2 fields, v0.1 migration, conformance, versioning, and worked examples. 3. [GoogleCloudPlatform/knowledge-catalog OKF repository](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf); reference producer, visualizer, tests, and project status. 4. [Official sample OKF bundles](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles); GA4, Stack Overflow, Bitcoin, and Acme Retail examples. 5. [Andrej Karpathy's LLM wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f); the workflow OKF formalizes. 6. [OKF Apache 2.0 license](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/LICENSE.md); 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.* ## Final thoughts Open Knowledge Format is compelling because it standardizes very little. One always-required field, familiar files, normal links, and a permissive consumer contract make curated knowledge portable between people, agents, catalogs, and model stacks. Version 0.2 adds practical signals for provenance, trust, freshness, and attestable calculations without turning the format into a platform. Those fields are evidence, not enforcement. OKF still will not choose the right context, apply permissions, secure an executor, guarantee that reviews happen, or earn AI citations by itself. Treat it as the durable knowledge layer beneath retrieval and tools. Pilot it where knowledge portability already hurts, measure whether answers and updates improve, and build governance before the bundle becomes another forgotten wiki. ## You may also like.. [**MCP vs RAG vs Agent Skills vs Custom GPTs** A practical decision framework for choosing the right AI context and integration layer.](/blog/mcp-vs-rag-vs-agent-skills-vs-custom-gpts/) [**AI enablement vs a generic AI consultancy** Compare a working, owned AI setup with a strategy-only engagement.](/compare/ai-enablement-vs-generic-ai-consultancy/) Agent engineering ## Continue through this cluster Coding agents, MCP, context systems, evaluation and the controls required for dependable automation. [Start with the cornerstone**Graph Engineering for AI Agents: When Does a Knowledge Graph Pay Off?**](/blog/graph-engineering-ai-agents/) - [TrueForge Review: Is the Open-Source Agent Harness Production-Ready?](/blog/trueforge-agent-harness-review/) - [Agent-Readable Websites: llms.txt, Markdown Mirrors and What Breaks](/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Localized URLs Break hreflang: Keep One English Slug](/blog/english-slugs-vs-localized-urls-hreflang/) - [Can an AI Agent Use Your Product, or Only Read About It?](/blog/can-an-ai-agent-use-your-product/) - [Graft Review 2026: Do Agent Repo Maps Belong in Git?](/blog/graft-review-agent-repo-map/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 19 min read · 12 Jul 2026 Last reviewed August 12, 2026 [**Next**](/blog/software-maintenance-cost-benchmark-dach-saas/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/open-knowledge-format-okf/#webpage", "@type": "WebPage", "dateModified": "2026-07-12", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-12", "url": "https://wavect.io/blog/open-knowledge-format-okf/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Open Knowledge Format (OKF) is Google Cloud's vendor-neutral v0.2 specification for packaging organizational knowledge as linked Markdown files with YAML frontmatter. Version 0.2 keeps type as the only always-required concept field and adds optional provenance, verification-derived trust tiers, lifecycle and freshness signals, plus attested computations. It supersedes v0.1 by replacing timestamp with generated.at and body citation lists with frontmatter sources, while retaining consumer fallbacks. OKF still does not replace RAG, MCP, OpenAPI, a vector database, permissions, retrieval evaluation, or governance, and it is not a confirmed SEO, crawler, or LLM-citation signal. The pragmatic move is a reversible 20-to-50-concept pilot with CI validation, access controls, named reviewers, stale_after dates, and measured retrieval quality.", "articleBody": " Blog overview/AI and agents/Agent engineering Open Knowledge Format (OKF): What It Is and How to Adopt It TL;DR Open Knowledge Format (OKF) is Google Cloud's vendor-neutral v0.2 specification for packaging organizational knowledge as linked Markdown files with YAML frontmatter. Version 0.2 keeps type as the only always-required concept field and adds optional provenance, verification-derived trust tiers, lifecycle and freshness signals, plus attested computations. It supersedes v0.1 by replacing timestamp with generated.at and body citation lists with frontmatter sources, while retaining consumer fallbacks. OKF still does not replace RAG, MCP, OpenAPI, a vector database, permissions, retrieval evaluation, or governance, and it is not a confirmed SEO, crawler, or LLM-citation signal. The pragmatic move is a reversible 20-to-50-concept pilot with CI validation, access controls, named reviewers, stale_after dates, and measured retrieval quality. 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? Every non-reserved Markdown file has parseable YAML frontmatter. Every frontmatter block contains a non-empty type. There is no central registry of types. 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Google Cloud: Introducing the Open Knowledge Format", "url": "https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing" }, { "@type": "WebPage", "name": "Official Open Knowledge Format v0.2 specification", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md" }, { "@type": "WebPage", "name": "GoogleCloudPlatform/knowledge-catalog OKF repository", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf" }, { "@type": "WebPage", "name": "Official sample OKF bundles", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles" }, { "@type": "WebPage", "name": "Andrej Karpathy's LLM wiki pattern", "url": "https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f" }, { "@type": "WebPage", "name": "OKF Apache 2.0 license", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/LICENSE.md" } ], "dateModified": "2026-08-12", "datePublished": "2026-07-12", "description": "Open Knowledge Format (OKF) is Google Cloud's vendor-neutral v0.2 specification for packaging organizational knowledge as linked Markdown files with YAML frontmatter. Version 0.2 keeps type as the only always-required concept field and adds optional provenance, verification-derived trust tiers, lifecycle and freshness signals, plus attested computations. It supersedes v0.1 by replacing timestamp with generated.at and body citation lists with frontmatter sources, while retaining consumer fallbacks. OKF still does not replace RAG, MCP, OpenAPI, a vector database, permissions, retrieval evaluation, or governance, and it is not a confirmed SEO, crawler, or LLM-citation signal. The pragmatic move is a reversible 20-to-50-concept pilot with CI validation, access controls, named reviewers, stale_after dates, and measured retrieval quality.", "headline": "Open Knowledge Format (OKF): The Enterprise Guide", "image": "https://wavect.io/img/blog/headers/header_open-knowledge-format-okf.svg", "inLanguage": "en", "keywords": "Open Knowledge Format, OKF, AI agents, knowledge management", "mainEntityOfPage": { "@id": "https://wavect.io/blog/open-knowledge-format-okf/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/open-knowledge-format-okf/", "wordCount": 2929 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/ai-agents/", "name": "AI and agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/agent-engineering/", "name": "Agent engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/open-knowledge-format-okf/", "name": "Open Knowledge Format (OKF): Enterprise Guide 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Open Knowledge Format is an open, vendor-neutral Google Cloud specification for representing knowledge as linked Markdown files with YAML frontmatter. People and AI agents can read and exchange the same bundle without a proprietary SDK. The current version is v0.2." }, "name": "What is Open Knowledge Format (OKF)?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Only type is always required in each concept document's YAML frontmatter. title, description, resource, and tags are recommended; the v0.2 provenance, trust, lifecycle, freshness, and computation families are optional unless their own contract says otherwise." }, "name": "Which field is required in an OKF concept?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. OKF packages portable knowledge; RAG retrieves the most relevant pieces for a request; MCP connects agents to resources and tools. They can work together in one architecture." }, "name": "Does OKF replace RAG or MCP?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "There is no official evidence that OKF is a ranking, crawler, or citation signal. It can structure context for systems that already access the bundle, but it does not replace an indexable website, authoritative sources, or web structured data." }, "name": "Does OKF improve SEO or AI citations?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "OKF v0.2 is a young specification with usable structural, provenance, trust, freshness, and attestation conventions. Enterprise deployments still need their own access control, CI enforcement, retrieval evaluation, review workflow, runtime security, and governance." }, "name": "Is OKF production-ready?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Both use the acronym OKF. This article covers Google Cloud's Open Knowledge Format, introduced in June 2026, not the nonprofit Open Knowledge Foundation." }, "name": "Is OKF related to the Open Knowledge Foundation?" } ] } ```