hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md
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

type source_url retrieved title author subreddit score tags okf_announcement okf_spec okf_repo pit_share_ome_topic pit_share_message_id
blog https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/ 2026-06-16 Google Cloud just released OKF. Think MCP, but for knowledge instead of tools and 3 ways to use it. u/OnshapePTC (PTC) r/WebAfterAI null
okf
google-cloud
open-knowledge-format
llm-wiki
karpathy
knowledge-base
mcp
agent-knowledge
https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md https://github.com/GoogleCloudPlatform/knowledge-catalog 13 6697

Google Cloud just released OKF. Think MCP, but for knowledge instead of tools

Pit-Share: OME Topic 13 #6697, 2026-06-16 11:48 UTC Pit-Kommentar: Pit hat den Reddit-Link ohne zusätzlichen Kommentar geteilt — drei 🚨🔥👉-Marker in seiner bisherigen Pit-Kommunikation signalisieren "relevantes neues Wissen, sofort wikifyen". Primärquellen:

Warum das Pit interessiert (unsere direkte Relevanz)

Unser RamaDama-Repo (knowledge-base) ist exakt nach dem Muster aufgebaut, das OKF jetzt formalisiert. Die AGENTS.md zitiert Karpathys LLM-Wiki-Gist als konzeptuelle Grundlage, und unsere Frontmatter-Standards (siehe AGENTS.md Section "Frontmatter Standards") sind strukturell kompatibel mit OKF. Pit hat in den letzten Wochen intensiv an der Wiki-Wartung gearbeitet — eine offizielle Standardisierung dieser Pattern durch Google ist für uns direkt wertvoll: Validierung + potentieller Konvergenzpunkt für Tooling + potentiell Migrationspfad zu mehr Provider-Support.

TL;DR (Reddit-Post v0.1-Zusammenfassung)

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

In einem Bildschirm:

  • Was: Konvention für statisches Wissen als Directory aus Markdown-Dateien + YAML-Frontmatter
  • Nicht: Runtime, SDK, Framework, MCP-Konkurrent
  • Vergleichbar mit: Obsidian, Notion, Hugo, allen LLM-Wiki-Patterns der letzten 12 Monate
  • Differenz: OKF pinnt die nötigen Konventionen fest, damit verschiedene Tools das gleiche Bundle lesen können ohne Translation-Layer

Was ist ein "Bundle"?

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 gegenseitig via Standard-Markdown-Links. Das ganze Bundle ist ein Graph von Beziehungen.

Drei Designprinzipien (Google Cloud Blog)

  1. Minimally opinionated. OKF verlangt genau eine Sache pro Concept: ein type-Feld. Alles andere (welche Types existieren, welche weiteren Felder, welche Body-Sections) bleibt dem Producer überlassen. Die Spec definiert die Interoperabilitäts-Oberfläche, nicht das Content-Model.
  2. Producer/Consumer independence. Wer schreibt und wer liest sind sauber getrennt. Bundle von Menschen hand-geschrieben → von AI-Agent konsumiert. Bundle von Metadata-Export-Pipeline generiert → in Visualizer gebrowst. Bundle von einem LLM synthetisiert → von einem anderen abgefragt. Format = Vertrag; Tooling an beiden Enden unabhängig austauschbar.
  3. 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.

Was ein Concept tragen muss (aus SPEC.md)

Frontmatter

Pflicht:

  • type — kurzer String, identifiziert die Art des Concepts. Consumers nutzen es für Routing, Filter, Darstellung. Beispiele: BigQuery Table, BigQuery Dataset, API Endpoint, Metric, Playbook, Reference.

Empfohlen (in Prioritäts-Reihenfolge):

  • title
  • description
  • resource
  • tags
  • timestamp

Type-Werte sind nicht zentral registriert. Producers SOLLEN deskriptive/self-explanatory Werte wählen; Consumers MÜSSEN unbekannte Types graceful behandeln (typischerweise als generic concepts).

Citations (Section 8)

Wenn ein Concept-Body Claims aus externem Material macht, sollten diese unter # Citations Heading am Dokumentende gelistet sein, nummeriert. Citation-Links können absolute URLs, bundle-relative Pfade oder Pfade in references/-Subdirectory sein, das externes Material als first-class OKF Concepts spiegelt.

Conformance-Regel (Section 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)

Alle anderen Constraints sind soft guidance. Consumers dürfen ein Bundle NICHT ablehnen wegen: unbekannter Types, fehlender index.md. Permissive consumption model is intentional.

Versioning (Section 11)

  • Document spezifiziert OKF version 0.1
  • Künftige Revisionen: <major>.<minor>-Format
  • Bundles KÖNNEN OKF-Version im bundle-root index.md Frontmatter deklarieren via okf_version: "0.1"
  • Consumers, die deklarierte Version nicht verstehen, SOLLEN best-effort consumption versuchen statt das Bundle abzulehnen

Drei Wege, OKF zu nutzen (Reddit-Post-Highlights)

"How to pick if you only try one: Start with workflow 1. Hand-author a five-file bundle for one messy corner of your system and point your agent at it. It takes ten minutes, it is just markdown, and it shows you the actual value (and the actual limits) before you invest in generating or consuming at scale."

Workflow 1: Hand-author a small bundle

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

Workflow 2: Generate from existing schema

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

Workflow 3: Consume a bundle without blowing your context window

Große Bundles komplett in den Context zu laden ist teuer und noisy. OKFs Antwort: optional index.md — plain directory listing (ohne Frontmatter), das dem Agent zeigt, was existiert. Agent liest Index, folgt Links, zieht einzelne Concepts on-demand.

Google Cloud Knowledge Catalog Update

Google Cloud hat den Knowledge Catalog aktualisiert, um OKF zu ingestieren und an Agents auszuliefern. Drei ready-to-browse Sample Bundles werden mitgeliefert:

Diese Bundles werden vom Reference Agent produziert und im Repo als lebende Beispiele konformen OKFs committed.

Relationship to other formats (Section 10)

OKF ist absichtlich nahe an mehreren etablierten Patterns:

  • Karpathy LLM-Wiki — gleiche Grundidee (raw → LLM → wiki → Q&A)
  • Obsidian / Notion / Hugo — Markdown-First-Ansatz
  • AGENTS.md — Schema-on-Read für AI-Agent-Konsum
  • CLAUDE.md — Agent-Kontext-Konvention

OKF unterscheidet sich primär durch Spezifikation — pinnt die nötige Regelmenge fest für Interoperabilität, ohne Tooling zu diktieren.

Konkrete nächste Schritte für uns

  1. Schema-Review: Stimmt unser AGENTS.md-Frontmatter-Schema mit OKF v0.1 überein? (type als Pflichtfeld, title/description/tags empfohlen — check ✅)
  2. # Citations-Section einführen: Optional, aber OKF-Standard. Citations am Ende jedes Wiki-Pages mit nummerierten Links.
  3. okf_version: "0.1" in root-index.md deklarieren (einzige Stelle, wo index.md Frontmatter haben darf).
  4. Producer/Consumer-Trennung prüfen: Ist unsere Wiki-Pipeline wirklich sauber getrennt? Raw → Subagent-Prozessor → Wiki. Ja, das passt.
  5. Tooling-Optionen evaluieren: Reference Implementation unter github.com/GoogleCloudPlatform/knowledge-catalog — Lint-Tools, Bundle-Generators, Visualizer. Beobachten.

Externe Primärquellen