Google Cloud has published a method for moving Open Knowledge Format bundles out of git repositories and into Knowledge Catalog, its metadata service, where each concept becomes an indexed entry subject to the same identity and access management rules that already govern BigQuery tables. The post carries an August 27, 2026 dateline and began circulating on August 26. It is the third instalment in a specification that started life in June as a set of markdown conventions.

The mechanics are narrow. The implications are not.

Google Cloud describes Knowledge Catalog as a context engine for agents, and the new documentation explains how an OKF bundle maps onto the catalog's existing object model. The post is credited to Firat Elbey, Group Product Manager for Data Analytics, and Sam McVeety, Tech Lead for Data Analytics. McVeety co-authored the original specification. PPC Land covered the launch of OKF v0.1 on June 12, 2026, a vendor-neutral format built on plain markdown files with YAML frontmatter, carrying one required field and five conventions.

A second release, v0.2, added what the company calls trust signals: provenance, verification, freshness and attestation. According to Google, those fields exist because a bundle written by a machine needs evidence attached before anything downstream can rely on it. The August post identifies the gap that remained after v0.2. A team could publish a trustworthy bundle for its own agents. It had no sanctioned way to share that bundle across an organisation.

The problem with one git repo per bundle

According to Google, a repository holds the format well enough but fails at organisational scale in three specific ways. It cannot be searched alongside the data it describes. It cannot be secured under the same identity and compliance policies that cover everything else. And it does not sit next to the technical metadata - schemas, lineage, ownership - that data teams already work inside.

There is a fourth cost, and it is the operational one. Every downstream agent has to know where each bundle lives. That arrangement works for a handful of bundles and stops working beyond that.

Three resources, two aspects, one push

Setup registers three objects in Knowledge Catalog. An EntryGroup holds the bundle. An EntryType named okf-bundle types its concepts. An AspectType named okf carries the structured signal fields, defined by an okf-aspect.json schema shipped in the sample code.

The push then writes one okf-bundle Entry per concept. Each Entry carries two Aspects. An overview Aspect holds the markdown body, the human-readable text explaining what the concept is. An okf Aspect holds the machine-readable signals that previously lived in YAML frontmatter. Display name, description and tags sit on the Entry itself rather than inside either Aspect.

Navigation files travel too. Each index.md becomes an Entry carrying only the overview Aspect, since index files have no OKF frontmatter. The bundle's root log.md carries both Aspects, with okf_type set to Log.

The split matters more than it looks. An agent that wants provenance no longer parses prose to find it. Both surfaces exist as separate, typed objects on the same record.

Thirteen fields

The okf AspectType covers the full v0.2 specification across thirteen fields. Field one is okf_type, a freeform string naming the document type, with BigQuery Table, Metric and Attested Computation given as examples. Field two, generated, is a record of actor and timestamp for the last meaningful change. Field three, sources, is an array describing the materials a concept derives from, each with an identifier, resource path, title, author, usage count and last-modified stamp.

Field four, verified, records verification events; an actor prefixed human: marks the highest trust tier the format recognises. Field five, status, takes draft, stable or deprecated. Field six, stale_after, is an absolute RFC3339 datetime with an explicit offset, on or after which the content is treated as stale. Field seven, usage_window, bounds the period over which source usage counts were measured.

Five fields describe execution. The runtime field names how an Attested Computation runs, with bigquery given as the example. The parameters array defines typed named holes a caller may fill, and Google states plainly that these are the only surface a caller may vary. The computation field points at a file holding the computation body. The executor record specifies how the computation runs and what evidence it must return. The attester record names deterministic code that takes a receipt and returns a verdict.

The thirteenth field, extra, is a catch-all. It stores producer-defined frontmatter the template does not model, expressed as JSON path and value pairs, so that a round trip through the catalog loses nothing.

What agents can and cannot filter on

Six top-level scalar fields - okf_type, status, stale_after, runtime, computation and extra - drive Knowledge Catalog search predicates directly. A query of the form aspect:acme-analytics.us-central1.okf.okf_type=Metric returns every OKF Metric in scope. Four scalar subfields inside record fields also work as predicates: generated.by, usage_window.from, executor.resource and attester.resource.

Three array fields do not. The sources, verified and parameters arrays are not server-side searchable on their subfields. An agent narrows on those client-side, after fetching the record with entries.get and view=ALL. Google also flags a syntax constraint on datetime-typed fields, where a bare date or a range comparison works and a full RFC3339 timestamp does not.

That distinction is the difference between filtering a catalogue and downloading it first. Anyone building against this needs to know which side of the line a given field sits on.

Counting the Acme Retail bundle

The worked example uses Acme Retail, a synthetic bundle covering a United States retailer's BigQuery estate. It holds nine leaf concepts spread across six directories named attesters, tables, metrics, computations, policies and skills. Each directory carries its own index.md. The bundle root adds an index.md and a log.md.

That arithmetic produces seventeen pushed Entries. Dataplex creates one additional entry alongside them, so a gcloud dataplex entries list command returns eighteen rows. Google states the count explicitly, which is unusual precision for a developer post and useful for anyone estimating what a real bundle will cost in catalog objects.

A new command-line tool handles the write. kcmd, described in the source material as the Metadata-as-Code CLI, reads a bundle from git and creates each concept as an Entry in the target EntryGroup. Concepts are parented to the index above them, so directory structure survives as a browsable hierarchy rather than flattening into an undifferentiated list.

The tool expects what Google calls the Documents Layout: markdown files under a catalog/ subdirectory and a catalog.yaml at the bundle root listing the snapshot's entry and aspect types. The sample setup script generates catalog.yaml from a command-line flag, defaulting to an EntryGroup named okf_demo, so wiring the sample to a different bundle means passing a flag rather than hand-editing configuration.

Retrieval, and its limits

Once pushed, a concept is reachable through the same APIs an agent already uses for cataloged data. The documented flow runs in three steps.

A searchEntries call returns candidate entry names and descriptions, scoped to a project or an organisation, narrowed through query terms including aspect predicates. A LookupContext call on the top few names returns the full concept body as pre-formatted YAML, with a context_budget parameter capping response size; the sample request sets it to 8000. An entries.get call with view=ALL returns the structured OKF signals for filtering or attestation.

LookupContext resolves up to ten entry names per call, within a single location. It does not follow links out of a concept body. An agent that wants a referenced concept has to name it explicitly. Google recommends placing a bundle's EntryGroup in the same location as the data it describes, so both can be fetched in one call.

One limitation is stated flatly: LookupContext does not render custom Aspects. An agent needing the thirteen structured signal fields has to issue entries.get alongside the LookupContext call. Two round trips, not one.

According to the Google Cloud post, the payoff is that the retrieval path involves "no repository clone, no manual Aspect merging, and no re-parse of frontmatter."

Governance is the actual product

Permissions on the EntryGroup use standard Knowledge Catalog identity and access management. Reading agents need roles/dataplex.catalogViewer, which grants entries.get, LookupContext and searchEntries. The identity running kcmd push needs roles/dataplex.catalogEditor, which grants entries.create and entries.patch. Google names one EntryGroup per bundle-owning team as the multi-team pattern, with permissions cascading from the group to its entries.

The consequence is specific. An agent naming both a bundle concept and the BigQuery table it grounds against in a single call receives both, each subject to its own access control list. The response carries only what the caller was already permitted to read. There is no second permission model to maintain, and no scenario in which a knowledge bundle leaks context about data the reader cannot query.

Lifecycle behaviour is conventional. A push is an idempotent upsert, safe to re-run, though every push rewrites every entry. Deleting a concept requires an explicit kcmd delete on the entry, or a cleanup script that removes the whole EntryGroup at once. That cleanup script leaves the shared okf AspectType and okf-bundle EntryType in place for other bundles that reference them. For continuous ingestion, Google points to a continuous integration job triggering kcmd push on every commit, using a service account credential scoped to the target EntryGroup.

A practitioner declines, for now

Marie Haynes, the SEO consultant whose reading of Google's systems PPC Land has tracked since December 2025, posted her assessment on X at 7:49 PM on August 26, 2026. The post had drawn 836 views, two reposts, seven likes and nine bookmarks at capture.

Her framing of the change is that Google is proposing OKF as official infrastructure agents use across a company rather than as a file format. She noted the identity controls, the sample code for a one-time push, the split into overview and okf aspects, and the arrival of kcmd. Then she posed the question the post does not answer: whether this is an enterprise-only proposition, or whether independent builders of OKF bundles have reason to adopt it.

Her provisional answer was negative. "Github is still the way to go for most of our uses," Haynes wrote, adding that she needed to think further and inviting responses. She had posted the day before about Google launching Gemini Enterprise systems for legal and financial work, describing reusable skills carrying domain knowledge and MCP connections to underlying systems.

The hesitation is not trivial. A specification pitched as vendor-neutral now has its most detailed scaling path documented only for one vendor's catalogue, and the practitioners closest to the format are weighing whether that path is for them.

Why this lands on advertising desks

Nothing in the post is an advertising product. The same was true of Google's Managed Agents API update on July 7, 2026, and of the agentic AI framework guideline the company published in November 2025. Infrastructure choices inside Google's agent stack have a habit of turning into plumbing beneath tools that media buyers and publishers eventually touch.

The connection here is context governance, and the advertising industry is arriving at the same problem from a different direction. IAB Tech Lab named its umbrella agentic initiative AAMP on February 26, 2026, covering execution protocols, interoperability standards and an Agent Registry. AAMP 2.3 addressed pricing provenance, stopping agents from inventing numbers they had no source for. Prebid took stewardship of an open-source sales agent on January 29, 2026. Each of those efforts is trying to answer a version of the same question OKF asks: where does an agent get authoritative information, and what proves it is authoritative?

The verified field and its human: prefix answer that question inside a data warehouse. AAMP answers it inside a bid request. The formats differ. The requirement does not.

Cost is the second link. PPC Land documented how Draft Digital collapsed twelve MCP calls into one buyer agent to control token burn, and reported an IAB Europe showcase where a three-agent task ran about twenty-five minutes for roughly fifty euros in token and credit charges. A retrieval design that filters server-side on six scalar fields, instead of returning candidate documents for an agent to read and discard, is a direct answer to that arithmetic. The three unfilterable array fields are where that saving stops.

Third, the format question overlaps with a live search-policy dispute. Model Context Protocol adoption pushed publishers toward machine-legible markdown, and Haynes has previously observed that Google's markdown versions of its developer documentation existed primarily for MCP use rather than search. Yet John Mueller and Microsoft's Fabrice Canel warned in February 2026 against serving separate markdown or JSON pages to crawlers. Knowledge Catalog sidesteps that tension by keeping the markdown private and governed rather than published to the open web, which is a meaningful distinction for any publisher weighing how much of its own knowledge to expose.

What the post does not say

There is no pricing information for Knowledge Catalog storage or query volume attached to OKF entries. There are no adoption figures, no named customers and no benchmark comparing retrieval latency or token cost against reading the same bundle from git. Google gives no guidance on what happens when a bundle exceeds a size at which per-concept entries remain practical, and the entry count it does publish, seventeen, describes a deliberately small synthetic example.

The post also does not address whether any catalogue other than Google's implements equivalent OKF ingestion. OKF was introduced as a specification that requires no proprietary runtime, SDK or commercial relationship. Scaling it, on the evidence published on August 27, currently requires a Google Cloud project, a Dataplex API, and identity management inside that project.

Timeline

  • June 12, 2026 - Google publishes OKF v0.1, a markdown and YAML specification with one required field and five conventions, alongside sample bundles and reference implementations on GitHub
  • OKF v0.2 - adds provenance, verification, freshness and attestation signals for machine-authored bundles
  • June 30, 2026 - date recorded in the sample metric's generated field, attributing authorship to a reference agent running Gemini 2.5 Pro
  • July 1, 2026 - date of the human verification event on the sample revenue metric, signed off by a finance executive against the FY2026 policy
  • August 15, 2026 - creation and update timestamps on the sample Revenue Entry in the published API response
  • August 25, 2026 - Marie Haynes posts about Google launching Gemini Enterprise systems for legal and financial work
  • August 26, 2026, 7:49 PM - Haynes publishes her assessment of the Knowledge Catalog documentation on X, concluding that GitHub remains her preference for most uses
  • August 27, 2026 - dateline on the Google Cloud post documenting OKF ingestion into Knowledge Catalog
  • December 31, 2026 - stale_after value on the sample revenue metric, after which consumers must re-verify against a reissued policy

Summary

Who: Google Cloud, in a post credited to Firat Elbey, Group Product Manager for Data Analytics, and Sam McVeety, Tech Lead for Data Analytics and co-author of the original OKF specification. Marie Haynes, an SEO consultant, published the first substantive practitioner reaction.

What: Documentation and sample code for publishing an Open Knowledge Format bundle into Knowledge Catalog. Setup registers an EntryGroup, an okf-bundle EntryType and an okf AspectType carrying thirteen fields. A push writes one Entry per concept with two Aspects, an overview holding the markdown body and an okf Aspect holding the structured signals. A nine-concept sample bundle produces seventeen entries, with an eighteenth created automatically by Dataplex.

When: The Google Cloud post carries an August 27, 2026 dateline and circulated on August 26, 2026. Haynes posted her assessment at 7:49 PM on August 26. OKF v0.1 was published on June 12, 2026, with v0.2 following before this release.

Where: Sample code sits in the GoogleCloudPlatform/knowledge-catalog repository on GitHub. The runtime is Google Cloud, through the Dataplex API, with retrieval via searchEntries, LookupContext and entries.get. Permissions run through roles/dataplex.catalogViewer for reads and roles/dataplex.catalogEditor for writes.

Why: OKF defined a portable format but left unresolved how bundles are shared and governed across an organisation. A repository per bundle is not searchable next to the data it describes, cannot inherit organisational identity policy, and forces every agent to know where each bundle lives. Mapping bundles onto catalog objects makes them discoverable through calls agents already issue and subject to access controls already in force. The open question, raised by Haynes and unanswered by the post, is whether a specification presented as vendor-neutral now has a scaling path that runs through a single vendor.