The Open Knowledge Format Evolves: Version 0.2 Introduces Enhanced Trust and Attestation for AI-Driven Data Ecosystems

When the Open Knowledge Format (OKF) was first unveiled in June 2026, the core proposition was clear: the contextual information—table schemas, metric definitions, operational runbooks—essential for intelligent agents should reside in a structured, accessible format, rather than being buried within proprietary systems or scattered across unstructured text. OKF v0.1 embodied this principle with a minimalist approach, leveraging Markdown, YAML frontmatter, and a set of established conventions. The subsequent response from the developer community has been robust, shaping the trajectory for the next iteration, OKF v0.2, which significantly bolsters the format’s capabilities for ensuring trust and accountability in increasingly automated data environments.

The initial release of OKF sparked immediate engagement. Developers proposed extensions, including typed relationship edges for more nuanced data connections, agent-routing hint fields for optimized workflow management, an optional erasure conformance profile for data privacy compliance, and an .okfignore convention akin to .gitignore for managing OKF files. Furthermore, new sample bundles have been contributed, and an ecosystem of OKF-compatible tools developed outside of Google has begun to be cataloged. A recurring theme in this feedback loop, however, has been a fundamental concern: as agents increasingly contribute to and modify the OKF corpus, how can its integrity be maintained and its trustworthiness assured?

This question of trust is particularly acute in the context of dynamic knowledge bases. The most valuable OKF bundles are unlikely to be static, manually authored documents. Instead, they are envisioned as living repositories, continuously updated by agents and consumed by other agents. A human-authored wiki page inherently carries an implicit guarantee of accountability; there is a traceable individual responsible for its content. When an agent can generate thousands of new concepts overnight, this direct human accountability dissolves. Consequently, consumers—often other agents—must be empowered to assess each concept based on explicit signals, necessitating answers to critical questions about its origin, verification status, currency, and the methodology behind any reported values.

OKF v0.2 directly addresses this imperative by enabling all five of these crucial questions to be answered directly from the frontmatter. The format remains remarkably lightweight and non-prescriptive, adhering to the principle of adding vocabulary rather than imposing rigid rules. The type field continues to be the sole mandatory element. All new fields are opt-in, custom keys are preserved rather than rejected, and bundles that adopt none of the new features remain fully valid, just as they were under v0.1. The innovations introduced in v0.2 are optional, but their absence now carries significant meaning. For instance, an unverified concept is now distinctly identifiable from a verified one, although this difference does not lead to outright rejection. This subtle but powerful distinction allows for nuanced filtering and decision-making within data consumption workflows.

From Describing to Deciding: Enhancing Frontmatter Capabilities

The foundational metadata in v0.1, including type, title, description, resource, and tags, served to describe a concept: its nature and its associated data pointers. OKF v0.2 expands this frontmatter functionality by introducing a second category of fields designed to facilitate decision-making about a concept before its full content is accessed. These new fields address critical attributes such as the originator of the information, its verification status, its current validity, and the precise method for computing any reported values.

The strategic placement of these decision-support fields within the frontmatter is deliberate. The vast majority of interactions with a knowledge concept, whether by a human, deterministic code, or an agent performing search and discovery, begin with an assessment of relevance. Before delving into the detailed information within a file’s body, a consumer must first determine if the concept is pertinent to its task. While conciseness is paramount across all OKF content, the frontmatter’s role is even narrower: to surface the precise signals needed for rapid relevance and trustworthiness evaluations. This allows for inexpensive and frequent access to these crucial metadata points, avoiding the token expenditure often associated with parsing prose. The substantive content, requiring deeper inspection, is reserved for the file body, accessed only after a concept has been deemed relevant and trustworthy. This architectural choice allows trust signals to be filtered upon before committing to the full consumption of a concept’s content.

To illustrate these advancements concretely, the following examples draw from a sample OKF v0.2 bundle, acme_retail. This fictional dataset represents the shared knowledge base for a US retail company, designed to facilitate AI-assisted analytics over its BigQuery data.

Provenance: Tracing Origins with Objective Signals

OKF v0.2 introduces the sources field to meticulously record the origins of a concept. This can encompass external documentation, paths relative to the bundle, or even broader scope descriptors like "all queries within project X." Complementing this, each source entry can incorporate objective credibility signals, such as author, usage_count, and last_modified.

A key design choice in OKF is the deliberate omission of a direct "credibility score." Instead, OKF focuses on recording the raw signals, recognizing that a score is inherently subjective, difficult to port across different consumers, and quickly becomes obsolete. Credibility is thus inferred by the consumer, who can dynamically assess these signals to determine trustworthiness. For instance, a heavily used, recently updated source authored by a recognized authority would naturally be deemed more trustworthy than an anonymous, seldom-accessed one. Furthermore, when the body of a concept cites a specific source, it does so using standard Markdown footnotes keyed to the source’s id (e.g., [^export-schema]). This ensures attribution is tied directly to individual claims, rather than relying on a generalized list at the end of the document.

Trust: Establishing Verification Through Distinct Roles

Trust in OKF v0.2 is established through two carefully distinguished fields: generated and verified. This separation is intentional, acknowledging that the individual or agent responsible for creating a piece of information is not necessarily the same entity that confirms its accuracy.

The generated field captures information about the creator, including its agent identifier and the at timestamp of creation. This provides a clear audit trail of who or what produced the knowledge.

The verified field, on the other hand, records the entity that confirmed the concept, along with the at timestamp of verification. This can be a specific agent, such as agent:reference-agent, or a human user, denoted by human:<id>.

From the verified field, a consumer can derive a trust tier. The absence of a verified key signifies an unverified concept. Confirmation solely by machine actors results in a "machine-confirmed" tier, while confirmation by a human:<id> actor elevates the concept to a "human-reviewed" tier. These tiers are advisory signals, not access control mechanisms. However, they empower consumers to implement intelligent filtering, such as displaying only human-reviewed metrics on an executive dashboard, thereby tailoring the presentation of information based on its established level of trust.

In the acme_retail example, the metrics/revenue.md concept is authored by the reference agent and verified by the VP of Finance. This places it in the human-reviewed tier. An executive dashboard configured with a trust-tier filter would surface this metric, while a less stringent testing environment might accept concepts from lower trust tiers.

Freshness and Lifecycle Management: Ensuring Data Currency

OKF v0.2 introduces the stale_after and status fields to manage data freshness and lifecycle. The status field allows concepts to progress through distinct lifecycle stages: draft, stable, and deprecated. The absence of a status field defaults to stable.

The stale_after field utilizes a single absolute date. This choice over a relative Time-To-Live (TTL) ensures that staleness is determined by a straightforward date comparison, independent of when the concept is accessed. This deterministic behavior is particularly valuable for non-LLM consumers that require predictable data validity.

For instance, in acme_retail, both metrics/revenue.md and metrics/gross-margin.md are marked with stale_after: 2026-12-31. This reflects Acme’s practice of re-approving underlying financial policies annually. Consequently, on January 1, 2027, both concepts would require re-verification against the Fiscal Year 2027 policy before they can be reliably used.

Meanwhile, metrics/gross-margin-legacy.md is explicitly marked with status: deprecated. This indicates that Acme revised its cost allocation standard in February 2026, a change that excluded shipping and fulfillment costs from the cost of goods sold in the legacy formula. While the legacy definition is preserved for historical query reproducibility, it is no longer surfaced for new analytical work.

Attestation: Verifying Computation Integrity

Provenance clarifies the origin of a claim. Attestation addresses a more complex and critical question, especially when agents report financial figures: was this number computed according to the sanctioned methodology, or did the agent deviate and improvise its own calculation?

OKF v0.2 introduces a new concept type, Attested Computation. This type goes beyond simply defining what a value means; it specifies a sanctioned method for its computation and provides mechanisms to verify that this sanctioned method was indeed executed. The example acme_retail/computations/revenue-ytd.md illustrates this:

This concept defines the executor (e.g., a Python script that interacts with BigQuery), the parameters the executor must use, and the attester script responsible for validating the computation. The agent is strictly limited to filling the declared parameters; it cannot author or alter the computation logic itself. A consumer then executes the computation via the executor, receiving a receipt containing the BigQuery job_id, the actual SQL executed, and the result. Subsequently, a deterministic, non-LLM attester analyzes this receipt. Its verdict confirms whether the executed query matches the sanctioned computation bound with the claimed parameters, and whether the displayed value aligns with the authoritative source recorded in the receipt. This mechanical verification process ensures that any deviation—such as a rewritten query, a swapped computation file, or a mutated dependency—will cause the attestation check to fail.

In the acme_retail scenario, the attester script, attesters/sql_equality.py, canonicalizes both the sanctioned SQL and the executed SQL. This process involves stripping comments, collapsing whitespace, and uppercasing known keywords. If the canonical forms differ, the attester refuses to return an "ok" verdict. This means that a swapped table name, an added filter, or a dropped JOIN clause will all result in a failed attestation. When the attestation verdict is false, the consumer will refuse to display the computed value.

While the example uses BigQuery and SQL, the attested computation abstraction is designed for broad flexibility. It can encompass invoking semantic models in tools like Looker or AtScale, querying structured knowledge graphs, or even executing arbitrary API calls.

Crucially, OKF records the computation logic and the verification method; it does not execute anything itself. Attestation is also distinct from verification. The verified field confirms that a definition aligns with policy (a slower, document-level check stored within the bundle). Attestation, conversely, confirms that a single execution run produced the value correctly (a per-call, runtime check that is never stored within the bundle). A definition might be stale yet still attest cleanly, while a freshly verified definition still requires attestation on every execution. This dual mechanism ensures both definitional integrity and execution accuracy.

What’s New in OKF v0.2

Consistent with the philosophy of v0.1, the reference implementations provided with v0.2 are deliberately proof-of-concept examples, underscoring that OKF itself imposes no specific implementation requirements. The GitHub repository for OKF is being updated to include:

• Updated Specification: A revised specification document reflecting the new fields and concepts introduced in v0.2.
• Enhanced Sample Bundles: More comprehensive sample bundles, including the acme_retail example, demonstrating the practical application of the new features.
• Reference Implementations: Updated reference implementations for producers and consumers, showcasing how to integrate OKF v0.2 into existing data workflows.

Compatibility and Forward Momentum

OKF v0.2 represents a minor version increment, characterized by additive changes that maintain backward compatibility. Two deliberate renames have been implemented: timestamp has been superseded by generated.at, and the body-level # Citations list has been replaced by the sources field. In both instances, v0.2 consumers are designed to fall back gracefully to the v0.1 forms if encountered. Bundles created with v0.1 will function without modification within a v0.2 environment.

The journey for OKF is far from over. Developers are encouraged to engage with the specification, which remains concise and accessible. The call to action is clear: implement producers that emit trust signals for existing source systems, develop consumers that can filter based on these signals, and experiment with Attested Computation for critical financial or operational definitions. Filing issues, submitting pull requests, and proposing extensions are vital for evolving OKF into a robust lingua franca for automated knowledge management. The strength of such a format lies in the breadth of its adoption and the collective ability of its users to verify each other’s contributions.

The OKF v0.2 specification, along with sample bundles and reference implementations, is available on GitHub at: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf.