Why it fits without adaptation
Enterprise knowledge catalogs are becoming the always-on context layer that unifies a data estate and serves it to agents. Google Cloud's Knowledge Catalog can already ingest the Open Knowledge Format and serve it to Gemini agents. CKS does the work a high-quality OKF producer is assumed to have done, so it meets that contract natively rather than by conversion.
Ingestion parses a source, extracts concepts, claims, and entities, scores trust and validity, and emits a Validity Warrant with provenance, then projects all of that into a conformant OKF bundle. To a catalog, CKS is simply a producer at the near end of the contract. The difference is that a CKS bundle is a high-trust one: it carries trust tier, validity with decay, provenance hashes, a warrant id, and its FrameGraph framing as namespaced extension keys that a permissive consumer preserves and ignores.
The integration vectors
There are two production directions and one serving alignment. They are kept deliberately separate because they differ in effort and in value, and because conflating a quick win with a deeper build helps no one.
| Vector | Direction | What it delivers |
|---|---|---|
| OKF provider | CKS → catalog | CKS bundles ingested and served to agents. Low effort, high signal: publishing and conformance. |
| Partner catalog | CKS → catalog | CKS sources as governed native catalog entries, in unified search, as data products with golden queries. |
| Serving alignment | agents → CKS | Catalog agents call CKS over MCP for the framing, warrants, and causal reasoning the catalog does not perform. |
| Catalog ingestion | any catalog → CKS | CKS enriches its substrate from external catalogs through a provider-agnostic adapter port. |
The governed OKF estate CKS already maintains is published into the catalog as bundles and as native, governed entries, so its trust-tiered, warranted knowledge appears in the enterprise's unified search and governance plane.
External catalogs are ingested through a loosely coupled adapter port, each provider's metadata normalised into OKF, so the substrate is enriched by whatever catalog the institution runs without taking a dependency on it.
CKS into the catalog
Two routes outward, one quick and one deep.
As an OKF provider, the fast path
Publish the OKF bundles CKS already exports to a location the catalog ingests, pin the targeted OKF version, and prove the bundles ingest and serve. Mostly publishing and conformance, almost no new build.
As a first-class partner catalog, the deeper path
Register CKS knowledge as native catalog entries through the metadata import API, with custom entry and aspect types that carry CKS provenance, trust tier, Validity Warrant, entitlement, and FrameGraph frame. Map CKS collections to catalog data products and expose CKS recipes as pre-vetted golden queries.
Catalogs into CKS, vendor-agnostic by requirement
The reverse flow is the part that is built to outlast any single vendor. CKS ingests from an external catalog through a provider-agnostic adapter port: each provider is a swappable adapter behind one internal port, and every adapter normalises its provider's metadata into OKF as the common target. No provider's model leaks into CKS core, which is what keeps the coupling loose.
One port, many adapters
The reverse flow reuses the existing OKF import path and adds one internal port behind which each catalog provider is a pluggable adapter.
OKF as the normaliser
Each provider's metadata is mapped into OKF on the way in, so the substrate sees one schema regardless of where the knowledge came from.
No single-vendor lock-in
Google Cloud's Knowledge Catalog is the first adapter; AWS (Glue Data Catalog, SageMaker Catalog) and Microsoft Fabric (OneLake, Purview) are later adapters that prove the port holds.
Serving alignment: agents reach back into CKS
Publishing into a catalog is not the end of the relationship. CKS exposes retrieval through MCP in line with a catalog's own remote MCP server, so an agent that found CKS knowledge in the catalog can call CKS directly for the things a catalog does not itself perform: the FrameGraph framing, the Validity Warrant, and the causal reasoning behind a premise chain.
The one hard problem: entitlement
The difficulty in publishing a governed estate into a shared catalog is licensed content. CKS imports the full estate and mirrors its entitlement as catalog access policy, so a non-entitled agent is denied licensed content at the point of retrieval, inside the catalog, on the same governed feed. Licensed bodies never leak into a non-entitled response, the same discipline CKS already applies to its own exports.