Open Knowledge Format (OKF) — assessment vs the RDCO vault
Founder shared OKF (Google Cloud Data Analytics, v0.1 Draft) 2026-06-13 and asked: what we think, how it compares to our vault, green-field choice, multi-contributor scaling. This is the verdict.
What OKF is
A vendor-neutral, Apache-2.0 spec (not a platform) that formalizes the "LLM-wiki" pattern into a portable bundle: a directory of markdown Concept files with YAML frontmatter, read as a graph (concepts = nodes, markdown links = edges). General-purpose KM, not data-catalog-only. Explicitly "not a finished standard," "not an official Google product," no external adoption yet. Reference tooling = a Gemini/ADK enrichment agent (producer) + a Cytoscape viz CLI (consumer).
Headline
OKF is our vault pattern — markdown + YAML frontmatter + link-graph + git — standardized into a portable interchange format, but deliberately thinner than what we already run.
Comparison
| Dimension | OKF v0.1 | RDCO vault |
|---|---|---|
| Doc unit | Concept = one .md |
note = one .md ✓ same |
| Metadata | YAML frontmatter, only type required |
YAML frontmatter, richer conventions + invariants |
| Links | untyped markdown links (kind in prose) | typed graph (graph.duckdb: validates/contradicts/citations/author-authority) — [[graph-query]] |
| Search | not specified (viewer has a search box) | qmd: BM25 + vector + hyde |
| Provenance | # Citations + resource URI field |
citations/wikilinks (no strict canonical-URI field) |
| Versioning | optional log.md + git |
git + working-context |
| Portability | defined bundle (ship as tarball/repo) | bespoke Obsidian-flavored, not an interchange format |
| Multi-contributor | punted entirely to git | single-writer discipline + evolving filing-contract |
We're richer on the analytical layer (typed edges, search, enforced conventions). OKF is ahead on portability (a clean bundle you can hand to another org/agent) + the canonical resource field + explicit producer/consumer separation.
Green-field verdict
Still our richer model — typed graph + real search beat OKF's thin layer for a working KB. But make the vault OKF-emittable (we're ~90% compatible already) and adopt its best bits (canonical resource field, bundle/index.md discipline). Treat OKF as an export target, not the internal model. Too early (v0.1, zero adoption) to bet the system on.
Multi-contributor / multi-agent scaling (its weakest point)
OKF does not solve it — punts to git (PRs/diffs/blame). No merge model, no federation, no identity/access ("not specified"). Scales distribution well (one producer → many consumers/agents via a bundle) but not concurrent co-authoring — two agents editing one concept = a git merge conflict resolved by git, not OKF. Same wall the vault hits; the contribution/merge/governance layer is still yours to build.
Strategic hook
A portable knowledge-bundle interchange format maps directly onto the CAF restructure — handing engagement knowledge between agents, consultants, and clients (producer→consumer is exactly that shape). See [[2026-06-09-caf-restructure-proposal]]. If OKF grows typed edges + tooling + adoption, revisit. Until then: track it; consider an OKF-bundle emitter as the CAF interchange format candidate.
Related
- [[2026-06-09-caf-restructure-proposal]] — CAF as the primary use-case for a portable knowledge-bundle format; producer→consumer shape is the direct application
- [[graph-query]] — RDCO's typed-edge graph layer (the dimension where we're richer than OKF v0.1)
- [[2026-05-11-internal-state-review-foldering-sop]] — vault foldering conventions OKF would need to accommodate in any emitter design