Open Knowledge Format (OKF)

A lightweight open standard from Google Cloud (the GoogleCloudPlatform/knowledge-catalog repo) for representing knowledge and metadata as a directory of markdown files with YAML frontmatter — human-readable, agent-parseable, and git-diffable. It is, almost line for line, a vendor-published specification of the llm-wiki substrate this wiki runs on.

The format

Bundle — a self-contained collection of concepts, shipped as a directory, a git repo, or an archive. (This wiki's raw/+wiki/ tree is a bundle.)
Concept — one markdown file per thing, whether a concrete asset (a BigQuery table, an API endpoint) or an abstract idea (a metric, a playbook). The concept ID is the file path minus .md (e.g. tables/users).
Frontmatter — a required type field naming the concept category, plus recommended title, description, resource (a canonical URI), tags, and timestamp. The body is free-form markdown with conventional sections like Schema, Examples, Citations.
Reserved filenames — only index.md (directory listing) and log.md (update history) carry defined meaning. The same two spine files this wiki keeps.
Cross-linking — plain markdown links join concepts; bundle-relative absolute links (leading /) are recommended.

The deliberate omissions are the point

OKF refuses to prescribe a taxonomy, an ontology, central schema registration, or storage/query infrastructure. type values are producer-defined and unregistered ("BigQuery Table," "Playbook"). Relationships emerge from the surrounding prose, not from formal link semantics — there is no typed edge, no triple, no RDF. It explicitly does not replace schema systems like Avro, Protobuf, or OpenAPI; it references them. Google frames the whole thing as "metadata as code" — catalog metadata living beside source code in git rather than in a separate registry.

Why it matters here

This is the strongest corroboration yet that the wiki's core bet is a real attractor, not one author's taste. Counting Karpathy's spec, gbrain's schema packs, tana's supertags, Notion's databases, and this wiki's own schema.org @type model, OKF is the fifth independent arrival at typed markdown pages a machine reads — and the first published by a hyperscaler as a named open standard. The substrate convergence the synthesis tracks (Bush's microfilm desk → a git repo of markdown) now has Google Cloud writing down the file format.

It also sharpens a standing boundary. OKF sits at the anti-formalist pole of knowledge representation: where the semantic-web tradition (RDF/OWL/SHACL — the sibling knowledge-representation wiki) makes relationships machine-checkable triples, OKF leaves them as prose for an LLM to read, betting that a capable model plus minimal structure beats a rigid ontology. That is the same "connection emerges, don't pre-impose categories" instinct behind Luhmann's slip-box and associative-trails, now a design principle for an enterprise data catalog. It is the typed-edge question answered the other way: OKF declines the formal edge on purpose.

Finally it adds a third hyperscaler/vendor data point to the enterprise knowledge-substrate thread — alongside Atlan's context layer and Microsoft's Knowledge-as-a-Service — but from the opposite direction: where those are managed services that hide the substrate, OKF is a plain-files format you own and diff, the llm-wiki/own-your-markdown ethos brought to corporate metadata. The agent-readable angle makes it a near neighbor of model-context-protocol (a way to deliver this knowledge to an agent).

First sighting outside the spec (2026-08-15)

The caveat below has one data point against it now. llm-inference-wiki/okf-token-handoff — a Towards Data Science build-log on passing pre-computed token arrays between LLM agents — uses OKF's markdown-plus-frontmatter shape as the carrier, and the author says plainly that his files are "not valid Google-OKF bundles as-is" because he added a field the spec does not define (token_pointer, a path to a NumPy array in shared memory), conforming "in spirit — same instinct" instead. Read against the omissions above, that is the format working as designed: a producer-defined extension is exactly what a spec with no schema registry and no central authority invites. It is also the weakest possible kind of adoption evidence — one independent developer, borrowing the aesthetic, not the conformance. The source routed to ../llm-inference-wiki, which owns the tokenizer mechanism it actually measures; only this sighting belongs here.

First tool claiming conformance (2026-08-31)

openkb (VectifyAI, Apache-2.0, ~4.2k★) lists OKF compliance as a headline feature and a Recent Update: "Wiki pages follow the Google OKF specification for knowledge sharing." That is a stronger class of evidence than the 2026-08-15 sighting above — a shipped, installed tool rather than one developer borrowing the aesthetic — and it is the first adoption data point of any kind for the spec.

It is also weaker than it sounds, for a reason that is the spec's own design showing through. Nobody has checked an OpenKB bundle against OKF, and there is nothing to check it with: a format that registers no schema, defines no type vocabulary and appoints no authority has, by construction, no conformance suite. OpenKB's frontmatter conventions live in a user-editable wiki/AGENTS.md the README invites you to rewrite, so conformance is a default setting, not a property of the tool. And the two designs would look alike anyway — both are markdown-plus-frontmatter with index.md and log.md spine files, which is what the whole llm-wiki family already does. Adoption of a maximally permissive format is hard to tell apart from convergence in shape. Read it as the first producer to say the word, which is real and is not the same as measured uptake.

Caveats

A specification, not a deployment — the adoption data is one tool's self-asserted claim (above) plus one developer's non-conforming borrowing, and knowledge-catalog is a young repo. The spec is primary and authoritative (T1) for what OKF is; whether it gets used is still substantially unproven.

llm-wiki · llm-wiki-gist · knowledge-graph · ontology · tools-for-thought · enterprise-context-layer · azure-logic-apps-knowledge-service · model-context-protocol · gbrain · zettelkasten · google · openkb