Building a Local Knowledge Base in Google’s Open Knowledge Format (OKF) — Extended Brain (2026)

Bibliographic Reference

Extended Brain. (2026, June 16). Building a local knowledge base in Google’s Open Knowledge Format (OKF). Extended Brain (Substack). https://extendedbrain.substack.com/p/post-202209913

Core Argument

The article describes a workflow for building and maintaining a local knowledge base using an AI agent (Nous Hermes / Xiaomi Mimo LLM), implementing what it calls Karpathy’s “LLM Wiki” pattern: a directory of interlinked markdown files with YAML frontmatter and wikilinks, organized into raw sources, wiki pages, and a schema document. The central thesis is that this pattern — no database, no vector store, just structured markdown files that an AI agent reads and writes — produces knowledge that is portable, interoperable, self-describing, visualizable, and compounding.

The article traces the workflow through three stages: (1) creating the wiki directory structure and schema from scratch, (2) ingesting two Substack essays resulting in 18 auto-generated pages (entities, concepts, works) with full cross-referencing, (3) building a self-contained HTML viewer with graph visualization, (4) converting the entire wiki to conform to Google’s Open Knowledge Format (OKF) — a newly released spec that formalizes the markdown-wiki pattern into an open standard — and (5) building a tag management system with graph visualization for metadata governance.

Methods

The article is a narrative walkthrough of a single AI-agent session. The agent used was Nous Hermes (by Nous Research), running on Xiaomi Mimo V2.5 Pro as the underlying LLM. The method was: define a schema (directory structure, frontmatter spec, tag taxonomy), feed raw articles to the agent, have the agent read and distill them into markdown pages, verify cross-referencing, build a viewer, convert to OKF conformance, and build a tag management interface. The article also documents the OKF conversion process in detail: converting wikilinks to standard markdown links, restructuring frontmatter (type, description, timestamp), rewriting index.md in OKF bullet-list format, reversing log.md to newest-first, and updating the viewer to handle both formats.

Key Findings

1. The LLM Wiki pattern is a viable zero-dependency knowledge management system. “No database. No special tooling. Just a directory of .md files with YAML frontmatter and wikilinks between pages.” The agent created the full directory structure and schema in seconds, and from two essays “identified 6 entities, 11 concepts, 1 work” and generated corresponding pages.

2. OKF conversion enables portability across tools. “Google’s OKF takes the Karpathy ‘LLM wiki’ pattern — markdown files an agent reads and writes, organized so both humans and models can navigate them — and turns it into a spec rather than a personal convention.” The conversion touched every file: new frontmatter, wikilinks replaced with standard markdown links, index rewritten in OKF format, log reversed to newest-first.

3. The graph view reveals knowledge network structure that a table of contents cannot. “Seeing the knowledge network laid out spatially — Pattee at the center, the epistemic cut and semantic closure as dense concept hubs, the newer thinkers (Deacon, Barbieri, Hoffmeyer) at the periphery with thinner connections — made the wiki’s structure visible in a way that a table of contents never could.”

4. Tags drift without management: tags exist in the taxonomy but go unused, tags appear on pages without being defined in the taxonomy, and there is no way to see which tags cluster together. “The wiki had metadata, but no way to manage it.” The solution was a tag management system with three sub-views: a tag graph (force-directed, edge-weighted by co-occurrence, color-coded by taxonomy category), a browse view, and an edit view.

5. The knowledge base is now portable, interoperable, self-describing, visualizable, and compounding. “The next article ingested will cross-reference everything that already exists. Google’s OKF adds portability to that compiled knowledge.”

Concepts Introduced or Used

• LLM Wiki (Karpathy’s pattern): A directory of interlinked markdown files with YAML frontmatter and wikilinks, organized as raw sources + wiki pages (entities, concepts, comparisons) + schema, managed by an AI agent. The article explicitly references Karpathy’s proposal as the foundation.
• Open Knowledge Format (OKF): A file format specification by Google for organizing knowledge as bundles of markdown files. Each file is a “concept” with YAML frontmatter (only type required). Two reserved filenames: index.md (directory listing) and log.md (chronological changelog). Links carry no typed semantics — the relationship type is conveyed by surrounding prose, not by the link structure.
• Tag graph: A force-directed visualization where tags are nodes, sized by page count, and edges connect co-occurring tags (thicker edges for more shared pages). Nodes are color-coded by taxonomy category. Used for metadata governance — detecting orphan tags, unused tags, and tag clusters.
• Write-read-rewrite loop: The article references the concept from a prior ingestion (the author’s earlier essay “Life Is Interpretation”), describing the molecular mechanism of condensate-driven cellular interpretation.
• (See) viewer: A self-contained single-file HTML application that renders a wiki directory as an interactive dark-themed interface with rendered markdown, working graph, and tag management — all pages embedded as inline JSON.

Entities Referenced

• Google OKF (Open Knowledge Format): A file format specification published by Google Cloud Platform’s knowledge-catalog repository on GitHub at https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
• Nous Hermes (Nous Research): A desktop AI agent capable of reading files, running terminal commands, browsing the web, and building applications. The agent used in the article’s workflow.
• Xiaomi Mimo V2.5 Pro: The LLM powering the Nous Hermes agent.
• Andrej Karpathy: Referenced as the proposer of the “LLM Wiki” pattern (the essay “The Wiki That Writes Itself”).
• Howard Pattee: Physicist and theoretical biologist; epistemic cut concept. Appears as a central entity in the resulting wiki’s graph.
• Stuart Newman, Sahotra Sarkar, Jesper Hoffmeyer, Marcello Barbieri, Terrence Deacon: Philosophers and biologists whose works were primary content in the ingested essays.

Limitations (as stated by authors)

The article does not explicitly discuss limitations of the OKF format or the LLM Wiki workflow as caveats. The tag management section documents a scaling problem (tag drift as the wiki grew past 30 pages) and its solution, but frames this as a solved problem rather than a limitation. The article also implicitly acknowledges that OKF links carry no typed semantics (“the specific kind of relationship… is conveyed by the surrounding prose, not by the link itself”), but does not discuss this as a limitation — it is presented as a design feature. No limitations of the viewer (performance on large wikis, offline capabilities beyond the initial bundle, graph scalability) are discussed.

Relevance to Clonal Evolution

Direct structural relevance — the article describes this wiki’s own architecture. The “LLM Wiki” pattern documented here — a directory of markdown files with YAML frontmatter, organized into raw/, entities/, concepts/, comparisons/, with an index.md and log.md — is the same pattern this wiki follows, down to the directory layout and file conventions. The article thus serves as a reflective case study of the wiki’s own design choices and their intellectual provenance.

Relevance to the olog and double-categorical infrastructure is indirect but substantive. The article and the olog infrastructure represent two different levels of knowledge representation:

1. OKF / LLM Wiki is a file-format and workflow layer — it handles storage, navigation, portability, and cross-referencing of knowledge units. It has no formal semantics: links are untyped, there are no commutativity conditions, no functors, no structure-preserving mappings. As the article states: “the specific kind of relationship… is conveyed by the surrounding prose, not by the link itself.” This is sufficient for human navigation and LLM reading but provides no mathematical machinery for verifying that cross-domain analogies are valid.

2. The olog infrastructure (cancer-evolution-olog, ecology-invasion-olog, compression-progress-olog, cross-domain-functors) and double-categorical semantics (lambert2024-double-functorial-semantics) are a formal representation layer — they provide exactly what OKF lacks: typed relationships (objects, arrows, proarrows, cells), commutativity conditions (functoriality constraints), and structure-preserving mappings (functors as formal criteria for valid analogies). The Lambert & Patterson (2024) double olog goes further, unifying functional and relational ologs into a single framework with both terms and predicates as first-class citizens.

A potential synthesis — the three-layer stack. OKF, the olog infrastructure, and Bian (2025) (bian2025-llm-kg-construction) form a complete knowledge infrastructure stack:

• Layer 1 — OKF (file format). Portable, human-readable markdown + YAML frontmatter + [[wikilinks]]. The concrete representation.
• Layer 2 — Bian (2025) (algorithmic population). LLM-driven ontology engineering, knowledge extraction, and knowledge fusion. How the format gets populated from unstructured sources.
• Layer 3 — Lambert & Patterson (2024) (formal semantics). Double ologs with typed relationships, commutativity conditions, and double functors. Verifiable correctness criteria for cross-domain mappings.

This wiki implements all three: OKF as the file format, subagent-driven ingest as Layer 2 (manually orchestrated rather than automated as Bian surveys), and domain ologs with double-categorical enrichment as Layer 3. The stack is the wiki’s own architectural insight. See docs/superpowers/specs/2026-07-11-kg-construction-stack.md.

OKF could serve as the portable file-format layer for double ologs — storing type definitions and instance data as markdown files with YAML frontmatter, while the double-categorical structure (objects, vertical arrows, horizontal proarrows, cells) is encoded in the schema and frontmatter conventions. The OKF spec’s tolerance of arbitrary extra keys in frontmatter (“producers can add arbitrary extra keys that consumers must tolerate”) would allow embedding categorical metadata (source and target objects, arrow types, commutativity constraints) alongside the standard fields. This would produce a knowledge base that is both human-navigable (markdown + wikilinks) and formally analyzable (double-functorial semantics), without requiring special tooling to read the human-facing content.

The tag management problem described in the article (tags that exist in the taxonomy but go unused; tags that appear on pages but are not defined in the taxonomy; no way to see tag clusters or co-occurrence) is directly relevant to this wiki’s own tag taxonomy management. The wiki already has lint checks for orphan tags and undefined tags (scripts/lint-wiki.sh), and the article’s tag graph visualization offers a potential enhancement: a spatial view of which tags cluster together, which tags co-occur, and which tags are peripheral.

Knowledge representation as a bottleneck: The article’s relevance ultimately lies in what it does NOT address — the problem that motivated the olog infrastructure in the first place. The OKF format, with its untyped links, cannot distinguish between causal relationships, compositional relationships, analogical mappings, or evidential support. For the clonal evolution wiki’s cross-domain synthesis program, which depends on precisely this distinction (functorial mappings versus mere metaphor), the formal semantics of the olog approach are essential. The article makes clear that OKF is a format for portable knowledge, not formally structured knowledge — and the wiki needs both.