Das Open Knowledge Format (OKF) ist eine offene, vendor neutrale Spezifikation von Google Cloud, die organisatorisches Wissen als Verzeichnis von Markdown Dateien mit YAML Frontmatter darstellt. Veröffentlicht am 12. Juni 2026 vom Google Cloud Data Cloud Team, formalisiert OKF das sogenannte LLM Wiki Muster in ein portables, interoperables Format, das Menschen und KI Agenten gleichermaßen lesen können. Aktueller Stand ist seit dem 24. Juli 2026 die Version v0.2.

Die Idee dahinter ist bewusst schlicht: kein neues Runtime, kein Pflicht SDK, keine proprietäre Plattform. Ein OKF Bundle ist nur Markdown, nur Dateien, nur YAML Frontmatter. Jede Datei beschreibt ein Konzept, etwa eine Tabelle, ein Dataset, eine Metrik, ein Runbook oder eine API. Der Dateipfad ist die Identität des Konzepts, und gewöhnliche Markdown Links verbinden die Konzepte zu einem Wissensgraphen.

OKF löst das Context Assembly Problem moderner Agentensysteme. Heute liegt internes Wissen verstreut in Metadaten Katalogen, Wikis, Code Kommentaren oder allein in den Köpfen erfahrener Entwickler. Jedes neue KI Agenten Projekt sammelt diese Informationen von Grund auf neu ein. OKF setzt an dieser Stelle einen gemeinsamen Standard, vergleichbar mit dem, was das Model Context Protocol für den Tool Zugriff leistet, nur eben für das Wissen selbst.

Mit v0.2 kommt die Frage dazu, die sich stellt, sobald Agenten selbst in die Wissensbasis schreiben: Wie vertrauenswürdig ist das, was da steht? Die Antwort sind optionale Frontmatter Felder für Herkunft, Prüfung, Frische und Lebenszyklus sowie ein neuer Concept Type für geprüfte Berechnungen. Ein Bundle aus v0.1 bleibt dabei unverändert gültig.

Never Code Alone beschäftigt sich seit Jahren mit lokal gehosteter KI und DSGVO konformen Wissensbasen. Genau das Problem, das OKF adressiert, kennen wir aus der Praxis: Wissen, das in Konfluenz, Code Kommentaren, Datenbank Schemata und den Köpfen einzelner Entwickler feststeckt. In NCA Projekten bauen wir regelmäßig Markdown basierte Knowledge Stacks auf, etwa mit Obsidian, Logseq und dem SKILL.md Format, und wissen daher, wie ein offener Standard wie OKF in einen produktiven Workflow passt.

Rund um das Open Knowledge Format ordnet NCA alle angrenzenden Themen ein: vom Vibe Coding Consulting über den Aufbau eines DSGVO konformen lokalen Stacks mit Ollama und llama.cpp bis zur Anbindung an das Model Context Protocol. Wir helfen Teams, eine Wissensbasis sauber zu strukturieren, prüfen im konkreten Use Case, ob OKF zur eigenen Architektur passt, und zeigen, wie sich das Format mit lokaler KI für Compliance verbinden lässt.

Ein OKF Bundle ist ein Verzeichnis aus Markdown Dateien. Jede Datei repräsentiert ein Konzept und besteht aus einem kleinen YAML Frontmatter Block für strukturierte, abfragbare Felder und einem Markdown Body für alles Weitere. Das einzige Pflichtfeld ist type, auch in v0.2. Optional und ebenfalls reserviert sind title, description, resource und tags. Alles andere überlässt die Spezifikation bewusst dem Produzenten, eigene Schlüssel bleiben erhalten statt abgelehnt zu werden.

So sieht ein Konzept Dokument für eine Tabelle aus:

Konzepte verlinken sich über normale Markdown Links und bilden so einen Graphen aus Beziehungen, der reicher ist als die reine Ordnerhierarchie. Optional enthalten Bundles index.md Dateien für progressive Offenlegung beim Navigieren sowie log.md Dateien für die chronologische Änderungshistorie. Die komplette Spezifikation ist weiterhin kurz und liegt offen auf GitHub im Repository GoogleCloudPlatform knowledge-catalog.

Beim Sprung auf v0.2 gibt es zwei bewusste Umbenennungen. Das Feld timestamp wird von generated.at abgelöst, die Liste Citations im Body vom Frontmatter Feld sources. In beiden Fällen kann ein Consumer auf die alte Form zurückfallen. v0.2 ist ein additiver Minor Bump, rückwärtskompatibel und ohne Migrationszwang.

Google begründet das Design von OKF mit drei Leitgedanken, die das Format bewusst leichtgewichtig halten:

• Minimal vorgegeben: OKF verlangt von jedem Konzept genau eine Sache, das Feld type. Welche Typen existieren, welche weiteren Felder genutzt werden und wie der Body aufgebaut ist, bleibt dem Produzenten überlassen. Die Spezifikation definiert die Interoperabilität, nicht das Inhaltsmodell.
• Produzent und Konsument getrennt: Wer das Wissen schreibt, ist sauber davon entkoppelt, wer es konsumiert. Ein von Menschen verfasstes Bundle kann ein KI Agent lesen, ein per Pipeline generiertes Bundle lässt sich in einem Visualizer durchblättern. Das Format ist der Vertrag, die Werkzeuge an beiden Enden sind frei austauschbar.
• Format statt Plattform: OKF ist an keine Cloud, keine Datenbank, keinen Modell Anbieter und kein Agenten Framework gebunden. Es verlangt nie einen proprietären Account oder ein SDK. Der Wert eines Wissensformats entsteht daraus, wie viele Parteien es sprechen, nicht daraus, wem es gehört.

Zum Start liefert Google bewusst nur Referenz Implementierungen: einen Enrichment Agent, der ein BigQuery Dataset durchläuft und für jede Tabelle ein OKF Dokument entwirft, einen statischen HTML Visualizer, der jedes Bundle in eine interaktive Graph Ansicht verwandelt, sowie drei fertige Beispiel Bundles. Diese Tools zeigen einen möglichen Weg, schreiben aber weder Agenten Framework noch Modell vor. Wer mit lokalen Modellen wie Qwen oder einem RAG Framework wie LlamaIndex arbeitet, kann eigene Produzenten und Konsumenten bauen.

Am 24. Juli 2026 hat das Google Cloud Data Cloud Team OKF v0.2 veröffentlicht. Der Auslöser kam aus der Community. Solange ein Mensch eine Wiki Seite schreibt, gibt es eine stille Garantie: jemand ist verantwortlich. Wenn ein Agent über Nacht zehntausend Konzepte erzeugt, ist diese Garantie weg. v0.2 beantwortet deshalb die Frage, der sich jede agentisch gepflegte Wissensbasis stellen muss. Kann ich dem hier trauen?

Google formuliert das als fünf Fragen, die ein Consumer aus dem Frontmatter beantworten können muss, bevor er den Body überhaupt liest:

• Provenance: Woraus ist dieses Konzept entstanden?
• Trust: Wie sehr soll ich ihm vertrauen?
• Freshness: Stimmt es noch?
• Lifecycle: Ist das die aktuelle Version?
• Attestation: Wurde diese Zahl so berechnet, wie es vorgeschrieben ist?

Der Trick dahinter ist Sparsamkeit. Die meisten Zugriffe auf ein Konzept lesen den Text nie. Ein Agent scannt, sortiert aus und entscheidet erst danach, was er wirklich liest. Genau diese Entscheidung soll billig sein, ohne Tokens für Prosa zu verbrennen. Deshalb wandern die Vertrauenssignale ins Frontmatter und nicht in den Body:

generated und verified sind bewusst getrennt. Wer etwas geschrieben hat, muss nicht der sein, der es bestätigt. Aus verified leitet sich ein Trust Tier ab: kein Eintrag heißt unverified, nur maschinelle Bestätigung heißt machine confirmed, eine Bestätigung durch einen human Actor heißt human reviewed. Das ist keine Zugriffskontrolle, sondern ein Filter. Ein Management Dashboard zeigt nur human reviewed Metriken, eine Testumgebung nimmt alles.

Bei sources hat Google bewusst etwas weggelassen: den Score. Statt einer erfundenen Vertrauenszahl stehen dort objektive Signale wie Autor, Nutzungshäufigkeit und Änderungsdatum. Bewerten darf der Consumer selbst. Ein Score wäre subjektiv, wäre zwischen Systemen nicht übertragbar und wäre in dem Moment veraltet, in dem er geschrieben wird. status führt ein Konzept von draft über stable nach deprecated, stale_after setzt ein absolutes Datum statt einer relativen Laufzeit. Damit wird Veralterung zu einem simplen Datumsvergleich, den auch Code ohne LLM ausführen kann.

Der stärkste Teil von v0.2 ist ein neuer Concept Type. Attested Computation beantwortet eine Frage, die in dem Moment brennt, in dem ein Agent einen Geldbetrag nennt: Wurde diese Zahl so berechnet, wie es vorgeschrieben ist, oder hat sich der Agent sein eigenes SQL zusammengebaut?

Ein solches Konzept enthält nicht nur die Bedeutung eines Wertes, sondern die gesanktionierte Berechnung selbst plus die Mittel, ihre Ausführung zu prüfen:

Die Regel ist hart: Der Agent darf ausschließlich die deklarierten parameters füllen. Er darf die Berechnung nie schreiben und nie editieren. Ausgeführt wird über den executor, der ein Receipt zurückgibt, hier die Job ID, das tatsächlich ausgeführte SQL und das Ergebnis. Danach prüft ein attester ohne LLM, rein deterministisch, ob die gelaufene Query der gesanktionierten entspricht. Ein getauschter Tabellenname, ein zusätzlicher Filter, ein weggefallener JOIN: alles fällt durch. Der Consumer zeigt den Wert dann schlicht nicht an.

Wichtig für die Einordnung: OKF beschreibt die Berechnung und den Prüfweg, führt selbst aber nichts aus. Und Attestation ist nicht dasselbe wie Verification. verified bestätigt, dass eine Definition noch zur Policy passt, langsam und auf Dokumentebene. Attestation bestätigt einen einzelnen Lauf, bei jedem Aufruf und ohne im Bundle gespeichert zu werden. Eine veraltete Definition kann sauber attestieren, eine frisch geprüfte Definition braucht trotzdem bei jedem Lauf ihre Attestation.

Für uns bei Never Code Alone ist das der interessanteste Teil der Spezifikation, weil es exakt das Muster ist, das wir aus Vibe Coding Best Practices kennen, nur auf Zahlen statt auf Code angewendet. Ein Agent bekommt Tempo, aber keine Freiheit an der kritischen Stelle. Genau so funktionieren auch Guardrails im Code: Der Agent schreibt, PHPStan, Rector und PHPUnit entscheiden. Wer Agenten an Unternehmensdaten lässt, braucht diese Trennung zwischen Ausführen und Prüfen zwingend.

Für Unternehmen in der EU ist der offene Charakter von OKF mehr als ein technisches Detail. Wer seine Wissensbasis als offenes Markdown ablegt statt in einem proprietären Katalog, behält die volle Kontrolle: Die Dateien lassen sich auf eigenen Servern, im eigenen Git und ohne externen Dienst betreiben. Das macht OKF zu einem natürlichen Baustein für einen DSGVO konformen, lokal gehosteten KI Stack, wie ihn NCA regelmäßig mit Teams aufbaut.

Wichtig zur Einordnung: OKF ersetzt das Model Context Protocol nicht, sondern ergänzt es. MCP regelt, wie ein Agent Werkzeuge und Datenquellen zur Laufzeit anspricht, etwa über einen GitHub MCP Server oder die Mistral Connectors. OKF beschreibt dagegen das kuratierte Wissen selbst. Beide Ansätze adressieren dasselbe Grundproblem aus unterschiedlichen Richtungen: Ein Modell ist nur so gut wie der Kontext, den es bekommt.

Das Muster ist nicht neu. Wer schon einmal einen Obsidian Vault mit einem Coding Agent verbunden, mit SKILL.md Dateien gearbeitet oder das Karpathy LLM Wiki gelesen hat, erkennt die Form sofort. OKF formalisiert genau die kleine Menge an Konventionen, die nötig ist, damit diese bislang individuellen Lösungen zusammenarbeiten. Auch verwandt ist der Trend zu kompakten Datenformaten wie TOON, der ebenfalls Token und Lesbarkeit in den Mittelpunkt stellt.

OKF ist ein Format, kein Tool, das man installiert. Genau deshalb ordnen wir es als Experten ein, statt es pauschal zu empfehlen. Ob ein offener Wissensstandard für dein Projekt passt, hängt davon ab, wie verteilt dein Wissen heute liegt und wie viele Agenten darauf zugreifen sollen. In NCA Projekten sehen wir regelmäßig, dass der größte Hebel nicht im Modell liegt, sondern im Kontext, den es bekommt. Ein sauber strukturiertes Bundle aus Markdown Konzepten bringt oft mehr als das nächstgrößere Modell.

Sinnvoll wird OKF dort, wo mehrere Teams oder mehrere Agenten dieselbe Wissensbasis nutzen und Portabilität zählt. Für eine einzelne kleine Codebase reicht häufig schon eine SKILL.md oder ein Obsidian Vault. Wir helfen Teams, diese Entscheidung im konkreten Use Case zu treffen, und verbinden OKF bei Bedarf mit einem lokalen Stack aus Ollama, Embedding Modellen und einem RAG Framework.

Roland Golla und das NCA Team begleiten diesen Weg vom Prototyp bis in die Produktion. Unsere Schwerpunkte reichen vom Vibe Coding Consulting über Vibe Coding Best Practices bis zur Vibe Coding Beratung für Teams, die KI gestützte Entwicklung sicher und DSGVO konform aufsetzen wollen. Wir kombinieren offene Standards wie OKF mit einem souveränen, europäischen KI Stack.

Die wichtigsten Fragen zu OKF, seiner Funktionsweise und der Einordnung gegenüber MCP und proprietären Katalogen, kompakt beantwortet.