Intelligence Briefing · Viska Funds
Google Cloud's new open specification for storing an organisation's knowledge as a folder of linked Markdown files — what it is, what it is not, and why the idea matters regardless of whether this particular standard succeeds.
Scope: Neutral landscape briefing. No Viska-specific recommendation — this document explains OKF so the fund can form its own view.
On 12 June 2026, Google Cloud published the Open Knowledge Format (OKF) v0.1 — an open specification for storing an organisation's knowledge as a folder of plain Markdown files that link to each other, rather than inside a specialised "vector database." It formalises a pattern popularised two months earlier by Andrej Karpathy (co-founder of OpenAI, former head of AI at Tesla), who called it the "LLM Wiki."
The core idea is a genuine shift — and it is the part worth your attention regardless of whether this particular spec succeeds:
The dominant way to give an AI system memory has been RAG — chop documents into fragments, store them in a vector database, and retrieve the closest fragments to each question. Its weakness: the system re-derives the same connections on every query; nothing accumulates. The "wiki" approach instead has an AI build and maintain a living, cross-linked knowledge base once, so the synthesis is paid for up front and simply read thereafter.
Essentially "keep institutional knowledge as version-controlled Markdown that an AI maintains." Low-cost, low-lock-in, inspectable.
A v0.1 draft. It standardises the container (file/folder conventions) but deliberately not the meaning of the content — its most-cited weakness.
Even Karpathy reintroduces conventional search (incl. vector search) once a base grows past a few hundred documents. "A folder beats the vector database" holds at moderate scale, not universally.
Apache-2.0 licence, no vendor account or SDK required to read or write, lives in Git. Trying it costs little and locks you into nothing.
An OKF "bundle" is just a directory of Markdown files. Each file is one concept — a table, a metric, a playbook, a process, an entity, anything. The file's location is its name. Files link to one another with ordinary Markdown links, and those links form a knowledge graph.
The whole specification fits on one page. In Google's own words: "If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it."
There is exactly one hard rule: every file must declare a type: in a small YAML header (e.g. type: Metric). Everything else — title, description, source link, tags, timestamp — is recommended but optional. Two filenames are reserved:
index.mdA table of contents for a folder. An AI reads this first to see what exists before opening individual files ("progressive disclosure").
log.mdA dated changelog of what was added or changed.
A deliberately permissive rule governs anything reading a bundle: it must tolerate unknown fields, unknown type values, broken links, and missing index files, and must never reject a bundle for them. Google states this is intentional — bundles will be "partially generated by agents," so readers are told to forgive mess rather than demand perfection.
Karpathy published a short "idea file" describing the pattern. His framing, verbatim: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." The key insight is that the human does not write the wiki — the AI does: it reads each new source, updates entity pages, revises summaries, flags where new data contradicts old, and maintains the cross-references. The human curates sources and asks good questions; the AI does the bookkeeping that humans always abandon.
Crucially, Karpathy's pattern has three layers: immutable raw sources; the AI-written wiki; and a schema file (a CLAUDE.md/AGENTS.md-style document) that tells the AI how to maintain the wiki — plus three standing operations: Ingest, Query, and Lint (a periodic health-check for contradictions, stale claims, and orphaned pages).
Google Cloud's announcement explicitly says OKF "formalizes the LLM-wiki pattern" and credits Karpathy directly. Google's contribution is standardisation — pinning down the minimum file/folder conventions so wikis written by one team or tool can be read by another.
Important nuance
Google standardised the container (the file format) but left out Karpathy's maintenance machinery — the schema layer and the Ingest/Query/Lint operations that actually keep a wiki alive. The OKF spec is a static format definition; it contains no mechanism for keeping bundles current. (See Section 06, limitation 1.)
OKF is published openly on GitHub (GoogleCloudPlatform/knowledge-catalog, Apache-2.0). Alongside the one-page spec, Google shipped three reference implementations, explicitly labelled "proofs of concept":
Walks a BigQuery dataset, drafts an OKF document for every table/view, then runs a second AI pass to add citations, schemas, and join paths.
Turns any bundle into an interactive graph view in a single self-contained file — no backend, "no data leaves the page."
Built from BigQuery public datasets: Google Analytics e-commerce, Stack Overflow, and Bitcoin.
Authorship is telling about strategy: the announcement is by-lined by Google's Data Cloud / BigQuery engineering leads, not its AI research lab, and every example is BigQuery-flavoured. Google has also wired its commercial Knowledge Catalog product to ingest OKF. The format is open and genuinely usable by anyone; the reference tooling and samples point back toward Google's data platform. That is a normal "open standard, house tooling" play — worth understanding, not alarming.
A widely-shared video about OKF asserts Google "just renamed" one of its knowledge products to capitalise on this launch. We found no evidence of any such rename. The product Google actually connected to OKF is its existing Knowledge Catalog. We flag this so the claim is not repeated as fact.
A vector-RAG system re-assembles the answer to "how do we compute weekly active users?" from scattered fragments every single time. A maintained wiki has already written that page, already flagged the contradictions, already linked the related concepts. You read a finished answer instead of re-deriving it.
An AI reads the small index.md table-of-contents first and opens only the one or two files it needs — it never has to ingest the entire library at once.
No database, server, or API key is needed to read it. You can diff it, review changes in a pull request, hand the whole thing to an offline model, and read it in any text editor. Knowledge becomes auditable and portable in a way a vector database never is.
Open spec, Apache-2.0, no SDK. The data outlives any one tool or vendor.
We assessed the three most-cited criticisms against the actual spec and independent commentary. Our confidence in each is stated.
The spec has a timestamp field, but a field is not a process. OKF defines a container and says nothing about how bundles stay current — Google explicitly dropped the maintenance layer that Karpathy's original included. In practice this works beautifully when one owner tends one folder; on a shared team knowledge base nobody is assigned to maintain, it goes stale, and an AI then answers confidently from expired knowledge.
Mitigation exists (it is exactly Karpathy's schema + Ingest/Query/Lint discipline, or a scheduled maintenance job) — but you must supply it; the standard will not.
The single required field, type, is free-form with no shared vocabulary. One team writes type: BigQuery Table, another writes table, another relational asset — all valid, all conformant, none interoperable in meaning. An independent analyst put it precisely: "The container is standardized; the meaning is left to each producer … a shared way to store context, not yet a shared way to make sense of it."
That same analysis caught an early inconsistency: Google's own reference parser expects four fields even though the spec requires only one — a sign the standard is still settling. For a single organisation that controls its own vocabulary, this matters far less; for cross-organisation exchange (OKF's stated ambition), it is the open problem.
The concern: language models maintaining thousands of files can botch formatting, mangle structure, and invent links to files that do not exist. We did not find a hard, quantified study proving this at scale, so we grade it as a reasonable risk rather than an established fact. It is, however, implicitly conceded by the spec's design — the "tolerate all mess" rule exists precisely because bundles are "partially generated by agents."
For a fund, the sharper version of this risk is factual: an AI that fabricates a number while summarising a financial document is far more dangerous than one that mis-formats a heading. Any serious deployment needs provenance discipline (OKF does provide an optional # Citations convention to support this) and validation — neither of which the format enforces.
Karpathy himself scopes the pure index-first approach to "moderate scale (~100 sources, ~hundreds of pages)." Beyond that he recommends adding a real search engine — specifically qmd, which uses hybrid keyword + vector search with re-ranking. In other words, the originator reintroduces vector search once the corpus is large. The popular "a folder beats the vector database" headline is therefore misleading at high volume: at scale the mature pattern is folder plus search, not folder instead of search.
Status: v0.1 — explicitly a "starting point, not a finished standard." Google invites breaking changes in future versions.
Traction: the figures above are ~12 days after launch — strong early interest and real engagement, and they contradict the dismissive "a standard with one user" framing. Caveat: stars measure curiosity, not production adoption; it is far too early to call OKF an established standard, and it could still stall (Google has retired promising projects before).
Licence: Apache-2.0 (permissive, commercially safe). The repo carries the standard "not an official Google product" disclaimer — it is a reference/sample repository, not a supported product.
Backing: Google Cloud Data Cloud / BigQuery engineering, published in the open with explicit invitation for outside implementations.
| Approach | What it is | Strength | Weakness |
|---|---|---|---|
| Vector RAG | Documents chunked, embedded, retrieved by similarity per query | Fine-grained recall over huge, unstructured corpora; mature tooling | Re-derives connections every query; nothing accumulates; opaque |
| OKF / LLM-Wiki | AI-maintained folder of linked Markdown concepts | Synthesis persists; auditable; portable; no infra to read | No built-in maintenance; meaning not standardised; weaker at large-scale fine recall |
| Knowledge graph | Typed entities + typed relationships in a graph store | Strongest at precise relationship / semantic queries | Heavyweight; needs schema design + infrastructure |
| MCP (Model Context Protocol) | A protocol for connecting AI to live tools / data | Standard plumbing for real-time access | Different layer entirely — not a memory format |
"MCP is the pipe, OKF is the cargo."
Commentators' framing, not Google's official wording. MCP moves data to a model at run time; OKF is a way to store curated knowledge — they are complementary, not competing. Likewise, OKF and vector RAG are not strictly either/or: the emerging mature pattern (and Karpathy's own) is a maintained wiki for synthesised knowledge, with a search index (often hybrid keyword + vector) layered on for scale.
OKF is best understood as Google blessing and standardising an already-spreading good idea: keep your institutional knowledge as AI-maintained, version-controlled Markdown. The idea is durable and worth internalising — it directly attacks the real weakness of today's RAG systems (no memory, constant re-derivation). The specific v0.1 standard is minimal, early, and solves the easy half of the problem (the container) while explicitly leaving the hard halves — keeping knowledge current, and agreeing on what words mean — to whoever adopts it.
For any knowledge-heavy organisation, the responsible posture is: take the pattern seriously; treat the v0.1 standard as promising-but-unproven; and assume you must supply the maintenance discipline, provenance controls, and (at scale) search infrastructure that the format itself does not provide.
Every load-bearing claim, with how it was verified. This briefing is T-deep: each primary source below was read in full.
Tags — deep-read read the full primary source · secondary credible third party · inferred reasoned from evidence · unverified could not confirm.
| # | Claim | Tag | Source |
|---|---|---|---|
| 1 | OKF published 12 June 2026, v0.1 draft | deep-read | Google Cloud blog (first_published 2026-06-12) |
| 2 | OKF = directory of Markdown + YAML frontmatter; bundle / concept / concept-ID model | deep-read | OKF SPEC.md §1–§4 |
| 3 | Exactly one required field: type; not centrally registered; consumers must tolerate unknown types | deep-read | SPEC.md §4.1, §9; blog |
| 4 | Reserved files are index.md (TOC) + log.md (changelog) | deep-read | SPEC.md §3.1, §6, §7 |
| 5 | Permissive consumption: must not reject for unknown fields/types, broken links, missing index | deep-read | SPEC.md §9 |
| 6 | Provenance supported via optional # Citations convention | deep-read | SPEC.md §8 |
| 7 | Spec contains no maintenance / update mechanism (Limitation 1) | deep-read | SPEC.md (entire) — absence verified; blog confirms format-only scope |
| 8 | Origin = Karpathy "LLM Wiki," ~April 2026; AI writes the wiki, not the human | deep-read | Karpathy gist (raw) |
| 9 | Exact quote "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase" | deep-read | Karpathy gist |
| 10 | Karpathy's three layers (raw/wiki/schema) + Ingest/Query/Lint = the maintenance layer OKF dropped | deep-read | Karpathy gist |
| 11 | Karpathy scopes index-first nav to "~100 sources"; recommends qmd (hybrid BM25/vector) at scale | deep-read | Karpathy gist |
| 12 | Google blog "formalizes the LLM-wiki pattern," credits Karpathy | deep-read | Google Cloud blog |
| 13 | Authors = Sam McVeety (Data Analytics TL) + Amir Hormati (BigQuery TL) → "BigQuery-team origin" | deep-read | Google Cloud blog byline |
| 14 | Reference impls: BigQuery enrichment agent, static HTML graph visualiser, 3 BigQuery sample bundles | deep-read | Google Cloud blog |
| 15 | Adoption ~12d post-launch: ~5,000 stars, 381 forks, 45 issues, 31 PRs, Apache-2.0 | secondary | GitHub repo page (fetched 2026-06-24) |
| 16 | Container-not-meaning critique; Google reference parser wants 4 fields vs spec's 1 | secondary | Marc Bara, Medium (independent analysis) |
| 17 | "Renamed knowledge product" claim from source video | unverified | No corroborating source; blog points to existing Knowledge Catalog |
| 18 | Reference enrichment agent "runs on Gemini" | inferred | Blog says "a second LLM pass," does not name Gemini |
| 19 | "MCP is the pipe, OKF is the cargo" positioning | secondary | Commentator framing; not in Google's official text |
| 20 | Limitation 3 (LLMs unreliable as librarians at scale) | inferred | No hard study found; supported circumstantially by spec's "tolerate mess" rationale |
raw.githubusercontent.com/GoogleCloudPlatform/knowledge-catalog/main/okf/SPEC.mdcloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharinggist.github.com/karpathy/442a6bf555914893e9891c11519de94fgithub.com/GoogleCloudPlatform/knowledge-catalogDevsplainers, "Google's OKF: Why a Folder Beats the Vector Database" (YouTube, 2026-06-22). This video prompted the research; two of its specific claims (the "renamed product"; the reserved-file naming) did not survive primary-source verification — see the audit below.
The research was prompted by a YouTube video. Per verify-before-assert discipline, the video was treated as an unverified secondary source and each of its specific claims independently audited — so the briefing inherits none of its mistakes.
| Video claim | Verdict | Evidence |
|---|---|---|
| OKF published 12 June | ✅ Correct | Blog first_published 2026-06-12 |
| Karpathy posted "LLM Wiki" in April; OpenAI co-founder / ex-Tesla AI | ✅ Correct | Gist + public record |
| "Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase" | ✅ Correct (exact) | Karpathy gist, verbatim |
| Bundle = folder; one file = one concept; path = name; links = graph | ✅ Correct | SPEC.md §2–§5 |
| One required field; readers must forgive unknown fields / broken links / unparseable files | ✅ Correct | SPEC.md §4.1, §9 |
| Google kept the folder but dropped Karpathy's maintenance instructions | ✅ Correct | Gist has schema + Ingest/Query/Lint; SPEC.md has none |
| Critique: no update process (field ≠ process); shared folders go stale | ✅ Correct | SPEC.md has no maintenance mechanism |
Critique: standardises container, not meaning (free-form type) | ✅ Correct | SPEC.md §4.1; corroborated by Marc Bara |
| OKF came from the BigQuery team; samples on BigQuery | ✅ Essentially correct | Authors = Data Analytics + BigQuery TLs; all samples BigQuery datasets |
| Two special files (one TOC, one changelog) | ⚠️ Right idea, wrong names | Actual reserved names are index.md + log.md; video implied bespoke two-letter names |
| Reference writer "runs on Gemini" | ⚠️ Unconfirmed | Blog says "a second LLM pass," never names Gemini |
| Critique: LLMs are bad markdown librarians at scale | ⚠️ Plausible, not proven | No hard study found; only circumstantial support |
| "Almost nobody outside Google was using it / a standard with one user" | ⚠️ Overstated | ~5,000 stars / 381 forks / 31 PRs in ~12 days = strong early interest |
| Google "just renamed" a knowledge product for this launch | ❌ Likely wrong | No evidence of any rename; product wired to OKF is the existing Knowledge Catalog |
| "A folder beats the vector database" | ❌ Misleading at scale | Karpathy reintroduces hybrid keyword+vector (qmd) beyond ~hundreds of pages |
Reserved filenames corrected to index.md / log.md; the "renamed product" claim excluded as fact and flagged unverified; the "Gemini" attribution softened to "a second LLM pass"; and "folder beats vector DB" reframed as scale-bounded, citing the originator's own qmd recommendation.