OKF v0.2 lets agents judge whether a piece of knowledge is worth reading before they read it. The spec is explicit about why it does not store a credibility number: scores are subjective, unportable and go stale.
Summary
Google Cloud has released version 0.2 of the Open Knowledge Format, adding frontmatter fields that signal how trustworthy a knowledge bundle is. The signals sit alongside source entries and cover authorship, usage, recency and the window those measurements cover. The release is additive and backward-compatible, with two renamed fields. Notably, the specification refuses to store a computed credibility score.
Key Takeaways
- OKF v0.2 adds trust signals to knowledge bundle frontmatter
- Signals attach to sources entries and cover authorship, usage, recency and the usage window
- The spec deliberately does not store a computed credibility score
- Google’s reasoning: scores are subjective, unportable and go stale
- Signals sit in frontmatter so consumers can filter before reading the body
- v0.2 is additive and backward-compatible
- timestamp is superseded by generated.at; body # Citations by sources
- The visualizer now shows trust tier, status and staleness
- Contradiction handling and faceted search remain unresolved
What OKF Is
An open standard from Google Cloud for representing enterprise knowledge in a form both humans and AI agents can read.
In practice: markdown files with YAML frontmatter, markdown links forming a graph, one required type field, and no mandatory SDK.
Two terms matter:
- Knowledge Bundle a self-contained, hierarchical collection of knowledge documents. The unit of distribution.
- Concept a single unit of knowledge within a bundle, represented as one markdown document. It may describe a tangible asset such as a table or API, or an abstract one such as a metric or business process.
OKF does not replace domain-specific schemas like Avro, Protobuf or OpenAPI. It references them.
A naming caution: an unrelated supply-chain specification also uses the abbreviation OKF (OKF-SCIS), and the Open Knowledge Foundation is a separate organisation entirely. At least one write-up has already conflated the format with the foundation. Google’s OKF is a data, analytics and agent-knowledge format.
The Signals Added in v0.2
Each signal is optional and attaches to a sources entry.
| Field | What it records | Signal type |
| author | Who or what produced the source | Authority |
| usage_count | How often the resource was exercised — dashboard views, query executions, page reads | Adoption and liveness |
| last_modified | When the source itself last changed (YYYY-MM-DD) | Recency |
| usage_window | A { from, to } date range framing every usage_count | Context for usage |
usage_window is written once as a sibling of sources rather than per-entry.
On the count: the specification documents these fields on source entries, while the release also surfaces trust tier, status and staleness in its visualizer. Anyone publishing an exact number of new signals should check the current spec directly, since the fields and the derived indicators are described separately.
One important distinction: last_modified records when the source changed. generated.at records when the concept was written. Those are different questions and the spec keeps them apart deliberately.
The Design Decision Worth Reading
The spec explicitly declines to store a credibility score.
Its reasoning, quoted from the specification:
“It does not store a credibility score: a score is subjective, unportable across consumers, and goes stale. Credibility is inferred from the signals, the same way trust tiers are.”
That is a genuinely considered choice and it is unusual. The obvious product decision would be to compute a number, display it, and let consumers sort by it. Google’s argument is that any such number encodes one organisation’s weighting of authority against recency against adoption — and that weighting will not transfer to another organisation, another agent, or the same bundle six months later.
So the format ships the inputs and leaves the judgement to the consumer.
The trade-off is real. Raw signals are more honest and less convenient. Every consuming system now has to decide for itself how to weigh a highly-used but stale source against a fresh one nobody has touched.
Why the Signals Live in Frontmatter
Because most interactions with a concept never reach the body of the document.
Google’s stated reasoning is that a consumer human, deterministic code, or an agent scanning during search and discovery first has to decide whether a concept is relevant at all. Frontmatter exists to elevate exactly the signals needed for that decision, cheaply and repeatedly, without spending tokens on prose.
The content that must be read in full stays in the body, accessed only once a concept has been chosen.
The line that captures it: “Trust becomes something you can filter on before you commit to reading.”
For anyone building agent systems, that is the practical point. Token cost scales with how much an agent must read to discover something is irrelevant. Putting trust indicators in frontmatter turns a read-then-discard cycle into a filter.
What Else Changed
v0.2 is a minor version bump — additive and backward-compatible — with two deliberate renames:
| Old | New |
| timestamp | generated.at |
| Body # Citations list | sources |
A v0.2 consumer can fall back to the earlier form in both cases.
Also shipped:
- The static visualizer now surfaces trust tier, status and staleness alongside the concept graph, so the signals are visible rather than only parseable
- Updated sample bundles GA4 e-commerce, Stack Overflow, Bitcoin, and a new acme_retail example modelling a fictional US retailer’s shared knowledge for AI-assisted analytics over BigQuery
- A Knowledge Catalog demo showing a bundle round-tripping through Google Cloud’s Knowledge Catalog, formerly Dataplex, with trust and provenance signals preserved through the catalog and back
Where This Came From
Google described v0.1 as a starting point rather than a finished standard, and named trust tiers as open design space.
The v0.1 release addressed interoperability first. Contradiction semantics, trust tiers and typed relationships were explicitly left unresolved, with Google stating that community feedback would shape v0.2.
Trust signals were therefore a stated gap that has now been partly filled. Other open items from v0.1 remain:
- Contradiction handling — when two OKF documents disagree, there are no merge semantics
- Faceted search — some practitioners want richer tagging than the minimal spec provides
- Live versus static — OKF is file-based, so stale documents are a process problem rather than a format one
That last point is interesting alongside v0.2. Recency signals help a consumer detect staleness. They do nothing to prevent it.
Why Google Publishes This Openly
The stated goal is interoperability rather than lock-in, and there is precedent.
By publishing as an open specification rather than a proprietary format, Google is following the pattern it used with Schema.org — a structured data vocabulary jointly maintained with Microsoft, Yahoo and Yandex.
The commercial logic is straightforward. Google Cloud’s Knowledge Catalog consumes OKF, and a format widely adopted across the industry drives more knowledge into systems Google can serve. An open standard that everyone writes to is more valuable to the largest consumer of it than a proprietary one nobody else adopts.
That does not make the openness insincere. It makes it aligned.
Frequently Asked Questions
What is the Open Knowledge Format?
An open specification from Google Cloud for representing enterprise knowledge as markdown documents with YAML frontmatter, using markdown links to form a graph. It is designed to be readable by both humans and AI agents.
What did version 0.2 add?
Frontmatter fields signalling trustworthiness, attached to source entries. These cover who produced a source, how often it has been used, when it last changed, and the date window those usage figures cover.
Does OKF include a trust score?
No, deliberately. The specification states that a credibility score is subjective, unportable across consumers and goes stale, so credibility is inferred from the underlying signals rather than stored as a number.
Why are trust signals in frontmatter rather than the document body?
Because most interactions never reach the body. Consumers first decide whether a concept is relevant at all, and frontmatter allows that decision to be made cheaply without processing the full text.
Is v0.2 backward compatible?
Yes. It is described as an additive minor version bump. Two fields were renamed timestamp to generated.at, and the body # Citations list to sources and consumers can fall back to the earlier forms.
What is a Knowledge Bundle?
A self-contained, hierarchical collection of knowledge documents, and the unit of distribution in OKF. Within a bundle, each individual markdown document representing one unit of knowledge is called a concept.
What still is not solved?
Contradiction handling between documents that disagree, faceted search beyond the minimal tagging spec, and the fact that OKF is file-based, meaning stale documents remain a process problem rather than something the format prevents.
Is this the same as the Open Knowledge Foundation?
No. The Open Knowledge Foundation is a separate organisation, and an unrelated supply-chain specification also uses the OKF abbreviation. Google’s OKF is a data, analytics and agent-knowledge format.
Conclusion
The addition worth noting is not the fields. It is the refusal.
Google could have shipped a credibility score, and most products would have. The specification argues instead that any single number encodes one organisation’s weighting of authority against freshness against usage, and that weighting does not survive contact with a different consumer or a later date.
So OKF publishes the evidence and declines to render the verdict. That is a harder standard to build against and a more durable one which is roughly the argument for open specifications generally.
