LLM Wiki Method vs Google OKF: What Is Shared and What Differs

Introduction

Teams that give AI agents curated context keep running into the same question: how should the knowledge be structured so that agents can read it reliably and so that other people and tools can use it too? Google Cloud published the Open Knowledge Format (OKF) on June 12, 2026, as an answer to that question. It formalizes a pattern that many practitioners already use: markdown files with YAML frontmatter, a type classification, reserved index and log files, and an agent that maintains the collection. This article compares that pattern with a personal LLM wiki that has been running for several months. You will see which parts are the same, which parts differ, and what a practical alignment would involve.

Summary

Google’s OKF v0.1 formalizes the LLM wiki pattern, which consists of markdown, YAML frontmatter, a type classification, index.md and log.md files, and maintenance by an agent, as an open, exchangeable format. A personal LLM wiki built on the same pattern adds an operating pipeline on top: compile, ingest, query, and lint. OKF does not prescribe that operating layer. Instead, it prescribes interoperability, meaning that any producer’s bundle can be read by any consumer.

Diagram

Key Facts

OKF facts

Primary sources are the Google Cloud blog and the GitHub SPEC.md file, checked on July 3, 2026.

• Announcement: June 12, 2026, Google Cloud. Spec version v0.1 (Draft). Repository: GoogleCloudPlatform/knowledge-catalog/okf
• Definition: “An open specification that formalizes the LLM-wiki pattern as a portable, interoperable format.” The format is vendor-neutral. It is not tied to a specific cloud, database, model, or framework, and reading, writing, and serving do not require a proprietary account or SDK.
• Structure: A directory of markdown files (a bundle) with YAML frontmatter.
  • The only required field is type. There is no central registry, so values such as “BigQuery Table,” “Metric,” or “Playbook” are free-form.
  • Recommended fields: title, description, resource (a URI for the real asset), tags, and timestamp (ISO 8601).
  • Extensibility: consumers MUST NOT reject a document because it contains fields they do not recognize.
• Concept ID: the file path inside the bundle with .md removed (tables/users.md becomes tables/users).
• Reserved filenames: index.md (no frontmatter allowed; a table of contents for progressive disclosure that can be generated automatically) and log.md (date-grouped work history, newest first). Neither can be used as a concept document.
• Links: standard markdown links, with absolute paths from the bundle root recommended. Consumers MUST tolerate broken links, because the spec assumes bundles that are still evolving or only partly generated.
• Distribution: a git repository (recommended), a tarball or zip, or a subdirectory of a larger repository.
• Three reference implementations: an enrichment agent that uses BigQuery metadata to generate OKF documents, a single-file HTML graph visualizer with no backend, and three sample bundles (GA4, Stack Overflow, and Bitcoin).
• Stated lineage: Karpathy’s LLM wiki idea, Obsidian vaults connected to agents, the AGENTS.md and CLAUDE.md conventions, and the data team practice of metadata-as-code. The spec formalizes the insight that LLMs can do the bookkeeping that humans abandon, such as cross-referencing and updating many files, without tiring.

Facts about our LLM wiki

The single source of truth is knowledge-management-system/docs/WIKI_SCHEMA.md.

• Structure: an Obsidian vault made of raw/ (immutable originals), wiki/ (knowledge pages owned by the LLM), sessions/ (automatic session records), output/ (query results), plus index.md and log.md.
• Frontmatter: title, type (entity, concept, source-summary, or comparison), tags, created, updated, sources (an array of raw/ origins), and source_count.
• Links: Obsidian wikilinks in the form [[page name]].
• Four operating pipelines: Ingest (merge raw into wiki), Query (read the index, navigate, answer, with no embeddings or RAG), Lint (detect orphan pages, contradictions, and thin pages), and Compile (turn session logs into entity pages).
• Automation: compile once a week and lint once a month, run by a launchd cron job on a Mac mini with work delegated to codex. A backfill converted 475 sessions into 25 wiki pages.
• Lineage: the same Karpathy LLM wiki idea. The schema example includes a karpathy-llm-wiki.md source-summary page. The two systems are siblings that grew independently from the same root.

Comparison table

Axis	Our LLM Wiki (KMS)	Google OKF v0.1
Nature	Operating system (personal knowledge pipeline)	Exchange format (open spec)
Knowledge unit	Markdown + YAML frontmatter	Same
type classification	Fixed set of 4 (entity/concept/source-summary/comparison)	Free-form string; only type is required
index.md / log.md	Present (catalog / chronological log)	Present (specified through reserved filenames)
Links	Obsidian wikilinks [[...]]	Standard markdown links (renderable on GitHub)
Source tracking	sources: pointing to raw/ files (immutable original layer)	resource: pointing to a live asset URI (no raw layer)
Retrieval	Read the index, then the pages (no embeddings/RAG)	Unspecified by the spec; left to the consumer (positioned as “curated, read and updated directly by the agent” in contrast to RAG)
Operating workflow	Four operations (compile, ingest, query, lint) plus cron automation	Outside the spec (reference implementations only)
Target knowledge	Personal session logs, articles, troubleshooting notes	Organizational data asset metadata (BigQuery tables, metrics, playbooks)
Interoperability	None (single user, Obsidian-specific syntax)	Core value (producer/consumer separation, vendor neutrality)
Governance	Personal SSOT document	Open spec v0.1, with explicit backward-compatible evolution

Insights

1. Independent convergence is a form of validation. The type frontmatter, the progressive disclosure of index.md, the chronological log.md history, and the division of labor in which the LLM owns the wiki and humans curate it all match at the level of detailed conventions. Our design has run since April 2026, and Google standardized a matching design in June. Two independent efforts arriving at the same file-based markdown wiki for the same problem, which is curated context for agents, suggests the pattern is more than a trend. It may be close to a structural answer. For content or lectures, this is material for a case study of an individual setup that reached the same conclusion about two months before Google.

2. The core difference is system versus format. Our wiki defines how knowledge is created and maintained, including the compile and lint cron jobs, delegation to codex, and cost tracking. OKF defines how knowledge is exchanged, through minimal required fields, tolerance of broken links, and preservation of unknown fields. These are not competing approaches. They sit at different layers of a stack. The layer OKF leaves out, operations, is our asset, and the layer we lack, interoperability, is what OKF contributes.

3. Practical implication: alignment is cheap, and the benefit is optional. To make our wiki OKF-compatible, the changes are roughly: (a) convert wikilinks to standard markdown links, (b) keep sources: and add resource: and timestamp:, and (c) leave type as is, since it is already a free-form string. In a single-user Obsidian setup, interoperability has no practical benefit yet, so the alignment should wait until a bundle needs to go to outside parties such as collaborators, other agents, or a public repository. There is no reason to change anything now.

4. OKF’s resource: field is a good idea we do not have. Our sources: field only points to files in the vault’s raw/ folder. OKF’s resource: points to live assets such as console URLs and API endpoints. It turns a wiki page into a shadow document for a real system object. Entity pages, such as an n8n instance or a Supabase project, are worth adopting it for.

Sources

Primary sources (all checked July 3, 2026)

• Google Cloud Blog: How the Open Knowledge Format can improve data sharing (original announcement, design principles, lineage, and reference implementations)
• OKF SPEC.md, GoogleCloudPlatform/knowledge-catalog (v0.1 Draft spec text: required and recommended fields, reserved filenames, link rules, MUST and SHOULD clauses)
• Google Cloud Tech announcement post (the official phrasing “formalizes the LLM-wiki pattern”)
• Local SSOT: ~/Projects/knowledge-management-system/docs/WIKI_SCHEMA.md and README.md (our LLM wiki schema and operating status)

Secondary sources (cross-checks, all checked July 3, 2026)

• MarkTechPost: Google Cloud Introduces OKF (confirms the June 12, 2026 announcement date)
• StartupHub.ai: Google OKF Explained
• Search Engine Journal: Google Cloud Announces OKF

Uncertainty notes: The OKF spec document does not state a license. The repository-level license needs separate verification. The June 12, 2026 date comes from secondary sources and was not checked against the publication date of the Google blog post.

Bottom line

Google’s OKF and a personal LLM wiki share the same file-based design: markdown, YAML frontmatter, a type field, reserved index and log files, and agent maintenance. They differ in scope. OKF standardizes how knowledge is exchanged between producers and consumers and leaves operations out of scope. A personal wiki with compile, ingest, query, and lint pipelines covers operations but has no interoperability. The two are complementary layers of one stack, not competitors. For a single-user Obsidian setup, the evidence supports keeping the current design. Adopting OKF conventions makes sense only when a bundle must leave the local environment, and the required changes are small.