Hector-Bot db3ddc9638 ingest(blog)+wiki(concepts/llm): OKF v0.1 — Google formalisiert LLM-Wiki-Pattern

Pit-Share in OME Topic 13 #6697 (Reddit-Post r/WebAfterAI).
OKF v0.1 ist die offizielle Spezifikation des Musters, das wir bereits umsetzen.
Neue Konzeptseite open-knowledge-format-okf.md mit Frontmatter-Schema,
Bundle-Struktur, 3 Workflows, Citations-Konvention, Versioning.
Cross-Ref in llm-knowledge-base.md + index/log Updates.

2026-06-16 13:52:24 +02:00

10 KiB

Raw Blame History

created

updated

sources

Open Knowledge Format (OKF) v0.1 — Google Cloud

Was: Google Cloud hat am 2026-06-12 das Open Knowledge Format (OKF) veröffentlicht — eine offene Spezifikation, die Karpathys LLM-Wiki-Pattern zu einem portablen, interoperablen Format formalisiert. Quelle: Pit-Share in OME Topic 13 #6697 (Reddit-Post r/WebAfterAI). Status: v0.1 — Spezifikation öffentlich, Reference Implementation auf GitHub verfügbar.

TL;DR

OKF ist kein Runtime, kein SDK, kein Agent-Framework, kein MCP-Konkurrent. MCP ist ein Protokoll für Agenten, um Tools aufzurufen und Aktionen auszuführen. OKF ist das gegenüberliegende Ende: eine Konvention, wie man statisches Wissen aufschreibt, damit jeder Agent es lesen kann.

In einem Satz: Karpathys LLM-Wiki-Pattern (raw → LLM → wiki → Q&A) wird von Google formalisiert, damit verschiedene Tools das gleiche Bundle lesen können ohne Translation-Layer.

Bundle-Struktur

my_bundle/
├── index.md          # optional: directory listing for progressive disclosure
├── log.md            # optional: chronological history of changes
├── datasets/
│   └── sales.md
└── tables/
    ├── orders.md
    └── customers.md

Jedes .md-File = ein Concept
Concepts verlinken sich via Standard-Markdown → Graph von Beziehungen
index.md = plain directory listing (kein Frontmatter) für progressive disclosure
log.md = chronologische Änderungshistorie (optional)

Drei Designprinzipien

Minimally opinionated. Nur ein Pflichtfeld pro Concept (type). Alles andere (Types-Taxonomie, weitere Felder, Body-Sections) bleibt dem Producer überlassen. Die Spec definiert die Interoperabilitäts-Oberfläche, nicht das Content-Model.
Producer/Consumer independence. Wer schreibt und wer liest sind sauber getrennt. Bundle von Menschen hand-geschrieben → von AI-Agent konsumiert. Bundle von Metadata-Pipeline generiert → in Visualizer gebrowst. Bundle von LLM A synthetisiert → von LLM B abgefragt. Format = Vertrag; Tooling an beiden Enden unabhängig austauschbar.
Permissive Conformance. Consumers MÜSSEN unbekannte Types, fehlende Felder und broken Links tolerieren statt das Bundle abzulehnen. OKF soll nutzbar bleiben, wenn Bundles wachsen, refaktoriert oder teilweise von Agenten generiert werden.

Conformance-Regel (SPEC §9)

Ein Bundle ist OKF v0.1 konform wenn:

Jedes non-reserved .md-File hat einen parseable YAML-Frontmatter-Block
Jeder Frontmatter-Block hat ein non-empty type-Feld
index.md und log.md sind die einzigen erlaubten Frontmatter-Dateien (reserviert)
Consumers dürfen Bundle NICHT ablehnen wegen unbekannter Types oder fehlender index.md

Permissive consumption model is intentional. — OKF wächst mit den Bundles mit.

Frontmatter-Schema

Pflicht

Feld	Typ	Zweck
`type`	String (kurz)	Identifiziert Concept-Art. Consumers nutzen für Routing, Filter, Darstellung. Beispiele: `BigQuery Table`, `API Endpoint`, `Metric`, `Playbook`, `Reference`.

Type-Werte sind NICHT zentral registriert. Producers wählen deskriptive Werte; Consumers behandeln unbekannte Types als generic concepts.

Empfohlen (Prioritäts-Reihenfolge)

Feld	Zweck
`title`	Menschenlesbarer Titel
`description`	Kurzbeschreibung
`resource`	Verweis auf zugrundeliegende Quelle (z. B. `bigquery://project.dataset.table`)
`tags`	Themen-Tags für Filterung
`timestamp`	Letztes Update / Erstellungsdatum

Producers können weitere Keys frei hinzufügen. Consumers MÜSSEN unbekannte Felder tolerieren.

Citations (SPEC §8)

Wenn ein Concept-Body Claims aus externem Material macht, sollen diese unter # Citations-Heading am Dokumentende gelistet sein, nummeriert:

# Citations

1. https://example.com/paper-x
2. https://arxiv.org/abs/2024.12345
3. references/internal-doc.md  (lokale Spiegelung)

Citation-Links können sein:

Absolute URLs zu externen Quellen
Bundle-relative Pfade zu anderen Concepts
Pfade in references/-Subdirectory, das externes Material als first-class OKF Concepts spiegelt (empfohlen für Stabilität)

Drei Workflows zum Loslegen

Workflow 1: Hand-author a small bundle

Schnellster Einstieg. Manuell 3-5 Markdown-Files für eine "messy Ecke" des Systems schreiben, Agent drauf zeigen. 10 Minuten, zeigt Wert und Limits in einem Durchgang. → Empfohlener Startpunkt.

Workflow 2: Generate from existing schema

Wenn Schema zu groß zum Hand-Schreiben: Pipeline, die bestehende Strukturen (DB-Schemas, API-Specs, Notion-Wikis) als OKF-Bundle exportiert. Achtung: Citations-Disziplin nötig, sonst verliert Bundle an Wert.

Workflow 3: Consume a bundle without blowing your context window

Große Bundles komplett in Context laden = teuer + noisy. OKF-Lösung: optional index.md als plain directory listing. Agent liest Index, folgt Links, zieht Concepts on-demand.

Versioning (SPEC §11)

Document spezifiziert OKF version 0.1
Künftige Revisionen: <major>.<minor>
Bundles deklarieren Version via okf_version: "0.1" im bundle-root index.md-Frontmatter (einzige Stelle, wo index.md Frontmatter tragen darf)
Consumers, die deklarierte Version nicht verstehen, sollen best-effort consumption versuchen statt das Bundle abzulehnen

Reference Implementation + Sample Bundles

Repo: github.com/GoogleCloudPlatform/knowledge-catalog

Drei ready-to-browse Sample Bundles (vom Reference Agent produziert, als lebende Beispiele committed):

GA4 e-commerce — Google Analytics BigQuery Demo Dataset
Stack Overflow — Pantheon Marketplace
Bitcoin public datasets — BigQuery Public Datasets

Google Cloud Knowledge Catalog wurde aktualisiert, um OKF zu ingestieren und an Agents auszuliefern.

OKF vs. andere Formate (SPEC §10)

Format	Fokus	OKF-Differenz
Karpathy LLM-Wiki	Pattern, kein Standard	OKF formalisiert das Pattern
Obsidian	Wikibase für Menschen	OKF ist agent-first, permissiver
Notion	Wikibase + Block-Editor	OKF ist plain markdown, kein Tooling-Lock-in
Hugo	Static site generator	OKF ist reines Content-Format
AGENTS.md	Schema-on-Read für AI-Agents	OKF pinnt Regeln fest, AGENTS.md ist freier
CLAUDE.md	Agent-Kontext	OKF ist konzept-orientiert, CLAUDE.md ist Workflow-orientiert
MCP	Tool-Calling-Protokoll	OKF ist statisches Wissen, MCP ist Aktionen

OKF unterscheidet sich primär durch Spezifikation — Interoperabilität ohne Tooling-Diktat.

Direkte Konsequenzen für unser RamaDama-Repo

Unser Repo knowledge-base ist exakt nach Karpathys LLM-Wiki-Pattern aufgebaut (siehe ../llm/llm-knowledge-base.md). Google macht das Pattern jetzt zum formalen Standard. Konkrete Implikationen:

Was wir bereits OKF-konform haben

Frontmatter-Standards mit type als Pflichtfeld in raw-Files ✅
wiki/concepts/, wiki/teams/, wiki/tools/, wiki/architecture/, wiki/decisions/ als konzept-orientierte Verzeichnisstruktur ✅
wiki/log.md als chronologischer Append-Only Changelog ✅
wiki/index.md als Auto-Generated Catalog (Fakten) + wiki/ideas.md (Subconscious Outcomes) — wir haben sogar zwei index-Dateien, OKF erlaubt das via optional index.md ✅
Cross-References via [[seite.md]] — Markdown-Standard ✅
Producer/Consumer-Trennung: Raw → Subagent-Prozessor → Wiki, Tooling unabhängig ✅

Was wir noch ergänzen könnten (nicht zwingend)

# Citations-Section am Ende jedes Wiki-Pages mit nummerierten externen Links (OKF-Standard, aber optional)
okf_version: "0.1" im root-wiki/index.md-Frontmatter deklarieren (signalisiert Konformität für externe Reader)
Bundle-Root-Identifier: Klare Konvention, dass wiki/ als OKF-Bundle-Root gilt (oder knowledge-base/ direkt)

Strategische Implikation

Validierung: Wir sind mit unserer Architektur-Wahl nicht alleine; Google pusht dasselbe Pattern in den Markt → potentiell mehr Tooling-Support (Lint, Visualizer, Search)
Migration-Risk gering: Unsere Struktur ist bereits kompatibel, Migration wäre additiv (Citations-Section) nicht destruktiv
Opportunität: Wir könnten mit minimaler Ergänzung OKF-konform sein und von zukünftigen OKF-Tools profitieren

Externe Primärquellen

OKF Ankündigung (Google Cloud Blog, 2026-06-12): https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
OKF SPEC v0.1: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
OKF Reference Implementation Repo: https://github.com/GoogleCloudPlatform/knowledge-catalog
Karpathy LLM-Wiki Original-Gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Search Engine Journal Coverage: https://www.searchenginejournal.com/google-cloud-announces-the-open-knowledge-format/579253
Note.com Deep-Dive (JP/EN): https://note.com/ai_driven/n/n8e2726b98180
Reddit Original-Post: https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/
Pit-Share in OME: Topic 13 #6697

10 KiB Raw Blame History