Am Abend des 16. Juni 2026 postete das Google Cloud Tech Account einen einzigen Tweet, der 117.000 Aufrufe, 1.800 Likes und 1.800 Bookmarks in 24 Stunden generierte, die höchste Engagement-Zahl einer Wissensformat-Ankündigung des Jahres, und zwar um Größenordnungen. Der Tweet stellte das Open Knowledge Format (OKF) vor, eine offene Spezifikation, die 'das LLM-Wiki-Pattern in ein portables, interoperables Format formalisiert'. Der Post verwies auf die Spezifikation auf GitHub und auf einen Blog-Post auf cloud.google.com von Sam McVeety (Tech Lead, Data Analytics) und Amir Hormati (Tech Lead, BigQuery). Der Blog-Post war vier Tage vor dem Tweet veröffentlicht worden, am 12. Juni, demselben Tag, an dem die Referenzimplementierung erstmals ins GoogleCloudPlatform/knowledge-catalog-Repository gepusht worden war.
@GoogleCloudTech - 22:34 · 16 juin 2026
Introducing the Open Knowledge Format (OKF), an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format. AI is only as smart as the context we give it. As we build more advanced, agentic AI systems, they need accurate metadata and context to organizations, that context is locked inside fragmented data catalogs, isolated wikis, scattered code comments, or the minds of senior engineers. Every time a new AI agent is built, teams are forced to solve the exact same context-assembly problem from scratch.
To solve this, we've announced OKF, a vendor-neutral, open specification that formalizes the "LLM-wiki pattern" into a portable, interoperable format. It provides a standardized way to represent the enterprise knowledge that modern AI systems rely on.
— Just markdown: readable in any editor, renderable on GitHub, indexable by any search tool — Just files: shippable as a tarball, hostable in any git repo, mountable on any filesystem — Just YAML frontmatter: for the small set of structured fields that need to be queryable: type, title, description, resource, tags, and timestamp
We've also shipped reference implementations to help you hit the ground running, including an enrichment agent for BigQuery, a static HTML visualizer, and live sample bundles on GitHub.
Die Substanz der Ankündigung lässt sich am besten als vier distinkte Bewegungen verstehen: die Spezifikation selbst, die Referenzimplementierungen, die BigQuery-Integration und der Positionierungs-Move. Jeder erfüllt eine andere Aufgabe. Die Spezifikation ist ein 1.000-Zeilen-Dokument, das ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter, ein einziges Pflichtfeld und zwei reservierte Dateinamen definiert. Die Referenzimplementierungen sind drei Artefakte: ein BigQuery-Enrichment-Agent, ein statischer HTML-Visualizer und drei Beispiel-Bundles. Die BigQuery-Integration ist ein nativer Ingest-Pfad im Knowledge Catalog, der ein OKF-Bundle in eine abfragbare, agent-bedienbare Oberfläche verwandelt. Der Positionierungs-Move ist die Behauptung, dass das LLM-Wiki-Pattern eine Kategorie ist, kein One-off, und dass das Format der Beitrag ist, nicht das Tooling.
Die Framing-Korrektur, in einem Absatz
Das Framing, das von Anfang an klar gemacht werden muss, ist, dass OKF ein Format ist, kein Produkt, und dass die häufigste Fehlinterpretation der Ankündigung darin besteht, sie als Google-Cloud-Produkt-Launch zu behandeln. Der Spezifikationstext erwähnt weder BigQuery noch Gemini noch irgendein Google-Produkt. Die Referenzimplementierungen werden im README bewusst 'Proofs of Concept' genannt, und der Abschnitt 'Relationship to other formats' (SPEC.md §10) ist explizit: OKF liegt stromabwärts von Patterns, die die Community seit mindestens einem Jahr baut: Karpathys LLM-Wiki-Gist, Obsidian-Vaults, die mit Coding-Agents verdrahtet sind, die AGENTS.md- und CLAUDE.md-Familie der Konventionsdateien und die 'Metadata-as-Code'-Repositories in Data-Teams. Was Google getan hat, in der saubersten Lesart, ist den kleinen Satz von Konventionen festzulegen, der es diesen Instanzen erlaubt zu kooperieren, die Festlegung unter Apache-2.0 zu veröffentlichen und eine Referenzimplementierung pro Ende der Produzent/Konsument-Achse auszuliefern. Die Lock-in-Frage ist genau die, die die Spezifikation auflösen will.
Das Korollar ist der Teil, der für Builder zählt. Wenn OKF zur Lingua Franca wird, wird der BigQuery-Knowledge-Catalog zum natürlichen Ingestionsziel für jedes Team, das bereits BigQuery nutzt, und das ist der größte Teil des Cloud-Data-Marktes. Das ist der strategische Move, und das Open-Spec-Framing ist die Art, wie der Move gemacht wird, ohne die Art von regulatorischer und kompetitiver Prüfung auszulösen, die ein geschlossener Produkt-Launch einladen würde. Das Format ist der Beitrag, und das Format ist auch der Keil.
Die Spezifikation, auf einem Bildschirm
Die v0.1-Spezifikation, SPEC.md im Repository, umfasst ungefähr 1.000 Zeilen Markdown mit 11 Abschnitten, einem Konformitäts-Appendix und einem einzigen minimalen Beispiel-Bundle. Die Struktur eines Bundles ist der Teil, der alles andere verankert, und sie ist klein genug, um vollständig reproduziert zu werden:
sales/
├── index.md # Optional. Verzeichnis-Listing für Progressive Disclosure.
├── log.md # Optional. Chronologische Update-Historie.
├── <concept>.md # Ein Konzept auf der Bundle-Wurzel.
└── <subdirectory>/ # Unterverzeichnisse organisieren Konzepte in Gruppen.
├── index.md
├── <concept>.md
└── <subdirectory>/
└── …
Ein Bundle ist eine Verzeichnisstruktur. Die Verzeichnisstruktur ist unabhängig von der Domäne, und Produzenten organisieren Konzepte so, wie es für das erfasste Wissen sinnvoll ist. Ein Bundle KANN als Git-Repository (empfohlene Form, weil Git Historie, Attribution und Diffs liefert), als Tarball- oder Zip-Archiv oder als Unterverzeichnis in einem größeren Repository distribuiert werden. Die reservierten Dateinamen, index.md und log.md, haben auf jeder Hierarchie-Ebene eine definierte Bedeutung und DÜRFEN NICHT für Konzept-Dokumente verwendet werden. Alle anderen .md-Dateien im Baum sind Konzept-Dokumente.
Ein Konzept ist eine einzelne UTF-8-Markdown-Datei mit zwei Teilen: einem YAML-Frontmatter-Block, der durch ----Zeilen am Anfang der Datei begrenzt ist, und einem Markdown-Body, der Freiform-Inhalt enthält. Das Frontmatter ist der Ort, an dem die strukturelle Arbeit passiert, und die Spezifikation ist bezüglich genau einer Sache im Frontmatter opinionated: Das type-Feld ist Pflicht, muss nicht-leer sein und ist das einzige Feld, das Konsumenten verlangen dürfen. Alles andere ist vom Produzenten definiert.
---
type: <Type name> # REQUIRED
title: <Optional display name>
description: <Optional one-line summary>
resource: <Optional canonical URI for the underlying asset>
tags: [<tag>, <tag>, …] # Optional
timestamp: <ISO 8601 datetime> # Optional last-modified time
# … other producer-defined key/value pairs
---
Die empfohlenen Felder, in Prioritätsreihenfolge, sind title (für Menschen lesbarer Anzeigename, aus dem Dateinamen abgeleitet, falls abwesend), description (einzeilige Zusammenfassung, verwendet von Index-Generatoren, Such-Snippets und Previews), resource (kanonische URI für das zugrundeliegende Asset, das das Konzept beschreibt, ausgelassen für Konzepte, die abstrakte Ideen statt physische Ressourcen beschreiben), tags (YAML-Liste kurzer Strings für querschnittliche Kategorisierung) und timestamp (ISO-8601-Datetime der letzten signifikanten Änderung). Produzenten DÜRFEN beliebige zusätzliche Schlüssel einfügen, und Konsumenten SOLLTEN unbekannte Schlüssel beim Round-Trip bewahren und SOLLTEN Dokumente mit nicht erkannten Feldern NICHT ablehnen. Die Toleranz ist absichtlich: OKF soll nützlich bleiben, während Bundles wachsen, refaktoriert und teilweise von Agents generiert werden.
Der Body ist Standard-Markdown. Es gibt keine Pflicht-Body-Sektionen, aber die Spezifikation benennt drei konventionelle Sektions-Überschriften, die Produzenten VERWENDEN SOLLTEN, wenn anwendbar: # Schema (strukturierte Beschreibung der Spalten oder Felder eines Assets, typischerweise als Markdown-Tabelle), # Examples (konkrete Verwendungsbeispiele, oft als Code-Fence-Blöcke) und # Citations (externe Quellen, die Behauptungen im Body stützen, mit nummerierten Referenzen). Der Body ist der Ort, an dem der Großteil des Werts für einen Agent-Konsumenten lebt, und die strukturelle Anleitung ist der Teil, der ein OKF-Dokument von einer persönlichen Notizdatei im selben Verzeichnis unterscheidet.
Das type-Feld ist der Teil, der die meiste Arbeit leistet. type-Werte werden nicht zentral registriert, und die Spezifikation gibt eine Beispielliste: BigQuery Table, BigQuery Dataset, API Endpoint, Metric, Playbook, Reference. Produzenten SOLLTEN deskriptive und selbsterklärende Werte wählen; Konsumenten MÜSSEN unbekannte Typen tolerant behandeln, typischerweise indem sie sie als generische Konzepte darstellen. Die Toleranz ist dieselbe wie die Frontmatter-Extensions-Toleranz: Ein Agent, der auf ein Konzept vom Typ Sev1 Incident Runbook von einem Vendor stößt, den er nie gesehen hat, sollte das Bundle nicht ablehnen, sondern das Konzept als generisches Dokument rendern und die Prosa des Produzenten die Semantik beschreiben lassen. Das permissive Konsumtionsmodell ist die Designentscheidung, die OKF als Community-gepflegtes Format lebensfähig macht statt als Google-kontrolliertes Schema.
Die Spezifikation, im Detail: Linking, Indexing, Logging, Conformance
Die interessanten Teile der Spezifikation sind die vier Mechanismen, die ein Verzeichnis von Dateien in einen navigierbaren, versionskontrollierten Wissenskorpus verwandeln. Sie sind klein, sie komponieren, und jeder ist die Antwort auf eine Frage, die jedes Team wiedererkennen wird, das versucht hat, ein Wiki mit mehr als ein paar hundert Seiten zu pflegen.
Cross-Linking ist der Teil, der das Verzeichnis in einen Graphen verwandelt. Konzepte DÜRFEN mit Standard-Markdown-Links auf andere Konzepte verweisen, in zwei Formen. Die erste ist bundle-relative (absolut innerhalb des Bundles): ein Link wie [customers table](/tables/customers.md) wird relativ zur Bundle-Wurzel aufgelöst, was ihn stabil macht, wenn Dokumente innerhalb ihres Unterverzeichnisses verschoben werden. Die zweite ist relativ, die Standard-Markdown-Form ./other.md. Die Spezifikation empfiehlt die absolute Form, weil sie die Reorganisation überlebt. Link-Semantik ist bewusst untyped: Ein Link von Konzept A zu Konzept B assertiert eine Beziehung, und die spezifische Art der Beziehung (parent/child, references, joins-with, depends-on) wird durch die umgebende Prosa vermittelt, nicht durch den Link selbst. Konsumenten, die eine Graph-Sicht bauen, behandeln typischerweise alle Links als gerichtete Kanten einer untypisierten Beziehung, und das untypisierte Modell ist das, was die Spezifikation davon abhält, in ein Schema abzurutschen. Konsumenten MÜSSEN kaputte Links tolerieren, ein Link, dessen Ziel nicht existiert, ist nicht fehlerhaft, er kann einfach noch-nicht-geschriebenes Wissen repräsentieren, und die Toleranz ist der Teil, der das Format nutzbar macht, während ein Bundle gebaut wird.
Indexing ist der Teil, der Progressive Disclosure unterstützt. Eine index.md-Datei KANN in jedem Verzeichnis erscheinen, einschließlich der Bundle-Wurzel, und sie enumeriert den Inhalt des Verzeichnisses, um einem Menschen oder Agent zu ermöglichen zu sehen, was verfügbar ist, bevor einzelne Dokumente geöffnet werden. Index-Dateien enthalten kein Frontmatter. Der Body verwendet eine oder mehrere Sektionen, die jeweils Konzepte unter einer Überschrift gruppieren, mit Bullet-List-Einträgen, die auf die relative URL des Konzepts verlinken und die Beschreibung des Konzepts aus seinem Frontmatter übernehmen. Produzenten DÜRFEN index.md automatisch generieren; Konsumenten DÜRFEN on the fly eines synthetisieren, wenn keines vorhanden ist. Das Progressive-Disclosure-Pattern ist der Teil, der OKF für große Korpora funktionsfähig macht: Ein Agent kann die Wurzel-index.md lesen, entscheiden, welches Unterverzeichnis relevant ist, diese index.md lesen, entscheiden, welches Konzept zu öffnen ist, und das Konzept lesen, ohne jemals das gesamte Bundle in den Kontext zu laden. Für ein 10.000-Konzepte-Bundle ist das Pattern der Unterschied zwischen einem nutzbaren und einem unnutzbaren Korpus.
Logging ist der Teil, der Version-Control-Workflows unterstützt. Eine log.md-Datei KANN auf jeder Hierarchie-Ebene erscheinen, um die Änderungshistorie dieses Scopes aufzuzeichnen. Das Format ist eine flache Liste von datumsgruppierte Einträgen, neueste zuerst, mit Datums-Überschriften im ISO-8601-Format YYYY-MM-DD. Die Log-Einträge sind Prosa, mit einem fettgedruckten Wort am Anfang (**Update**, **Creation**, **Deprecation**) als Konvention, nicht als Anforderung. Das Pattern ist direkt von den Changelog-Konventionen entlehnt, die die Open-Source-Community seit einem Jahrzehnt nutzt, und die Wahl, das Format in Prosa statt strukturiert zu halten, ist der Teil, der den Log für Menschen lesbar, für Agents parsbar und in einer Git-Commit-Message schreibbar macht. Der Log ist nicht autoritativ (Git ist die Source of Truth), er ist eine denormalisierte leseoptimierte Sicht auf die Historie, die ein Bundle-Kurator bei jedem Release erzeugen kann.
Conformance ist der Teil, der festlegt, was es heißt, OKF-kompatibel zu sein. Ein Bundle ist konform mit v0.1, wenn drei Bedingungen gelten: jede nicht-reservierte .md-Datei im Baum enthält einen parsbaren YAML-Frontmatter-Block, jeder Frontmatter-Block enthält ein nicht-leeres type-Feld, und jeder reservierte Dateiname folgt der in §6 und §7 beschriebenen Struktur, falls vorhanden. Konsumenten SOLLTEN alle anderen Constraints als weiche Anleitung behandeln, und Konsumenten DÜRFEN ein Bundle NICHT ablehnen wegen fehlender optionaler Frontmatter-Felder, unbekannter type-Werte, unbekannter zusätzlicher Frontmatter-Schlüssel, kaputter Cross-Links oder fehlender index.md-Dateien. Das permissive Konsumtionsmodell ist die Designentscheidung, die OKF von einem strikteren schema-getriebenen Format unterscheidet (Protocol Buffers, Avro, OpenAPI), und die Wahl ist absichtlich: Der Wert eines Wissensformats liegt darin, wie viele Parteien es sprechen, und ein Format, das Bundles wegen fehlender optionaler Felder ablehnt, ist ein Format, das geforkt wird.
Die Versionierungs-Geschichte ist der Teil, der bestimmt, ob OKF v0.1 ein Startpunkt oder ein fertiger Standard ist. Die Spezifikation ist in der Form <major>.<minor> versioniert, wobei ein Minor-Versions-Bump rückwärtskompatible Ergänzungen einführt (neue optionale Felder, neue konventionelle Sektions-Überschriften) und ein Major-Versions-Bump Breaking Changes vorbehalten bleibt (Umbenennung von Pflichtfeldern, Änderung reservierter Dateinamen). Bundles DÜRFEN die OKF-Version, die sie anvisieren, deklarieren, indem sie okf_version: "0.1" im Frontmatter-Block der Wurzel-index.md einfügen, dem einzigen Ort, an dem Frontmatter in einer index.md erlaubt ist. Konsumenten, die die deklarierte Version nicht verstehen, SOLLTEN eine Best-Effort-Konsumption versuchen, statt das Bundle abzulehnen. Das Pattern ist dasselbe, das IETF, W3C und WHATWG seit zwei Jahrzehnten nutzen, und die Wahl, bezüglich der Versions-Semantik explizit zu sein, ist der Teil, der OKF zu einem Kandidaten für tatsächliche Standardisierung macht statt zu einem One-off-Format.
Das LLM-Wiki-Pattern, benannt
Das Nützlichste, was die Ankündigung tut, ist einem Pattern einen Namen zu geben, das im KI-Ökosystem seit mindestens einem Jahr leise aufgekommen ist. Das Pattern ist die Praxis, kuratiertes Wissen als Markdown-Dateien mit YAML-Frontmatter zu speichern, in einer Verzeichnisstruktur organisiert, und Agents (statt Suchmaschinen) die Struktur traversieren zu lassen. Das Pattern ist unter verschiedenen Namen, in verschiedenen Communities, aus verschiedenen Gründen wieder aufgetaucht, und OKF ist die erste Spezifikation, die die Kategorie beansprucht statt nur eine der Instanzen.
Andrej Karpathys LLM-Wiki-Gist ist die konzeptionelle Quelle, und der Blog-Post zitiert sie direkt: 'LLMs werden nicht gelangweilt, vergessen nicht, eine Cross-Reference zu aktualisieren, und können 15 Dateien in einem Durchgang anfassen.' Das Argument ist, dass die Buchhaltung, die Menschen dazu bringt, persönliche Wikis aufzugeben (Cross-References aktualisieren, tote Links reparieren, Hierarchien restrukturieren) genau das ist, was LLMs gut können. Dieselbe Einsicht erscheint in verschiedenen Formen im KI-Tooling-Ökosystem. Obsidian-Vaults, die mit Coding-Agents verdrahtet sind, sind die sichtbarste Instanz: Ein Entwickler pflegt ein Vault mit Notizen über sein Codebase, ein Agent liest das Vault vor der Arbeit, der Agent aktualisiert das Vault, während er lernt, und das Vault wird zu einem lebendigen Gedächtnis des Projekts, das mit der Zeit nützlicher wird. Die AGENTS.md- und CLAUDE.md-Familie der Konventionsdateien ist dasselbe Pattern in Ein-Datei-Form: eine einzelne Markdown-Datei an der Repository-Wurzel, die ein Agent vor der Arbeit konsultiert und die der Agent aktualisiert, während er die Projektkonventionen lernt. Das Pattern taucht auch in Data-Teams als 'Metadata-as-Code'-Repositories auf, wo SQL-Tabellen-Dokumentation, Metrik-Definitionen und Runbooks in versionskontrollierten Markdown-Dateien leben statt in einem separaten Metadaten-Register.
Der Grund, warum das Pattern wieder aufgekommen ist, ist, dass es ein Problem löst, das akut geworden ist, seit Agents die primären Konsumenten von Enterprise-Wissen geworden sind. Suchbasiertes Retrieval (finde mir ein Dokument, das den String weekly_active_users enthält) bricht zusammen, wenn der Agent einen Kontext aus zehn verschiedenen Dokumenten zusammensetzen muss, mit Cross-References zwischen ihnen, in einer bestimmten Reihenfolge, mit einem bestimmten Konfidenzniveau in jedem Stück. Ein Verzeichnis strukturierter Markdown-Dateien erlaubt dem Agent, in der Struktur zu navigieren: Lese den Wurzel-Index, entscheide, welches Unterverzeichnis relevant ist, lese den Unterverzeichnis-Index, entscheide, welches Konzept zu öffnen ist, lese das Konzept, folge den Cross-Links. Die Navigation ist explizit im Dateisystem und explizit im Frontmatter, was der Teil ist, der sie sowohl für Menschen lesbar als auch für Agents navigierbar macht.
Der Grund, warum das Pattern bisher ein Chaos war, ist, dass jede Instanz bespoke ist. Karpathys Wiki und das Wiki Ihres Teams und der Katalog-Export eines Vendors mögen alle ähnlich aussehen (Markdown, Frontmatter, Cross-Links), aber keines ist absichtlich dafür designed, zu kooperieren. Es gibt keine vereinbarte Antwort darauf, welche Felder jedes Dokument tragen sollte oder was Dateinamen bedeuten. Infolgedessen bleibt das in Wikis kodierte Wissen siloed innerhalb der Original-Teams, was zu redundantem Aufwand führt, sobald ein neuer Agent gebaut wird. OKF ist die Antwort auf die Frage 'was ist der kleinste Satz von Konventionen, der all diesen Instanzen erlaubt zu kooperieren', und die Antwort ist klein genug, um in eine 1.000-Zeilen-Spezifikation zu passen.
Was am Pattern auffällt, ist, dass es stromabwärts von drei älteren Ideen liegt, und die Abstammung ist ein Teil des Grundes, warum die Spezifikation so minimal ist. Das erste ist das Static-Site-Generator-Pattern (Hugo, Jekyll, MkDocs, Docusaurus), das seit über einem Jahrzehnt Markdown + Frontmatter rendert. Das zweite ist das Personal-Knowledge-Management-Pattern (Obsidian, Notion, Roam, Logseq), das seit fast ebenso langer Zeit Markdown + Frontmatter + Cross-Links für den persönlichen Gebrauch pflegt. Das dritte ist das Documentation-as-Code-Pattern (Docs als Markdown im selben Repository wie der Code, deployed bei jedem Release), das jetzt der Default für fast jedes Developer-facing-Produkt ist. OKF ist die Kombination aller drei, mit dem Agent als neuem Konsumenten, und die Spezifikation ist minimal, weil die zugrundeliegenden Patterns bereits minimal sind. Die Arbeit war immer da; OKF ist der Teil, der sie benennt.
Was Google ausliefert: vier Referenz-Artefakte, eine strategische Integration
Die Referenzimplementierungen werden im README bewusst 'Proofs of Concept' genannt, und das Framing ist wichtig: Das Format ist der Beitrag, und die Tools existieren, um das Format an beiden Enden der Produzent/Konsument-Achse greifbar zu machen. Google hat im selben Release vier distinkte Artefakte ausgeliefert, und jedes ist die Antwort auf eine spezifische Frage, wie das Format in der Praxis funktioniert.
Der Enrichment-Agent ist das Produzenten-Ende. Es ist ein Python-Paket (enrichment_agent, installiert via python3.13 -m venv .venv && .venv/bin/pip install -e .[dev]), das auf dem Google Agent Development Kit aufbaut, mit Gemini als Modell-Backend. Der Agent läuft in zwei Pässen. Der erste Pass durchläuft ein BigQuery-Dataset, liest das Schema und die Metadaten für jede Tabelle und View, und schreibt ein OKF-Konzept-Dokument pro Konzept, das die Quelle anbietet. Der zweite Pass lässt das LLM als seinen eigenen Crawler laufen: Es erhält eine Liste von Seed-URLs, fetched die Seeds und entscheidet, welche ausgehenden Links es wert sind, gefolgt zu werden, basierend darauf, ob sie wie autoritative Dokumentation für die existierenden Konzepte aussehen. Für jede Seite, die es fetched, wählt der Agent, ob er ein oder mehrere existierende Konzept-Dokumente enrichen, ein eigenständiges references/<slug>-Dokument minten oder skippen will. Ein hartes --web-max-pages-Cap und ein Same-Domain-Allowed-Hosts-Filter werden innerhalb des Tools erzwungen, sodass der Agent nicht über die Grenzen hinausläuft. Die CLI ist ein Befehl:
.venv/bin/python -m enrichment_agent enrich \
--source bq \
--dataset <project>.<dataset> \
--web-seed-file <path/to/seeds.txt> \
--out ./bundles/<name>
Das Source-Interface ist auf Wachstum ausgelegt. BigQuery ist die erste Source-Implementierung; Dataplex, Unity Catalog, Collibra und ein Database-Walker werden alle im README als Ziele genannt, und das Interface ist der dokumentierte Erweiterungspunkt für jede neue Source.
Der statische HTML-Visualizer ist das Konsumenten-Ende. Es ist ein visualize-Subkommando auf demselben Python-Paket, und es rendert jedes OKF-Bundle als selbst enthaltene interaktive HTML-Datei: eine Datei, kein Backend, keine Installation auf der Betrachtungsseite. Der Viewer zeigt einen Force-Directed-Graph jedes Konzepts im Bundle, mit farbigen Knoten nach Typ (Datasets, Tables, References) und gerichteten Kanten, die von jedem Cross-Link in den Markdown-Bodys gezogen werden. Ein Detail-Panel für das ausgewählte Konzept zeigt sein Frontmatter (Description, Resource-Link, Tags) und seinen gerenderten Markdown-Body, mit internen Links, die so umverdrahtet sind, dass sie innerhalb des Viewers navigieren statt dem Pfad zu folgen. Eine 'Cited by'-Backlinks-Liste wird aus der Umkehrung des Link-Graphen berechnet. Eine Such-Box matcht Titel, Concept-ID und Tags, ein Typ-Filter schränkt die sichtbaren Knoten ein, und umschaltbare Graph-Layouts (cose, concentric, breadth-first, circle, grid) lassen einen Kurator den Korpus auf verschiedene Arten erkunden. Die Visualisierung wird von cytoscape.js generiert, eingebettet in eine einzige selbst enthaltene HTML-Datei, und die Datei kann lokal geöffnet, als Artefakt geteilt oder auf einem Static-File-Server gehostet werden.
Die drei Beispiel-Bundles sind die lebenden Beispiele. Das erste ist das GA4-E-Commerce-Bundle, generiert aus dem öffentlichen GA4-BigQuery-Export-Datensatz und geseedet mit den kanonischen GA4-Dokumentations-URLs. Das zweite ist das Stack-Overflow-Bundle, generiert aus dem öffentlichen Stack-Exchange-Data-Dump-Datensatz und geseedet mit den kanonischen Schema-Referenzen der Community; es exerziert Multi-Konzept-Enrichment aus querschnittlichen Doku-Seiten. Das dritte ist das Bitcoin-Bundle, generiert aus der bitcoin-etl-Pipeline und geseedet mit der Bitcoin-Protokoll-Dokumentation; es exerziert Cross-Table-Foreign-Key-Beziehungen in Prosa, die Art von Wissen, die schwer in einem relationalen Schema zu repräsentieren und einfach in ein paar Sätzen Markdown auszudrücken ist. Jedes Sample paart ein Rezept (die Seed-URLs und den exakten enrich-Befehl, in samples/<name>/) mit dem produzierten Bundle (in bundles/<name>/), sodass ein Entwickler das Bundle auf seiner eigenen Maschine mit einem Befehl reproduzieren kann. Die Beispiel-Bundles sind auch der stärkste Beweis, dass das Format in nicht-trivialer Größenordnung funktioniert: Das GA4-Bundle hat Hunderte von Konzept-Dokumenten und einen reich vernetzten Link-Graph, und der Visualizer rendert es ohne Performance-Probleme.
Die BigQuery-Knowledge-Catalog-Integration ist der strategische Move. Der Knowledge Catalog ist BigQuerys eingebauter Metadaten-Service, die Oberfläche, die SQL-Autocomplete, Schema-Discovery und die Integration mit Vertex-AI-Agents speist. Zum Zeitpunkt des OKF-Launchs kann der Knowledge Catalog OKF-Bundles nativ ingestieren: Ein Team kann den Enrichment-Agent gegen sein BigQuery-Dataset laufen lassen, ein OKF-Bundle produzieren und es ohne Custom-Integrations-Code in den Katalog pushen. Der Katalog serviert dann den OKF-Content an Agents, die BigQuery abfragen, wobei das Frontmatter zu den indexierbaren Metadaten wird und der Body zum agent-lesbaren Kontext. Die Integration ist separat dokumentiert, in der BigQuery-Dokumentation, nicht in der OKF-Spezifikation, und die Trennung ist absichtlich: Die Spezifikation ist Platform-neutral, und die Integration ist eine Google-Plattform-spezifische Annehmlichkeit obendrauf.
Die vier Artefakte zusammen erfüllen eine andere Aufgabe, als sie aussehen. Der Enrichment-Agent ist kein Produkt, er ist eine Referenzimplementierung. Der Visualizer ist kein Produkt, er ist eine Referenzimplementierung. Die Beispiel-Bundles sind keine Produkte, sie sind Referenzbeispiele. Die BigQuery-Integration ist die einzige der vier, die ein Produkt ist, und das ist der Teil, der als Value-Add für BigQuery-Kunden positioniert ist statt als separater Produkt-Launch. Die Architektur ist dieselbe, die Google für Kubernetes, TensorFlow und gRPC verwendet hat: Veröffentliche die offene Spezifikation, liefere eine hochwertige Referenzimplementierung aus, und lass die Produkt-Integrationen der Spezifikations-Adoption folgen. Die Strategie ist gut erprobt, und die Spezifikation ist gut positioniert, um die Art von Ding zu sein, das zum Default wird, ohne jemals die einzige Option zu sein.
Der Präzedenzfall: Wer das schon tut, und was sich ändert
Die interessante Frage für die nächsten sechs Monate ist nicht, ob OKF ein gutes Format ist; die Spezifikation ist gut, das Format ist minimal, und die Referenzimplementierungen funktionieren. Die interessante Frage ist, ob das Pattern, das OKF benennt, das LLM-Wiki-Pattern, bereits dabei war, sich zu einer Community-Konvention zu entwickeln, bevor Google die Spezifikation veröffentlicht hat, und ob die Spezifikation die Konvergenz beschleunigt oder fragmentiert.
Das Pattern war bereits dabei zu konvergieren, und der Beweis ist die Liste der Communities, die unabhängig voneinander bei derselben Form angekommen sind. Die Hugo-Community macht seit 2013 Markdown + Frontmatter + Cross-Links für statische Sites. Die Obsidian-Community macht dasselbe für Personal Knowledge Management seit 2020, mit einem Plugin-Ökosystem, das bereits OKF-förmige Exporte enthält. Die Docusaurus- und Astro-Communities machen seit 2017 bzw. 2021 Markdown + Frontmatter für Dokumentations-Sites. Die Data-Engineering-Community macht 'Metadata as Code' in verschiedenen Formen (dbt docs, LookML-Views mit Beschreibungen, BigQuery INFORMATION_SCHEMA + handgeschriebenes Markdown) seit mindestens fünf Jahren. Die KI-Tooling-Community macht AGENTS.md / CLAUDE.md / context.md seit den letzten achtzehn Monaten. Der Karpathy-LLM-Wiki-Gist hat das Pattern als Empfehlung kristallisiert, und der Anthropic-Context-Engineering-Blog-Post hat die Prinzipien Mitte 2025 formalisiert. Das Pattern ist der Konvergenzpunkt, und OKF ist die erste Spezifikation, die es beansprucht.
Was sich mit der Spezifikation ändert, ist die Antwort auf die Frage 'was ist der kleinste Satz von Konventionen, der all diesen Instanzen erlaubt zu kooperieren'. Vor OKF war die Antwort 'nichts, sie sehen sich alle nur irgendwie ähnlich'. Nach OKF ist die Antwort 'die v0.1-Spezifikation, die 1.000 Zeilen umfasst und auf eine Seite passt'. Die Änderung liegt nicht im Format selbst, das Format war immer da; die Änderung liegt in der sozialen Tatsache, dass es jetzt eine veröffentlichte Spezifikation gibt, auf die jeder zeigen kann, gegen die jeder implementieren kann, und die jeder forken kann, wenn er mit den Designentscheidungen nicht einverstanden ist. Die Spezifikation ist ein Koordinationspunkt, und Koordinationspunkte sind das wertvollste Artefakt in jedem Ökosystem mit mehr als drei Teilnehmern.
Die kompetitive Frage, die sich in den nächsten sechs Monaten entscheiden wird, ist, ob OKF zur Lingua Franca wird, oder ob eine konkurrierende Spezifikation aus einer anderen Ecke des KI-Ökosystems auftaucht. Die glaubwürdigsten konkurrierenden Spezifikations-Kandidaten sind Anthropics context.md-Arbeit (falls sie sich über den Engineering-Blog-Post hinaus formalisiert), das Resource-Format der MCP (Model Context Protocol)-Community (das auf JSON-RPC basiert und nicht auf Markdown), und die Graph-Store-Formate von Cognee / LlamaIndex (die auf JSON basieren und datenbankförmig statt dateiförmig sind). Jede hat eine Constituency, und jede löst ein etwas anderes Problem: MCP ist für Runtime-Tool-Calling, die Graph-Store-Formate sind für vektorielles Retrieval, und OKF ist für human-readable, versionskontrollierte, agent-navigierbare Korpora. Die Probleme überlappen, sind aber nicht identisch, und das wahrscheinlichste Ergebnis ist Koexistenz statt Konsolidierung. Der Grund ist, dass die drei Formate drei verschiedene Probleme lösen, und dasselbe Team, das MCP für Tool-Calling und LlamaIndex für Retrieval nutzt, wird OKF für die Dokumentation nutzen, die der Agent liest, um den Kontext zu verstehen.
Die strategische Frage für Google ist, ob die BigQuery-Knowledge-Catalog-Integration ausreicht, um OKF zum Default zu machen, oder ob das Ökosystem zusätzliche Moats braucht. Die Integration ist ein starker Moat für BigQuery-Kunden, aber sie hilft Teams nicht, die auf Snowflake, Databricks oder Redshift laufen. Die Referenzimplementierungen sind bewusst Platform-neutral, aber der hochwertige Produzent im Referenzset (der Enrichment-Agent) ist BigQuery-only in v0.1. Die Wette ist, dass die Spezifikations-Adoption von Teams kommt, die bereits BigQuery nutzen, dass die BigQuery-Kunden die nützlichsten OKF-Bundles produzieren werden, und dass die Bundles die Non-BigQuery-Konsumenten anziehen werden, weil die Bundles gut sind. Die Wette ist plausibel, und die Timeline ist der Teil, den man beobachten sollte: Wenn Snowflake oder Databricks innerhalb von sechs Monaten eine konkurrierende Spezifikation veröffentlicht, hat der Format-Krieg begonnen; wenn innerhalb eines Jahres keine konkurrierende Spezifikation auftaucht, hat OKF per Default gewonnen.
Was die Wette plausibel macht, ist die Offenheit der Lizenzierung und des Designs. OKF wird unter Apache-2.0 veröffentlicht, derselben Lizenz, die das Fundament des modernen Open-Source-Ökosystems bildet (Kubernetes, TensorFlow, Swift, Apache-Foundation-Projekte). Die permissive Lizenz ist der Teil, der die Spezifikation forkable macht, der Teil, der alternative Implementierungen willkommen heißt, und der Teil, der die Spezifikation zu einem Kandidaten für die Adoption durch Teams macht, die philosophisch allergisch gegen alles sind, was wie ein Google-kontrollierter Standard aussieht. Die permissive Lizenz ist auch der Teil, der die Spezifikation schlecht für einen feindlichen Fork macht: Eine konkurrierende Spezifikation müsste signifikant anders sein, nicht nur anders gebrandet, und die Schwelle für signifikante Unterschiede ist hoch, wenn die zugrundeliegende Spezifikation bereits so minimal ist.
Was man beobachten sollte
Die nächsten 24 Stunden und die nächsten 24 Wochen haben jeweils spezifische Signale, die es wert sind, verfolgt zu werden. OKF v0.1 ist ein Startpunkt, und die Signale, die entscheiden, ob es zu einer Category-defining-Spezifikation oder einem One-off-Format wird, sind alle beobachtbar.
Für die nächste Woche:
- Die ersten Community-PRs des Repositories. Das Repository hat 3.300 Sterne, 213 Forks und 22 offene Issues zum Zeitpunkt des Artikels, und die ersten Community-PRs werden den Ton für die Evolution der Spezifikation setzen. Eine PR, die ein neues optionales Frontmatter-Feld hinzufügt, ist ein gesundes Signal (die Spezifikation wird auf die Art erweitert, für die sie designt wurde). Eine PR, die ein konkurrierendes Pflichtfeld hinzufügt, ist ein Warnsignal (die Community forkt das Design bereits). Eine PR, die eine neue Referenzimplementierung auf einer Non-BigQuery-Source (Snowflake, Databricks, Postgres) hinzufügt, ist das stärkste Signal für Ökosystem-Traction.
- Das erste Non-Google-OKF-Bundle. Die drei Beispiel-Bundles sind alle von Google produziert. Das erste Non-Google-OKF-Bundle, das in den nächsten sieben Tagen auf GitHub oder Hacker News gepostet wird, ist der direkteste Test, ob die Spezifikation über das BigQuery-Ökosystem hinaus adoptiert wird. Die wahrscheinlichste Quelle ist ein Entwickler, der ein LLM-Wiki im Karpathy-Stil gepflegt hat und nach einer Möglichkeit gesucht hat, das Format zu teilen; die wertvollste Quelle ist ein Data-Team in einem Non-BigQuery-Shop, das sich entschieden hat, auf OKF zu standardisieren.
- Der erste Drittanbieter-Visualizer. Der Referenz-Visualizer ist eine einzelne selbst enthaltene HTML-Datei, die vom Google-Python-Paket generiert wird. Ein Drittanbieter-Visualizer, geschrieben in einer anderen Sprache (TypeScript, Go, Rust) oder mit einer anderen Visualisierungs-Bibliothek (d3, vis.js, sigma.js), ist das stärkste Signal für Konsumenten-seitige Adoption. Der erste, der auftaucht, ist wahrscheinlich ein TypeScript-Port, der vis-network oder react-flow nutzt, weil die Entwickler-Audience für Visualisierungs-Bibliotheken stark TypeScript-zentriert ist.
- Die erste OKF-Erwähnung in einem Non-Google-KI-Tooling-Blog-Post. Der Blog-Post und der Tweet sind beide von Google. Die erste Non-Google-Erwähnung, in einem Cursor-Blog-Post, einer Claude-Code-Release-Note, einem LangChain-Changelog, einer LlamaIndex-Ankündigung oder einem OpenAI-Cookbook, ist das erste Signal, dass die Spezifikation von 'Google-Projekt' zu 'Community-Standard' gewechselt hat. Der wahrscheinlichste Venue ist ein Cursor- oder Claude-Code-Post darüber, wie das Team OKF als Format für die interne Wissensbasis des Tools nutzt.
Für die nächsten 24 Wochen:
- Ein OKF-v0.2-Release. v0.1 ist ein Draft, und das erste v0.2-Release ist das erste Signal, wie die Spezifikation durch Community-Feedback geformt wird. Das v0.2-Changelog ist die wichtigste Lektüre: Welche optionalen Felder wurden hinzugefügt, welche konventionellen Sektions-Überschriften wurden promoted, welche Konformitätskriterien wurden verschärft. Ein v0.2, das zu viele Felder hinzufügt, ist ein Zeichen, dass die Spezifikation ihre Minimalität verliert; ein v0.2, das zu wenige hinzufügt, ist ein Zeichen, dass die Spezifikation unter-curated wird.
- Eine Non-Google BigQuery-äquivalente Source-Implementierung. Der Enrichment-Agent ist BigQuery-only in v0.1. Die erste Non-BigQuery-Source-Implementierung (Snowflake, Databricks, Postgres, MySQL, ein generischer SQL-Walker) ist das erste Signal, dass das Format als Multi-Vendor-Standard adoptiert wird. Die wahrscheinlichste Quelle ist eine Community-PR an das bestehende Repository, nicht ein neues Repository, weil der Format-Name besser auffindbar ist, wenn er an einem Ort lebt.
- Ein OKF-kompatibles Produkt eines BigQuery-Konkurrenten. Snowflake Cortex, Databricks Unity Catalog, Redshift Spectrum oder ein anderes Data-Warehouse-adjazentes Produkt, das einen OKF-kompatiblen Ingest-Pfad ausliefert, ist das erste Signal, dass die Spezifikation zu einem kompetitiven Schlachtfeld geworden ist. Die wahrscheinlichste Timeline ist Q4 2026 oder Q1 2027, weil Data-Warehouse-Vendors historisch langsam waren bei der Adoption offener Standards, die von Konkurrenten initiiert wurden.
- Anthropics Antwort. Anthropic hat seine eigene Context-Engineering-Arbeit, das MCP-Protokoll und ein starkes Interesse am LLM-Wiki-Pattern. Der erste Anthropic-Post, der OKF erwähnt, entweder positiv (als nützliche Ergänzung zu MCP) oder negativ (als Format, das Anthropics Bedürfnisse nicht erfüllt), ist das erste Signal, wie sich das zweitgrößte KI-Lab zur Spezifikation positioniert. Eine positive Erwähnung wäre ein großes Endorsement; eine negative Erwähnung wäre der erste Schuss in einem Format-Krieg.
- Das erste OKF-Bundle mit mehr als 10.000 Konzepten. Die Referenz-Bundles haben Hunderte von Konzepten. Das erste OKF-Bundle mit mehr als 10.000 Konzepten ist das erste Signal, dass das Format im Maßstab eines echten Unternehmens funktioniert. Die wahrscheinlichste Quelle ist ein Data-Team, das sich entschieden hat, einen gesamten BigQuery-INFORMATION_SCHEMA-Korpus nach OKF zu exportieren, was der natürliche Use-Case für den BigQuery-Enrichment-Agent ist. Die Performance des Visualizers auf einem 10.000-Konzepte-Bundle ist das erste Signal, ob das Format für wirklich große Korpora tragfähig ist.
- Ein OKF-v1.0-Release mit Breaking Changes. v0.1 ist explizit ein Draft. Das erste v1.0-Release, mit welchen Breaking Changes auch immer der Curation-Prozess angesammelt hat, ist das erste Signal, ob OKF dem IETF/W3C-Pattern der langsamen, sorgfältigen, rückwärtsinkompatiblen Evolution folgen wird oder dem Kubernetes-Pattern der häufigen, sorgfältigen, rückwärtsinkompatiblen Evolution. Die Breaking Changes, die v1.0 einführt, sind das erste Signal, welche Designentscheidungen die Community bereit ist zu verteidigen und welche sie bereit ist zu revidieren.
