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

Open Knowledge Format (OKF) ist Google Clouds offene, herstellerneutrale Spezifikation, 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. August 2026 ist OKF v0.2 die aktuelle Version; sie ersetzt v0.1.

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.

Wenn du statt des Formats eine konkrete Umsetzung bewertest, prüft unser OpenKB Review mit RAG-Vergleich einen Open-Source-Knowledge-Compiler, die unabhängige Evidenz und die noch fehlenden Enterprise-Kontrollen.

Geht es dir um die breitere Systemfrage, wie Mitarbeitende und Agenten eine gesteuerte Quelle der Wahrheit teilen, behandelt unser Architekturleitfaden für ein KI-fähiges Unternehmenswiki kanonisches Wissen, Berechtigungen, Retrieval, kontrollierte Änderungen und einen 30-Tage-Pilot.

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]
status: stable
generated: { by: human:finance-owner, at: 2026-08-12T09:00:00Z }
verified: { by: human:controller, at: 2026-08-12T10:00:00Z }
stale_after: 2026-11-12
sources:
  - id: finance-policy
    resource: https://docs.example.com/finance/mrr
    title: Finance Policy
---

# Definition

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

[^finance-policy]: Finance Policy

Nur type ist immer Pflicht. title, description, resource und tags bleiben empfohlen. Version 0.2 ergänzt optionale Felder für Herkunft, Vertrauen, Lifecycle, Aktualität und Berechnungen. Produzenten dürfen weiterhin eigene Schlüssel ergänzen; Konsumenten sollen unbekannte Felder erhalten. Diese lockere Vereinbarung bleibt die zentrale Designentscheidung der offiziellen OKF-v0.2-Spezifikation.

Welche drei Regeln gelten für ein OKF-v0.2-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 hat sich von OKF v0.1 zu v0.2 geändert?

Version 0.2 behält die drei Konformitätsregeln, macht aber von Agenten gepflegtes Wissen besser prüfbar. Dafür kommen optionale Feldfamilien statt eines zentralen Schemas hinzu:

• Herkunft: sources erfasst die Materialien hinter einem Konzept. Jede Quelle kann stabile id, Titel, Autor, Nutzungszahl und Änderungsdatum tragen. Markdown-Fußnoten können die Quellen-ID für die Zuordnung einzelner Aussagen nutzen.
• Vertrauen: generated zeigt, wer oder was den aktuellen Inhalt erzeugt hat; verified dokumentiert spätere Prüfungen. Consumer leiten daraus die Stufen ungeprüft, maschinell bestätigt oder von Menschen geprüft ab. Das sind Hinweise, keine Zugriffskontrolle.
• Lifecycle und Aktualität: status kann draft, stable oder deprecated sein. stale_after setzt ein absolutes Datum, ab dem ein Consumer warnen oder ablehnen sollte.
• Attestierte Berechnungen: Der neue Konzepttyp Attested Computation verbindet eine freigegebene Berechnung mit Runtime, typisierten Parametern, Executor, Receipt-Feldern und deterministischem Attester. OKF speichert Vertrag und Prüfweg, führt aber nichts selbst aus.

Zwei Feldänderungen erfordern Migration. generated.at ersetzt timestamp aus v0.1; sources im Frontmatter ersetzt eine # Citations-Liste im Text. Ein v0.2-Consumer darf beide alten Formen als Fallback lesen. Teams können also schrittweise migrieren. Die Root-Datei index.md darf nun okf_version: "0.2" deklarieren.

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.
• Abfragbares Vertrauen und Aktualität. Consumer unterscheiden ungeprüfte von menschlich geprüften Inhalten und warnen nach dem stale_after-Datum.

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;
• freigegebene Berechnungen mit typisierten Parametern, Ausführungsbelegen und deterministischen Prüfungen;
• 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, Actor- und Datumsformate, Quellen-IDs, veraltete Konzepte, Berechnungsverträge, 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.
• Umbenennung und Löschung: Der Pfad ist die ID; Verschiebungen brauchen eigene Migrationsregeln. v0.2 kennt deprecated, definiert aber keine Löschweitergabe oder Tombstones.
• Wahrheit und Durchsetzung: Konformität und Vertrauensfelder beweisen weder Richtigkeit noch vollständige, tatsächlich ausgeführte Reviews.
• 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.2-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 August 2026: ein begrenzter, reversibler Pilot mit 20–50 Konzepten, einer Owner-Gruppe, einem Agenten-Use-Case und einem messbaren Workflow. Nutze die v0.2-Felder für Herkunft und Aktualität dort, wo sie eine reale Betriebsfrage beantworten, und bewahre das Quellmaterial. Ä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.2-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. August 2026. Vor einem langfristigen Unternehmensprofil Version und offene Issues erneut prüfen.