Google Cloud ships the Open Knowledge Format with four reference implementations: a two-pass producer, a static visualiser, a set of sample bundles, and a serving layer. When we adopted OKF as our export boundary, we committed to mirroring each one on our own material rather than taking the documentation on faith. As of 2026-07-16 all four run. This post walks through what each demo is, what it demonstrates, and what building the last one forced us to decide.
A one-paragraph refresher first. An OKF bundle is a folder of Markdown files. Each file is one concept. The only hard requirement is a non-empty type in the YAML frontmatter; title, description, tags, and timestamp are convention. Links between concepts are plain Markdown links. A resource: field on each concept points at the live system behind the file. That is the entire format, and its poverty is the point of everything below.
The producer and the visualiser
The first demo is the two-pass producer. Pass one is deterministic: a mirror script walks a folder of documents and writes one concept per file, promoting the title and description, mapping the type against our shared vocabulary, hashing the source so re-runs skip unchanged files. No model call, so it is fast, free, and exact. Pass two is a dotprompt, an executable prompt file with an input schema and an output schema, and it runs only on concepts whose deterministic description came out weak, raw meeting transcripts mostly. It writes one faithful sentence about what the document is and why it exists. Determinism where determinism works, model calls only where they earn their cost.
The second demo is the visualiser: one self-contained HTML file per bundle. The D3 library and the graph data are inlined into the file, so the page makes zero network requests and opens offline. You can attach it to an email or commit it to a repo and the graph travels intact. Every graph image in this post is a screenshot of that one file type doing its job.
One format, three shapes
Google ships GA4, Stack Overflow, and Bitcoin sample bundles to show the format carrying different graph structures. The third demo is our version: three bundles from our own work, each built to prove one structural property. Here are their directory trees side by side. Same envelope every time: folders, Markdown files, frontmatter.
The first bundle is a stack-ranking vertical from our K-Pop research corpus: fifteen concepts, twelve of them plain documents, eight weekly brand files plus their scoring and prediction sheets. It renders as one dominant cluster because that is what it is. This is the shape a corpus has when an agent first meets it, one type, structure carried by tags.
The second bundle is a personal persona exported from the DKR ingestion and ontology design process: 164 concepts across 29 types, Person, Organization, Intent, Goal, Methodology, and two dozen more. The 148 edges you see are the bundle's actual Markdown links, the format's native cross-link mechanism. Every concept in this bundle is a Layer 2 projection: it names the entity and its neighbors and nothing else. The typed relationships, the attribute values, and the confidence scores that the source graph carries were stripped at export. Hold that thought for the fourth demo.
The third bundle models value flow with REA semantics, the Resource, Event, Agent grammar from accounting theory. It is a deliberately generic specialty-coffee chain, five agents, three resources, six events, no client data. Every event links its provider agent, its receiver agent, and the resource that moves, which is exactly the give, receive, flow triple a relational database would express as foreign keys. Paired events like purchase and payment link each other to close the exchange. The graph reads as join paths.
Three different structures, one portable format. A flat corpus, a dense typed persona, and a directed economic model all travel in the same envelope, and the envelope is expressive enough to carry structure while staying too poor to carry the deep model. That asymmetry is what makes it a safe export boundary.
The gate
The fourth demo is the one that turns a safety claim into a running system. We say the firewall is the endpoint rather than the format, and OKF encrypts nothing and access-controls nothing, so the claim needs proof you can curl. The demo is a gated Cloudflare Worker serving the persona bundle two ways. The open routes serve the bundle root and every Layer 2 concept to anyone. The rehydration route, the one every concept's resource: field points at, checks for credentials and returns the deep model only to an authorized agent.
An external agent can walk the index, read any concept, follow the links, and build a full picture of what exists. The moment it follows a resource: pointer to get what the graph actually knows, typed edges, attributes, confidence, it gets a 401 with a plain explanation. Protection is three separate mechanisms stacked: a format too poor to leak, an export projection that chooses what ships, and an endpoint that says no. The fourth demo is the third mechanism running in public.
Building it also forced a decision that had been open since the first version of our OKF profile: what scheme the resource: URIs use. We chose a gated Worker URL for now because it runs on infrastructure we already operate and it makes the denial literal. A custom scheme resolved only by our own agents is the production direction once a resolver exists. The same bundle is also served over MCP by a small resource server, and the boundary holds there too: the resource list an MCP client sees is the projection, and the deep model is unreachable through it entirely.
How to apply it. Mirror your reference implementations before you trust them; each of our four demos surfaced a real defect or forced a real decision that reading the spec did not. Prove your graph shapes travel by building the sample bundles, and prove your protection claim by deploying the gate and capturing the denial. The three bundles and the firewall contrast are live, with rebuild recipes in every bundle's README.