On June 12, Google quietly released a specification called Open Knowledge Format (OKF), introducing it as a “vendor-neutral standard for delivering organizational knowledge to AI agents.” Six weeks later, on July 25, v0.2 arrived, directly addressing the question: “Can an agent trust this knowledge?”
A new standard usually attracts plenty of introductions, but marketing language and the actual specification often differ subtly. OKF was no exception. So this post takes a slightly different approach: cross-checking every claim against the original specification (SPEC.md) and official announcements, and labeling what is verified and what is not. An article introducing a standard about the provenance and trustworthiness of knowledge should probably be written that way too.
As of July 29, 2026, I cross-checked SPEC.md in the specification repository (GoogleCloudPlatform/knowledge-catalog), two official Google Cloud blog posts, and related community sources. The ✅ Verified / ⚠️ Caution / ❌ Unverified labels in each section reflect that process. OKF is still a draft (v0.2), so individual fields may change.
What Is OKF?
OKF is an open specification that represents organizational knowledge—metric definitions, table schemas, APIs, and runbooks—as a directory of Markdown files with YAML frontmatter. Its structural rules can be summarized in three lines.
- One file = one concept
- The file path, minus .md, is the concept's ID
- Relationships between concepts are ordinary Markdown links—as links accumulate, the whole directory becomes a relationship graph
The most striking feature is the specification's minimalism. In numbers:
In other words, the file below is a fully conformant OKF concept on its own.
# runbooks/deploy-rollback.md
---
type: Runbook
---
배포 롤백 절차는 ...“type is the only required field” is exactly what the specification says. SPEC.md states: “There is no schema registry, no central authority, and no required tooling.” Section 11 likewise has just two conformance requirements: (1) parseable YAML frontmatter and (2) a nonempty type. title, description, and tags are merely recommended, and even type values are not registered centrally.
Google Knows It Is “Nothing New”
“What is new about adding frontmatter to Markdown? How is this different from Obsidian?” These were among the most common community reactions after OKF's announcement. Interestingly, Google itself raises this point in the launch blog post.
“Similar knowledge-as-Wiki pattern keeps reappearing under different names: Obsidian vaults wired to coding agents, the AGENTS.md / CLAUDE.md family of convention files ... each instance is bespoke. OKF formalizes the small set of conventions needed to make these patterns interoperable.”
— Google Cloud launch blog post
The launch post links directly to Karpathy's LLM Wiki idea and defines OKF as a formalization of the “LLM-wiki” pattern. Its value proposition was therefore standardized interoperability, rather than technical novelty, from the outset: put common conventions around the bespoke “Markdown knowledge folders” built for each agent and company, making them portable.
The framing of OKF as “Google's answer to Karpathy's LLM wiki” came from Google's own launch messaging—the blog and official tweets—rather than the community. The real debate is therefore more accurately understood as “Do we need a common standard backed by Google?” than “Is the format new?”
v0.2: “Can This Knowledge Be Trusted?”
If v0.1 defined how to represent knowledge, v0.2 is about trust. The Google blog organizes what an agent should assess when reading a concept file into five questions: What was it derived from (provenance)? How much can it be trusted (trust)? Is it still valid (freshness)? Is it the latest version (lifecycle)? Was it computed as promised (attestation)?
Many introductions repeat these “five questions” as though five signal families were added to the specification, but the actual specification has four families: trust, lifecycle, provenance, and computation. Freshness is a single lifecycle field, stale_after, rather than its own family. Attestation is implemented as a separate concept type (Attested Computation, §10), rather than a frontmatter family. The blog's “five questions” are a consumer-facing framing; the specification's “four families” are the actual data structure. Keeping that distinction in mind makes the specification much clearer.
The Actual Field Structure
Reconstructing v0.2 frontmatter from the specification's examples gives the following.
---
type: Metric
title: Quarterly Revenue
generated: # 누가·언제 만들었나
by: reference_agent/gemini-2.5-pro
at: 2026-06-20T22:53:05Z
verified: # 누가·언제 검증했나 (작성자와 별개)
- by: human:ahormati
at: 2026-06-25T09:00:00Z
sources: # 출처 — 엔트리당 필수는 resource 하나
- id: rev-policy
resource: https://wiki.acme/finance/revenue-recognition
status: stable # draft | stable | deprecated (생략 시 stable)
stale_after: 2026-12-31 # 이 날짜가 지나면 stale
---Two details in the design stand out:
- The deliberate separation of
generatedandverified—in the official blog's words, because “who wrote it and who checked it do not have to be the same actor.” The field structure directly reflects a pipeline in which AI creates the content and a human verifies it. - Actor notation (§7)—agents and tools use producer/version, such as
reference_agent/gemini-2.5-pro, while humans use a value such ashuman:ahormatiwith thehuman:prefix. That prefix is the key to deriving the trust tiers below.
Three Levels of Trust: Machine-Readable Trust Tiers
A consumer, usually another agent, derives one of three trust tiers for a concept from the verified field alone.
These are the exact rules in SPEC.md §5.3. Since the determination depends on the presence of the human: prefix in the actor string, it is fully machine-readable from a parser's perspective. The repository README summary appears to imply that generated is considered too, but the normative text—the specification—uses verified alone.
Backward Compatibility: Exactly Two Renames
v0.2 is an additive minor bump with exactly two intentional renames: v0.1's timestamp → generated.at, and the body’s # Citations list → sources frontmatter. In the specification's words, “A v0.1 bundle drops in unchanged.” Existing bundles work without modification.
How Does It Relate to AGENTS.md and CLAUDE.md?
If you use Claude Code or another coding agent, you are probably already supplying context through convention files such as CLAUDE.md and AGENTS.md. Does OKF replace those? A community FAQ offers a clear distinction.
"AGENTS.md tells an agent how to behave. OKF tells an agent what exists in the world. They're friends, not competitors."
| AGENTS.md / CLAUDE.md | OKF bundle | |
|---|---|---|
| Role | “Behave this way” (instructions) | “This is what we know” (knowledge) |
| Scope | One repository or agent | Organization-wide knowledge, portable across repositories and tools |
| Composition pattern | AGENTS.md instructs: “For domain context, refer to the OKF bundle in /knowledge” | |
The okf.md FAQ behind this comparison is an independently run community site, not an official Google source. It is also still based on v0.1 and does not reflect the trust fields. The framing is useful, but must not be cited as an “official position.” Google's launch post identifying AGENTS.md and CLAUDE.md as “instances of the same pattern,” discussed above, is an official primary source.
“Throw Away Your Vector DB”? The Specification Does Not Say That
A community narrative has grown around OKF: “Abandon vector DBs and RAG, and return to a Markdown link graph.” The claim is that following explicit links instead of approximate similarity search removes both embedding costs and hallucination risk.
In this verification, I found no statement in either the official specification or the Google blog posts positioning OKF against vector DBs or RAG. The “OKF vs RAG” framing is entirely a community interpretation. Even on a practical level, stable organizational facts such as metric definitions and runbooks suit direct reading, while exploratory queries over large corpora still need search, so the two are not mutually exclusive. Treat “the end of vector DBs” headlines with distance.
The Ecosystem and Its Reception
For an ecosystem only six weeks past launch, things are moving quickly. The specification repository has gathered about 8K stars, and both the launch and v0.2 announcement have HN threads with active debate. One notable third-party tool is the Ruby ecosystem's serradura/okf-gem. It packs authoring through an agent skill, specification validation, linting with CI exit codes, full-text search, knowledge-graph visualization, and even a Claude Code plugin into one gem, running 100% locally.
Many secondary sources summarize the reception as “mostly cynical,” but this verification did not establish individual quotations or the distribution of sentiment. The verifiable point is that the debate centers on the need for a Google-led common standard rather than the format's novelty. I recommend reading the original threads directly: launch and v0.2.
Wrapping Up: Is It Worth Trying Now?
Here is my assessment.
- The adoption cost is effectively zero. If you already write documentation in Markdown, you can start by adding a single
typeline to the frontmatter, with everything versioned in git. Even if the specification is abandoned, what remains is a well-organized Markdown folder. There is nothing to lose. - v0.2's real contribution is standardizing trust metadata. Making the pipeline “AI generates → human verifies → validity period specified” machine-readable through three fields (
generated/verified/stale_after) is a practical design for an era in which agents consume one another's outputs. - But it is still a draft. Fields may change further, just as renames occurred between v0.1 and v0.2. At this stage, applying it experimentally to one knowledge folder read by an agent seems more appropriate than enforcing it as an organizational standard.
Personally, since I already use Claude Code's memory directory and CLAUDE.md, I plan to try the division “CLAUDE.md for behavior, OKF bundles for knowledge” in a side project. I will share a follow-up once results accumulate.
Verification note—Fact-checking for this post is as of 2026-07-29. It reflects a deep-research pipeline that extracted claims from 21 sources and cross-checked the top 25 through a three-vote process, confirming 22 and rejecting 3. Primary sources: OKF SPEC.md · Launch blog post · v0.2 blog post. Since OKF remains a draft, check the original specification again before adopting it.
Comments
Korean and English pages share this conversation.
Loading comments…