OKF and the LLM Wiki pattern: the format that decides whether AI will cite your company

I have been running marketing for an industrial technology company for a few years, and the part of my job that has changed most over the last eighteen months wasn’t writing content. It was understanding what format that content needs to exist in for an AI system to be able to use it as a source. Most companies I know still treat this as a technical detail for the IT team. It isn’t. The format in which you publish your technical knowledge determines, in practice, whether ChatGPT, Gemini, Claude or Perplexity will cite your company or ignore it.

In June 2026, Google Cloud published an open specification called Open Knowledge Format, or OKF, which puts a name and rules on something that had been happening informally for a while: the pattern many people already called the “LLM Wiki.” For those working in GEO (optimizing content to be cited by generative engines), OKF isn’t just another trendy acronym. It is the first serious attempt to standardize how knowledge should be structured to be consumed by AI agents. And that changes the conversation about citation strategy.

This article explains what OKF is, how it relates to the LLM Wiki pattern, and why it’s worth watching closely as a strategy for getting cited by AI, with a focus on those who need to turn technical expertise into authority recognized by machines.

What the Open Knowledge Format is

The Open Knowledge Format is an open specification published by Google Cloud, in the knowledge-catalog repository, for representing knowledge in a way that is, at the same time, readable by humans without special tools and parseable by AI agents without proprietary SDKs. The current version is v0.1.

The central idea is deliberately simple. An OKF knowledge base is a directory of Markdown files with a YAML metadata header. There’s no database, no binary format, no mandatory API. If you can open a text file, you can read OKF. The spec itself sums up the format’s goal in a sentence worth keeping: knowledge “written by people, generated by agents, exchanged between organizations and consumed by both.”

Four properties define the format:

Human-readable, without dedicated software.
Parseable by AI agents, without custom integrations.
Versionable in Git, meaning with traceable history and diffs.
Portable across tools, organizations and over time.

Notice what this solves. Most of an industrial company’s technical knowledge today lives in closed PDFs, spreadsheets, presentations and internal repositories. That material is unreadable to a language model at the moment it needs to answer a question. OKF proposes a format in which the same document serves the engineer reading it and the agent extracting from it, with no duplicate version and no loss of context.

The connection with the LLM Wiki pattern

Before Google Cloud published the spec, several teams were already organizing the knowledge they wanted to expose to agents in interlinked Markdown repositories, with metadata headers and internal links. This informal pattern became known as the “LLM Wiki”: a wiki designed not for the human reader of an intranet, but to be navigated and maintained by language models.

OKF is the specified version of that pattern. It’s the difference between everyone writing letters with the address in different places on the envelope and having a postal standard that says where the recipient goes. The LLM Wiki pattern said “organize your knowledge in structured Markdown for AI.” OKF says exactly which fields are mandatory, which files have a reserved function, how links should be written and what makes a set of documents formally compliant.

That formalization matters for a practical reason. When there is a specification, different tools, agents and organizations can assume the same conventions without agreeing on anything in advance. That’s what allows knowledge to be “exchanged between organizations,” as the spec puts it. An agent that understands OKF can navigate the knowledge of any company that publishes in that format, just as a browser renders any site that follows HTML.

Anyone who uses Obsidian, Notion or any Markdown base with internal links is, in practice, one step away from OKF. The format is compatible with these tools because it uses the same foundation: text files and links. The difference is the metadata discipline and the folder structure.

The most useful concept for understanding why OKF is a citation strategy, and not just an organizational one, is what the format’s documentation calls Semantic Unbaking.

In today’s dominant model, RAG (Retrieval-Augmented Generation), the AI agent receives the question and goes digging through a mountain of raw, disorganized context at answer time, trying to guess how to synthesize an answer from scattered fragments. It’s prospecting done in a hurry, at the very moment the user is waiting.

OKF flips this. Instead of letting the agent synthesize scattered context on the spot, you deliver the knowledge already “pre-digested” in modules the agent can use immediately. Each concept is a self-contained unit, with its declared type, its summary and its internal structure. The organizing work was done beforehand, by someone who knows the subject, and not improvised by the model at query time.

For GEO, the implication is direct and it’s the same thesis I defend in my article on GEO in industrial marketing: content structured in a machine-readable way has a much higher probability of being cited than the same content in loose prose or in a closed PDF. OKF is the most explicit expression of that principle. A document that arrives already “unbaked” for the agent requires less interpretation effort, and the model tends to prefer, as a source, whatever it can extract with more confidence.

The anatomy of an OKF document, piece by piece

It’s worth understanding the structure, because each part of it maps to a signal the agent uses when deciding whether or not to cite.

Bundle, Concept and Concept ID

The unit of distribution is the Bundle: a directory of Markdown files organized in a hierarchy. Each .md file is a Concept, a single unit of knowledge. And each concept has a Concept ID, which is simply the file path without the .md extension. A file at tables/orders.md has the ID tables/orders. That ID works as the concept’s key within the knowledge graph.

The two halves of each file

Every OKF document is split into two parts with different audiences:

Component	Format	Function	Primary audience
Frontmatter	YAML	Metadata: type, title, summary, date	Agents, for routing and filtering
Body	Markdown	The knowledge itself, with structure	Humans and agents

The frontmatter sits at the top of the file, between --- delimiters. It’s the document’s control panel. Without it, the agent reads the prose “blind,” without knowing whether it’s facing a procedure to follow, a metric to look up or a product specification.

The only mandatory field is type. It identifies the concept’s type and is what weighs most in routing: it tells the agent “what kind of thing” it’s handling, such as Playbook, Metric, Reference or BigQuery Table. There’s no central registry of types; the spec recommends using descriptive values and being permissive with unknown types.

Then come the recommended fields, in order of priority: title (readable name), description (one-sentence summary, used in indexes and snippets), resource (the canonical URI of the underlying asset), tags (cross-categorization) and timestamp (date of last change).

---
type: BigQuery Table
title: Orders
description: One row per order completed by the customer.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders]
timestamp: 2026-06-20T00:00:00Z
---

The body is everything after the frontmatter, and the recommendation is clear: prefer structural Markdown, with tables, lists, headings and code blocks, over running prose. Structure creates “anchors” that let the agent extract the knowledge precisely. The spec suggests three conventional headings: # Schema to describe fields and columns, # Examples for concrete examples in code blocks, and # Citations for the external sources backing the document’s claims.

That # Citations section is the one that matters most for anyone thinking about GEO. It formalizes provenance: every verifiable claim points to the source that supports it. That’s exactly the trustworthiness signal models use to decide whether a source is citable.

Cross-linking: knowledge becomes a graph

Links between concepts are the edges of the knowledge graph. The spec recommends using bundle-relative absolute links, starting with /, because they stay stable even when a document is moved to another subdirectory.

See the [customers table](/tables/customers.md) for the join key.

An important detail: the semantics of the relationship, whether one concept “depends on,” “joins with” or “references” another, is expressed in the prose around the link, not in the link itself. And broken links are tolerated, because they represent knowledge not yet written. The format was designed to evolve, not to lock up when it’s incomplete.

Reserved files: index.md and log.md

Two file names have a reserved function. index.md is the directory listing and enables what the spec calls “progressive disclosure”: the agent sees what’s available before opening each document, which makes navigation efficient. log.md is the change history, in reverse chronological order, and it’s what allows an agent to keep the base up to date like a librarian, knowing what changed and when.

There is one exception: the index.md at the bundle root may have frontmatter, exclusively to declare the version with okf_version: "0.1".

Why OKF is a citation strategy, not just knowledge management

Here is the central point for anyone thinking about marketing and GEO. OKF was designed around the question “how does an AI agent best consume knowledge?” That means the format already embeds, by construction, almost every signal we know increases the probability of citation.

Think of the tactics that the GEO paper by Princeton and partners, presented at KDD 2024, measured as most effective for increasing visibility in AI answers: referencing credible sources, attributed data, readability and clear structure, authoritative voice. OKF operationalizes each of them as part of the standard. The # Citations section is source attribution. type and description are readability and routing. The preference for tables and lists is extractable structure. The link graph is connected topical authority.

There’s also an effect that speaks directly to the logic of industrial GEO. GEO research shows that brand mentions and the density of verifiable information weigh more than raw content volume. In a technical niche where AI has few quality sources, what I’ve called a thin source pool, publishing knowledge in OKF format means handing the model exactly the kind of source it prefers and rarely finds: structured, dated, attributed and easy to extract. A scarcity of good sources combined with a format designed for the agent is a hard combination to lose.

There’s also the discovery layer. To signal to external agents which resources are accessible, the spec mentions the llms.txt file at the root, an emerging convention that works like a “robots.txt for LLMs,” pointing to what’s available for consumption by models. Publishing an OKF bundle and signaling it via llms.txt makes your knowledge explicitly available to be cited.

How to apply this in the industrial B2B context

For an industrial company, the practical application is less about creating new content and more about giving shape to what already exists. Datasheets, installation manuals, technical bulletins, field application studies and notes on certifications (ATEX, SIL, IECEx, NR-13) are exactly the kind of material dense in verifiable information that OKF was made to carry.

The implementation path that makes sense is gradual:

Start with the material you already have. Select the highest-value technical documentation that currently lives trapped in PDFs. Each document becomes a concept, a Markdown file with frontmatter.
Declare the type of each piece. A selection guide is a Selection Guide. A certification page is a Certification. A case study is a Case Study. That label is what guides the agent’s routing.
Rewrite the body as structure, not catalog prose. Specifications in tables, selection criteria in lists, examples in blocks. The answer to the most likely question for that section should appear right at its start.
Add the # Citations section. ABNT standard, IEC publication, certification body documentation. Attribution on the same page is a verifiable E-E-A-T signal.
Connect concepts with absolute links. A transmitter selection guide points to the certification page, which points to the case study. The knowledge graph of your technical expertise starts to exist in a navigable form.
Keep a log.md and signal with llms.txt. The history keeps the base trustworthy over time, and the access signal makes it discoverable by agents.

The point I insist on with any industrial marketing team is this: identified authorship is still the primary filter. A technically perfect OKF bundle, but with content signed by “editorial team,” loses to content with a simpler structure signed by an engineer with verifiable credentials. The frontmatter freely accepts extra fields, so include the author and their credentials. The format provides the structure; human provenance provides the trust.

Compliance: the minimum checklist

The spec defines that a bundle is compliant with OKF v0.1 if it meets three objective conditions:

Every non-reserved .md file has a parseable YAML frontmatter block.
Every frontmatter has a non-empty type field.
The index.md and log.md files follow their defined structures.

And a fourth rule, more philosophy than condition: consumers should be permissive. An agent reading OKF shouldn’t fail when facing an unknown type, a missing optional field or a broken link. Everything beyond the three conditions is “light guidance,” not obligation. That permissive design is what lets the knowledge base grow organically, without every document needing to be perfect to be useful.

Where this fits in your citation strategy

OKF is still v0.1 and the tool ecosystem around it is just emerging. It isn’t reasonable to treat it as an immediate obligation for every company. But it is reasonable, and in my reading advisable, to watch it as the direction in which structuring knowledge for AI is heading, with the weight of having been published by Google Cloud.

The way to act now isn’t to redo the whole website in the format. It’s to start thinking of your technical knowledge as a base of interlinked concepts, with metadata, attribution and machine-readable structure, instead of loose pages written only for the human reader. Those who already organize content this way will have little work to do to become formally compliant when the format matures. Those who keep publishing technical expertise locked in PDFs will remain invisible to the agents that, more and more, decide which supplier makes it into the answer before the buyer opens the first email.

Your company’s real technical knowledge is the asset. OKF and the LLM Wiki pattern are the way to make it citable. The window to occupy this space, especially in technical niches with few good sources, is open now.