Google OKF: A Knowledge Format, Not an AI Search Play

A reader pinged me the morning Google's OKF news hit: "Is this the new thing we have to optimize for?" Fair question - it shipped with "open," "knowledge," and a Google logo on it, which is enough to make any GEO person twitchy. So I read the spec and the repo instead of the headlines. Short version: OKF is a developer format, not an AI-visibility lever. Google shipped v0.2 on July 24, 2026 and it does not change that - it just makes the format more interesting. The longer version is where it gets useful.

What OKF actually is

On June 12, 2026 Google Cloud published the Open Knowledge Format (OKF) v0.1. In their own words it is "a directory of markdown files with YAML frontmatter." No SDK, no runtime, no proprietary platform. A bundle lives in a git repo or a tarball. On July 24, 2026 they shipped v0.2, an additive, backward-compatible bump - a v0.1 bundle still drops in unchanged.

The spec is deliberately tiny. OKF "requires exactly one thing of every concept: a type field." The core queryable frontmatter stays small - type, title, description, resource, and tags - plus optional index.md files for navigation and log.md files for change history. v0.2 renamed the old timestamp field to generated.at and moved body citations into a sources block, both with fallbacks so older bundles keep working.

It ships under Apache 2.0 with two reference implementations - an enrichment agent that produces bundles (built on Google's Agent Development Kit) and an HTML visualizer that consumes them - plus sample bundles: GA4 e-commerce, Stack Overflow, Bitcoin public datasets, and a new fictional retail bundle in v0.2. Press coverage framed it as formalizing Andrej Karpathy's "LLM-wiki" idea into a portable spec.

What OKF v0.2 added: trust and provenance signals

The v0.2 update answers the one question an agent has to ask before it leans on a bundle: where did this come from, and can I rely on it? Six weeks of agents writing into these bundles surfaced the gap. The new fields:

• sources - what a concept derives from, with credibility signals like author, usage count, and last-modified date.
• generated and verified - who or what produced the content and when, plus a list of independent confirmations, human or machine.
• status and stale_after - a lifecycle (draft, stable, deprecated) and an absolute date when a concept needs re-verification.
• an Attested Computation type - lets an agent confirm a number was computed the sanctioned way, not made up.

Read the theme there: freshness, provenance, verification. That is a trust layer, and it is pointed at your own agents deciding whether to believe your internal data - not at a public engine deciding whether to cite you.

The problem OKF solves, and the one it doesn't

Google is explicit about the target: the "fragmented context landscape" inside an organization. Most of what your AI agents need is internal knowledge - what a metric means, how a table is built, which API got deprecated - scattered across incompatible systems. OKF is a common wrapper so any agent can read any team's wiki without a custom integration.

Read that again. The producer is your data team. The consumer is your own agent. The content is internal. None of that is a public AI engine deciding whether to cite your storefront.

OKF vs AI visibility - two different jobs

This is the same shape as the llms.txt confusion I wrote about. A machine-readable file shows up, everyone assumes it's a ranking signal, and it turns out to solve a different problem entirely. OKF is wayfinding for your own agents, not a citation channel for Perplexity or AI Overviews.

Does OKF have any AI-visibility angle?

Yes, but it's directional, not tactical. The bet underneath OKF is the same bet underneath everything in our 50+ brand audits: machines read structured, declarative, markdown-shaped content far better than they read your div soup. v0.2 sharpens the point - Google is now institutionalizing not just "write it down cleanly for the machine" but "prove it's fresh and sourced." Those are the exact signals public AI engines weigh when they decide what to cite. Same instinct, different arena.

Two implications, no hype:

• If publishers ever ship public OKF bundles, agents could ingest your knowledge directly instead of scraping a page - and with v0.2 they could weigh its freshness and provenance too. That's a possible future consumption surface, not a 2026 ranking factor - nothing in the spec mentions web publishing or citation.
• Internally, OKF is a clean way to give your own support or merchandising agents accurate, verifiable context. Useful - just not the same thing as getting found in a public AI answer.

3 rules to use for OKF and your GEO roadmap

1. Don't reprioritize your GEO roadmap for it. OKF changes nothing about how ChatGPT, Perplexity, or Google AI Overviews cite you today. Keep shipping complete Product and FAQ schema - that's still the lever our audits confirm. See our Product schema guide.
2. Watch it if you build internal agents. If you're standing up a support or analytics agent, OKF is a genuinely good, free, lock-in-free way to feed it context - and v0.2's trust fields make that context auditable. Start from the sample bundles in the repo rather than from scratch.
3. Treat it as a signal, not a task. The direction is clear: Google keeps betting on clean, machine-readable content, and with v0.2, on content that can prove where it came from and when. The site that already writes for machines, and keeps its facts fresh and sourced, wins both games - the internal one and the public one.

Want to know whether public AI engines can actually read and cite your store right now - the question OKF does not answer? Run GEOlikeaPro's Visibility Vitals checker and start with your schema.