Open Knowledge Format (OKF): Das offene Format für KI-Wissen

Open Knowledge Format (OKF) ist Google Clouds offene, herstellerneutrale Entwurfsspezifikation, um Unternehmenswissen als verlinkte Markdown-Dateien mit YAML-Metadaten zu verpacken. Menschen und KI-Agenten können denselben portablen Kontext ohne proprietäres SDK lesen. Stand 12. Juli 2026 ist OKF v0.1 Draft die aktuelle Version.

Zwei Abgrenzungen sind wichtig: Dieses OKF ist nicht die Open Knowledge Foundation, die dasselbe Kürzel verwendet. Und OKF ist weder Datenbank noch Modell, Retrieval Engine, Agentenprotokoll oder bestätigtes Google-Ranking-Signal. Es ist ein bewusst kleines Austauschformat für das Wissen, das solche Systeme verwenden.

Welches Problem löst OKF?

Den meisten Unternehmen fehlt nicht Wissen, sondern zusammensetzbarer Kontext. Die Definition eines aktiven Kunden steht im BI-Dashboard, die Berechnung in SQL, die Ausnahme in Slack, der API-Vertrag in OpenAPI, der Incident-Ablauf in Confluence und die Begründung im Kopf eines Senior Engineers.

Ein Agent kann diese Systeme durchsuchen, doch jede Integration liefert ein anderes Format. Für jeden neuen Assistenten entstehen Connectoren, Chunking, Metadaten-Mapping und Berechtigungslogik erneut. Beim Wechsel von Katalog oder Modell bleibt das kuratierte Wissen oft im alten Tool gefangen. Google Cloud stellte OKF am 12. Juni 2026 vor, um das wiederkehrende „LLM-Wiki“-Muster zu formalisieren: eine gemeinsame Markdown-Bibliothek, die Menschen und Agenten zusammen pflegen. Der offizielle Google-Cloud-Beitrag beschreibt die fehlende Schicht ausdrücklich als Format statt als weiteren Service.

Wie funktioniert das Open Knowledge Format?

Ein OKF-Knowledge Bundle ist ein Verzeichnisbaum. Jede dauerhafte Wissenseinheit ist ein Konzeptdokument in einer UTF-8-Markdown-Datei. Sein Pfad ohne .md ist die Konzept-ID. Normale Markdown-Links machen aus den Konzepten einen Graphen; Ordner liefern gleichzeitig eine verständliche Hierarchie.

unternehmenswissen/
├── index.md
├── log.md
├── metriken/
│   ├── index.md
│   └── monatlich-wiederkehrender-umsatz.md
├── systeme/
│   └── billing-api.md
└── playbooks/
    └── fehlgeschlagene-zahlung.md

Ein Konzept verbindet kleine, abfragbare Metadaten mit lesbarem Inhalt:

---
type: Metric
title: Monthly Recurring Revenue
description: Vertraglich wiederkehrender, monatlich normalisierter Umsatz.
resource: https://analytics.example.com/mrr
tags: [finance, saas, board]
timestamp: 2026-07-12T09:00:00Z
---

# Definition

MRR enthält aktive Abos und keine einmaligen Leistungen.
Die Rückerstattungslogik steht im [Billing-Playbook](/playbooks/refunds.md).

# Citations

[1] [Finance Policy](https://docs.example.com/finance/mrr)

Nur type ist Pflicht. title, description, resource, tags und timestamp werden empfohlen. Produzenten dürfen eigene Felder ergänzen; Konsumenten sollen unbekannte Felder erhalten. Diese lockere Vereinbarung ist die zentrale Designentscheidung der offiziellen OKF-v0.1-Spezifikation.

Welche drei Regeln gelten für ein OKF-v0.1-Bundle?

1. Jede nicht reservierte Markdown-Datei besitzt parsebares YAML-Frontmatter.
2. Jeder Metadatenblock enthält ein nicht leeres type. Eine zentrale Typenregistrierung gibt es nicht.
3. Reservierte Dateien folgen ihrer definierten Struktur, wenn sie vorhanden sind. index.md listet ein Verzeichnis zur schrittweisen Navigation; log.md dokumentiert datierte Änderungen. Beide sind optional.

Fast alles andere ist weiche Empfehlung. Ein konformer Konsument soll fehlende optionale Felder, unbekannte Typen, eigene Schlüssel, kaputte Querverweise und fehlende Indexdateien tolerieren. Eine teilweise generierte, laufend veränderte Wissensbasis soll brauchbar bleiben statt komplett abgelehnt zu werden.

Was ist OKF – und was nicht?

OKF vs. RAG vs. MCP vs. OpenAPI vs. llms.txt

Das sind Schichten, keine Ersatzprodukte. Eine sinnvolle Architektur ist häufig OKF mit Retrieval und Tools.

Ein pragmatischer Stack: Fachverantwortliche bearbeiten OKF in Git, CI validiert es, ein RAG-System indexiert das Bundle, ein MCP-Server stellt Suche und Live-Systeme bereit. Der Agent lädt wenige Konzepte und folgt Links nur bei Bedarf. OKF ist die dauerhafte Quelle, RAG die Auswahl und MCP die Runtime-Tür.

"OKF löst Retrieval und Governance nicht. Es löst zuerst die leisere Frage: Überlebt dein Wissen das Tool, das es erzeugt hat, und bleibt es für den nächsten Menschen oder Agenten lesbar?"

Wo entsteht echter geschäftlicher Nutzen?

• Agentenkontext überlebt Anbieterwechsel. Der Wechsel von Modell, Vector Database, Katalog oder Agent-Framework erfordert keine komplette Neuschreibung.
• Wissen wird wie Code geprüft. Pull Requests, Diffs, Blame, CODEOWNERS, Tags und Rollbacks funktionieren ohne neue Governance-Oberfläche.
• Onboarding und Incident Response werden schneller. Dieselben Konzepte speisen Assistenten, rendern als Doku und bleiben im Ausfall direkt lesbar.
• Ein gemeinsames Exportziel. Kataloge, Wikis und Repositories produzieren OKF, statt jeden Konsumenten einzeln anzubinden.
• Kontext wird bedarfsgerecht geladen. Der Agent liest zuerst index.md und öffnet nur relevante Konzepte.

Der Business Case ist stark, wenn mehrere Agenten denselben kuratierten Kontext brauchen, Wissen oft wechselt und Lock-in oder Auditierbarkeit zählen. Für eine statische FAQ und einen Chatbot reichen oft normale Dokumentation und gute Suche.

Was gehört in ein OKF-Bundle?

Beginne mit wertvollen, dauerhaften Konzepten statt mit einem Bulk-Export aller alten Texte:

• Geschäftsmetriken, Definitionen, Owner, Rechenregeln und Ausnahmen;
• Systeme, APIs, Datensätze, Tabellen, Events und Abhängigkeiten;
• Produktregeln, Architekturentscheidungen, Runbooks und Eskalationswege;
• Compliance-Kontrollen, Evidenzorte, Richtlinien und Prüftermine;
• Support-Playbooks mit klaren Grenzen für automatisierte Aktionen.

Secrets, personenbezogene Daten, Roh-Chats, Verträge und Credentials gehören nicht ungeprüft in ein Git-lesbares Bundle. „Einfache Dateien“ sind zugleich Interoperabilitäts- und Datenleckvorteil. Klassifizierung, Least Privilege, Retention und Review bleiben Pflicht.

Wie führt man OKF im Unternehmen ein?

1. Eine entscheidungsreiche Domäne wählen. Umsatzmetrik, Supportprozess oder Produktionsservice statt „alles Wissen“.
2. Quellen und Verantwortliche erfassen. Autoritative Quelle, Owner, Sensitivität, Update-Auslöser und Konsumenten pro Konzept.
3. Ein kleines lokales Profil definieren. Fünf bis zehn Typen, Pflichtfelder, Namen und Body-Templates – klar als eigene Erweiterung markiert.
4. Erstes Bundle generieren und kuratieren. Exporte und LLMs erstellen Entwürfe; Fachverantwortliche lösen Widersprüche, entfernen Secrets und genehmigen Aussagen.
5. In CI validieren. YAML, type, reservierte Dateien, doppelte Ressourcen, Links, Timestamps, sensible Muster und Owner prüfen.
6. Einen Konsumenten anbinden. Bundle für RAG indexieren oder als Agentenressource bereitstellen. Korrektheit, Quellennachweis, Retrieval-Präzision und Aktualisierungszeit messen.
7. Betriebsmodell festlegen. Review, Veralterung, Zugriffsgrenzen und Löschung aus Indizes und Caches klären.

Was lässt OKF ungelöst?

• Berechtigungen: Keine Dokument- oder Feld-ACLs in der Spezifikation.
• Identität und Lifecycle: Der Pfad ist die ID; Renames brauchen eigene Migrationsregeln.
• Wahrheit und Aktualität: Konformität beweist Struktur, nicht Richtigkeit, Vollständigkeit oder Sicherheit.
• Beziehungssemantik: Links sind gerichtet, aber untypisiert; „abhängig von“ oder „ersetzt“ stehen in Prosa.
• Hohe Schreibfrequenz: Git eignet sich für Review, aber schlecht für operativen Zustand mit vielen gleichzeitigen Schreibern.
• Discovery: Ein Consumer muss das Bundle weiterhin kennen und erreichen. OKF macht es nicht automatisch öffentlich auffindbar.

Darum würden wir OKF als kuratierte Wissensschicht pilotieren, nicht als neues System of Record ausrufen. Operative Daten bleiben in operativen Systemen; OKF erklärt Bedeutung, Beziehungen und richtige Nutzung.

Verbessert OKF SEO oder LLM-Zitate?

Nicht automatisch. Weder Ankündigung noch v0.1-Spezifikation definieren OKF als Crawling-, Ranking- oder Zitationssignal. Ein öffentliches /okf/-Verzeichnis kann einem bereits informierten Consumer helfen, doch höhere Google-Rankings, AI Overviews oder ChatGPT-Zitate lassen sich damit nicht versprechen.

Für öffentliche Sichtbarkeit zählen weiterhin indexierbares HTML, klare Direktantworten, stabile URLs, benannte Autoren, Primärquellen, strukturierte Daten, interne Links und echte eigene Analyse. OKF kann ein zusätzlicher maschinenlesbarer Export sein, nicht der Ersatz für die Website.

Sollte dein Unternehmen OKF jetzt einführen?

Unsere Empfehlung im Juli 2026: ein begrenzter, reversibler Pilot mit 20–50 Konzepten, einer Owner-Gruppe, einem Agenten-Use-Case und einem messbaren Workflow. Ändert sich das Format, sind Markdown und YAML günstig migrierbar. Scheitert der Pilot, bleiben die kuratierten Dokumente wertvoll.

Primärquellen

1. Google Cloud: Introducing the Open Knowledge Format
2. Offizielle OKF-v0.1-Spezifikation
3. Offizielles OKF-Repository mit Referenztools
4. Offizielle Beispiel-Bundles
5. Andrej Karpathys LLM-Wiki-Muster
6. Apache-2.0-Lizenz von OKF

Status geprüft am 12. Juli 2026. Vor einem langfristigen Unternehmensprofil Version und offene Issues erneut prüfen.