OKF has a lineage. Its origin trail has a hole.

The Open Knowledge Format arrived in June 2026 with an appealingly small promise: knowledge for agents should travel as ordinary Markdown files, not remain trapped in a service. The launch account called OKF a portable, vendor-neutral specification and said directly what it was formalizing: Andrej Karpathy's LLM-wiki pattern [A1] [C1]. That gives OKF a clear design lineage. It does not give it a complete public history.

The first version of the OKF specification visible in Google Cloud's public repository was imported on June 12 as a single snapshot. The import record explicitly says the upstream Git history was not preserved [A3] [C4]. The repository's API returned only three commits touching the specification at the time of this review: that June snapshot and two changes on July 24 for v0.2 [A12] [C3]. The upstream repository named in the import no longer resolved on GitHub when checked on August 20 [A17].

That break matters. The public record can tell us what OKF's authors say they built on, what entered Google's repository, and how the specification changed afterward. It cannot reconstruct the work between the original idea and the snapshot. The honest origin story therefore begins with a distinction: OKF's declared precedent is traceable; its pre-import development trail is not.

The direct precedent is a maintained wiki, not query-time RAG

Karpathy's LLM-wiki idea file describes a three-layer system. Immutable raw sources sit at the bottom. Above them, an agent maintains a persistent, interlinked Markdown wiki, revising pages as new material confirms, contradicts, or complicates what is already known. A repository-level schema or instruction file tells the agent how to perform that maintenance [A2] [C2].

The point is accumulation. A conventional retrieval system finds fragments again for each question; the wiki keeps the synthesis, cross-references, and contradictions as a compounding artifact. Git supplies history. Obsidian can be the human reading surface. The human chooses sources and steers the inquiry; the agent absorbs the bookkeeping required to keep the record coherent [A2].

OKF's contribution is to turn that pattern into an exchange format. Its launch account points to Markdown and YAML, Obsidian, Notion, Hugo, AGENTS.md-style convention files, and repositories with index and log pages as familiar substrate. OKF standardizes enough of their shared shape that a bundle written by one producer can be consumed by another tool without a custom translation layer [A1] [C11].

There is a deeper intellectual ancestor, but it belongs one step back. The LLM-wiki file compares its persistent, curated knowledge store to Vannevar Bush's Memex and its associative trails. The OKF launch account does not make that historical claim itself [A2] [C10]. Calling Memex a precedent for OKF is reasonable only if the chain remains visible: Memex to LLM-wiki to OKF, not Memex cited directly by OKF.

A format boundary is both the strength and the unfinished work

OKF is intentionally not a complete knowledge system. The v0.2 specification does not prescribe storage, serving, or query infrastructure, and it does not standardize how executable tools are packaged or invoked. It fixes a portable document interface and leaves the machinery behind that interface to consumers. A full runtime protocol, portable and sandboxed attesters, attestation caching, and semantic-layer templates are explicitly deferred to a future revision [A4] [C5].

That narrowness is a feature: plain files remain readable, diffable, and tool-neutral. It is also an adoption cost. A team choosing OKF still has to decide how agents find the right page in a large bundle, how pages retain identity when reorganized, how relationships become queryable, and how several bundles compose. Conformance alone does not answer those operational questions.

The trust story has the same shape. Version 0.2 adds vocabulary for provenance, verification, freshness, lifecycle, and attestation. Those signals let a consumer distinguish a human-reviewed concept from an unverified one before spending tokens on the body. But the fields are optional, and a conforming consumer must not reject a concept merely because they are absent. OKF exposes trust state; it does not manufacture trust or require enforcement [A5] [C9].

The public pressure is clustering in five places

Six independently authored public issues and discussions were read as critiques and implementation signals, not as accepted requirements. Together they converge on five recurring problems [A6] [A7] [A8] [A9] [A10] [A13] [C6].

• Stable identity. One implementation critique argues that making a file

path the concept identity means ordinary reorganization can break inbound links. It proposes separating identity from hierarchy and preserving a rationale trail as knowledge changes [A6].

• Routing and orientation. Two proposals ask for cheap frontmatter cues

about depth, purpose, task, and audience so an agent can decide what to read without loading every body first [A7] [A13].

• Relationship semantics. Proposals seek a way to distinguish a citation,

dependency, join, or impact edge without inferring the relationship from surrounding prose or rebuilding the entire graph [A6] [A8].

• Retrieval at scale. A public discussion asks what replaces index traversal

when a bundle contains hundreds of thousands or millions of concepts. The question is unresolved at the format layer because query infrastructure is a declared non-goal [A10].

• Cross-bundle composition. A registry proposal tries to preserve portable,

bundle-local links while mounting concepts maintained elsewhere. It is a design proposal with no reference implementation in the captured record, not an existing capability [A9].

This cluster should not be read as evidence that OKF has failed. Several contributors begin from the opposite observation: independent projects converged on Markdown, YAML, Git, and permissive consumption because the core substrate works. The issues reveal what starts to hurt when a small portable bundle becomes an evolving, multi-agent knowledge system. They are evidence of where users are applying pressure, not evidence that maintainers have chosen a solution.

There is direction of travel, but no public schedule

The search for a roadmap produced a bounded negative result. At capture time, the public repository root contained no roadmap or planning file; neither did the okf/ directory; and the all-state milestones endpoint returned an empty list [A14] [A15] [A16] [C7]. Project-board contents were not observable with the available access, so they are expressly outside the claim [D1]. This notebook can say no formal roadmap was found on three named public surfaces. It cannot say no roadmap exists anywhere.

Nor does the absence of a roadmap mean the absence of planning. The specification has a "considered and deferred" section naming work for future revisions. The v0.2 release says community proposals informed that version. Open issues contain concrete extension designs [A4] [A5] [A6] [A9] [C8]. The record supports a narrower, more useful conclusion: OKF shows active public planning without a public delivery schedule.

How much authority should this account carry?

The notebook deliberately holds different parts of the answer at different levels of authority.

• Claims about what the OKF authors say are grounded in their launch post,

release post, and normative specification. Those are primary for the project's position but self-reported, so they are not independent proof of a broader historical claim [A1] [A4] [A5].

• The public commit count and roadmap-surface checks come from captured GitHub

API responses with a defined base. They establish what those public surfaces contained on August 20, 2026 [A12] [A14] [A15] [A16].

• The gap map rests on six independent contributors. It corroborates the

recurrence of the problem classes, not their severity, adoption, or place on an official roadmap [C6].

• The missing upstream is a record of an attempted acquisition, marked

PRIMARY-LOST. It corroborates nothing. It remains in the notebook so a future researcher knows exactly where the evidence chain broke and what would reopen it [A17] [Q1].

That last distinction is the point of keeping a reporter's notebook rather than merely writing an answer. A missing source was neither discarded nor silently promoted. A negative roadmap finding was given a named search base. Community proposals were useful signals without becoming project promises. Claims about individual documents were tested against captured bytes, while cross-source syntheses had to clear a corroboration bar.

Verdict

OKF is best understood as a young interoperability layer over an emerging agent-maintained-wiki practice. It did not invent persistent Markdown knowledge bases, Git-backed maintenance, or human browsing in Obsidian. It formalized enough of that convergent practice to let producers and consumers exchange knowledge as plain files [C1] [C2] [C11].

Its biggest present tradeoff follows directly from that choice. Minimalism makes the format portable; it pushes identity, routing, relationship semantics, retrieval, composition, and enforcement into profiles, extensions, and tools. Public contributors are working those edges, and version 0.2 shows that proposals can shape the specification. What the public record does not yet offer is a complete pre-import history or a dated roadmap.

This account should be reopened if the named upstream or an archived commit history reappears [Q1], if a later OKF version resolves or rejects the current proposal cluster [Q3], or if a roadmap file, milestone, release plan, or observable project board becomes public [Q4]. Until then, the concise answer is: clear lineage, incomplete origin custody; real planning, no visible schedule.