Open Knowledge format v0.2 tackles agentic trust Google Cloud introduced version 0.2 of the Open Knowledge Format (OKF) on Wednesday, adding optional frontmatter fields for provenance, trust, freshness, lifecycle, and attestation to address agentic trust concerns. The update allows consumers—whether humans or agents—to filter concepts on trustworthiness before reading the body, while remaining backward-compatible with v0.1. The new fields are opt-in, and their absence now carries meaning, distinguishing unverified concepts from verified ones. When we introduced the Open Knowledge Format https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing OKF in June 2026, we asserted that the context that agents need table schemas, metric definitions, runbooks should live in a format, not in a proprietary service, and not scattered across unstructured text blobs. Accordingly, OKF v0.1 started simple: just markdown, YAML frontmatter, and a handful of conventions. The strong response and contributions from the developer community informed our focus for the next version. Since launch, contributors opened extension proposals typed relationship edges, agent-routing hint fields, an optional erasure conformance profile, an .okfignore convention, and more , sent new sample bundles, and begun cataloging OKF ecosystem tools built outside Google. Many of these contributions and contributor feedback reflected a larger concern about OKF: once agents are writing to the corpus, can it really be trusted? The most valuable OKF bundles won't be written by hand once and then read forever. They're written continuously, by agents, and consumed by a different set of agents. A human-authored wiki page comes with an implicit guarantee: a person wrote it, and you can hold them accountable if it is wrong. When an agent generates ten thousand concepts overnight, that guarantee is gone. To provide accountability, a consumer often another agent has to judge each concept on explicit signals instead, and needs to answer five questions: What was this created from? provenance How much should I trust it? trust Is it still true? freshness Is it the current version? lifecycle Was this number produced the way we said it must be? attestation In OKF v0.2, it is now possible to answer all five of those questions from frontmatter, while the format remains as minimally opinionated as v0.1. It adds vocabulary, not rules: type is still the only always-required field, every new field is opt-in, custom keys are still preserved rather than rejected, and a bundle that adopts none of the additions is exactly as valid as it was under v0.1. Everything new below is optional, but its absence now carries meaning: an unverified concept is distinguishable from a verified one although never rejected for the difference . v0.1 already kept metadata in frontmatter: type , title , description , resource , tags . Those fields describe a concept: what it is and what it points at. v0.2 adds a second kind of frontmatter field, the kind you use to decide something about a concept before you read it: who produced it, whether it has been verified, whether it is still current, and how a value it reports should be computed. The reason these fields belong in frontmatter is that most interactions with a concept never actually progress to accessing the information in the body of the file. A consumer, whether a person, deterministic code, or an agent scanning during search and discovery, first has to decide whether a concept is relevant at all. Everything in a concept should be concise, but frontmatter has the narrower job of elevating exactly the signals needed to make decisions about relevance and trustworthiness, so it can be made cheaply and often, without spending tokens on prose. The content that must be read in full stays in the body, accessed only once a concept is chosen. Trust becomes something you can filter on before you commit to reading. To make the sections that follow concrete, every example below draws from a small OKF v0.2 bundle we've prepared as a companion to this post: acme retail, a fictional US retail company's shared knowledge for AI-assisted analytics over BigQuery: Each section that follows shows the corresponding file. Here is tables/orders.md, a concept carrying the new signals: Each of those families answers one of the five questions. The new sources field records the materials a concept derives from: an external doc, a bundle-relative path, or even a scope descriptor like "all queries in project X." At the same time, an entry can carry objective credibility signals : author , usage count , last modified . The deliberate choice here is what we didn't add. OKF records the signals, not a credibility score. A score is subjective, doesn't port across consumers, and goes stale the moment it's written. Instead, credibility is inferred from the signals by whoever is consuming and can be dynamically scored by the consumer, if desired , the same way you'd trust a heavily used, recently updated, authoritatively authored source more than an anonymous one. And when the body cites a specific source, it does so with an ordinary markdown footnote keyed to the source id ^export-schema , so attribution is per-claim instead of a dangling list at the bottom. generated , verified Trust is established using two fields, kept deliberately distinct, because who wrote something need not be who confirmed it: generated: { by, at } : how the current content was produced, and when it last meaningfully changed. verified: { by, at } : a list of independent confirmations against the sources or the underlying resource; a human sign-off, a nightly finance process, or both. From verified , a consumer derives a trust tier : no verified key is unverified; confirmation by machine actors only is machine-confirmed; confirmation by a human: