Google Cloud maps OKF bundles into Knowledge Catalog

Google Cloud has outlined a way to publish Open Knowledge Format bundles into Knowledge Catalog, with the aim of sharing and governing them across an organisation.

The move links OKF, an open specification for packaging context for AI agents, with Google Cloud's existing metadata catalogue. Under the model, each concept in a bundle is written into Knowledge Catalog as an entry that can be searched, governed and retrieved through the same interfaces used for data assets.

Google has developed OKF in stages. Version 0.1 introduced a portable structure based on markdown files with YAML frontmatter, while version 0.2 added trust signals including provenance, verification, freshness and attestation.

A gap remained around wider distribution inside large organisations. A bundle stored in a Git repository may be portable, but it is not automatically searchable alongside the data it describes, nor does it inherit the same identity and compliance controls used elsewhere in the organisation.

Catalog model

In the proposed setup, an OKF bundle is mapped to native Knowledge Catalog resource types. A one-time configuration step creates three catalog resources: an EntryGroup to hold the bundle, an EntryType called okf-bundle, and an AspectType called okf to carry the structured OKF fields.

After that, a push operation creates one entry for each concept in the bundle. Each concept entry includes an overview aspect for the markdown body and an okf aspect for the structured signals, while the display name, description and tags sit on the entry itself.

Navigation files and log files are also added as entries, preserving a bundle's directory structure inside the catalogue as a browsable hierarchy. Re-running the push process updates existing entries rather than creating duplicates.

The okf aspect schema contains 13 fields covering the current OKF specification, including document type, generation details, source material, verification events, lifecycle status, stale-after dates, usage windows, runtime details, and execution or attestation information for computations.

Some of those fields can be queried directly through Knowledge Catalog search predicates. Top-level scalar values such as okf_type, status and stale_after, along with scalar subfields inside records, can be used in server-side filtering. Array fields still have to be narrowed down by clients after retrieval.

Agent access

The arrangement is designed to fit existing workflows for AI agents that already read from Knowledge Catalog. Search results for an OKF bundle can appear alongside BigQuery tables, files in Cloud Storage, operational databases and application metadata held in the catalogue.

For retrieval, agents can use LookupContext to pull back formatted context for matched entries, then call entries.get with a full view when they need the structured OKF fields. That removes the need to clone repositories, merge metadata manually or parse markdown frontmatter separately.

The access model also stays aligned with existing Identity and Access Management controls. Bundle entries inherit permissions from the EntryGroup, so agents receive only the entries their identity is allowed to read.

Reading agents use the Dataplex Catalog Viewer role for search and retrieval, while the identity used to publish bundles needs the Dataplex Catalog Editor role to create and update entries. Google described one EntryGroup per bundle-owning team as the pattern for organisations with multiple teams.

Sample bundle

To illustrate the process, Google pointed to a synthetic "Acme Retail" bundle covering a US retailer's BigQuery estate. The example contains nine leaf concepts across six directories, plus index and log files, producing 17 pushed entries in total.

In that example, a metric document for revenue becomes a catalogue entry with markdown content in the overview aspect and structured metadata in the okf aspect. That allows an analyst searching for "revenue" to find the business definition alongside the BigQuery table it draws from under a single permission model.

The same structure is intended to help downstream agents. An agent that already queries Knowledge Catalog for table entries can extend its resource list to include the relevant OKF entry names, then retrieve both technical metadata and bundle context through the same APIs.

Operational use

The push process is idempotent, meaning repeated runs do not create duplicate entries, although each run rewrites every entry in the bundle. Deleting individual concepts requires a separate delete action, while removing an entire EntryGroup leaves the shared aspect and entry types available for other bundles.

For production use, Google suggested wiring the publishing step into a continuous integration pipeline so every repository commit triggers a new push into Knowledge Catalog. That would allow teams to keep AI-readable knowledge bundles in step with changes to their governed data environment.

More broadly, Google is trying to place AI context management inside the same metadata and access framework already used for data governance. Rather than keeping machine-readable knowledge in separate repositories, the model brings it into the catalogue layer, where search, lineage and permission controls are already established.

In Google's framing, OKF defines what a trustworthy bundle looks like, while Knowledge Catalog makes it reachable across the organisation.