OKF Ecosystem Tools

An honest inventory of what exists today (Oct 2026) around the Open Knowledge Format. For each tool: what it does, how mature it actually is, and whether you should bother. Versions, release dates, and GitHub star counts were checked against GitHub, PyPI, npm, and crates.io on Oct 2, 2026.

Repository Migration: OKF now lives in its own repository. The canonical home is GoogleCloudPlatform/open-knowledge-format. The old path (knowledge-catalog/okf/) is a frozen snapshot — do not use it for new work.

1. Reference Enrichment Agent (BigQuery → OKF Bundles)

What it is: An agent that pulls metadata from a pluggable source (currently only BigQuery) and emits a complete OKF bundle — a directory of markdowns with YAML frontmatter ready for humans, LLMs, and catalog tools.

How it works:

• BQ pass: Generates one OKF doc per concept using BigQuery metadata alone (schemas, descriptions, tables).

• Web pass: The LLM (Gemini via ADK) acts as its own crawler. It receives a list of seed URLs (via --web-seed or --web-seed-file), fetches them via a fetch_url tool, and follows outbound links that look like authoritative documentation for existing concepts. For each fetched page, the agent makes one of three decisions:

  • (a) Enrich — add citations, schemas, or join paths to one or more existing concept docs
  • (b) Mint — create a standalone references/<slug> doc for the page
  • (c) Skip — the page isn’t relevant enough

  A hard --web-max-pages cap and a same-domain allowed-hosts filter (--web-allowed-host) prevent the agent from overrunning. Use --no-web to skip the web pass entirely.

Stack: Python 3.13, Google Agent Development Kit (ADK), Gemini as the model backend.

Running it:

# Install
python3.13 -m venv .venv
.venv/bin/pip install -e .[dev]

# Credentials
gcloud auth application-default login
export GEMINI_API_KEY=<your-key>  # or Vertex AI

# Run (minimal)
.venv/bin/python -m reference_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file seeds.txt \
    --out ./bundles/<name>

# BigQuery only (no web crawl)
.venv/bin/python -m reference_agent enrich \
    --source bq \
    --dataset bigquery-public-data.ga4_obfuscated_sample_ecommerce \
    --no-web \
    --out ./bundles/ga4

Included sample bundles:

• bundles/ga4/ — GA4 e-commerce
• bundles/stackoverflow/ — Stack Overflow public dataset
• bundles/crypto_bitcoin/ — Bitcoin blocks/transactions
• bundles/acme_retail/ — Acme Retail

Link: github.com/GoogleCloudPlatform/open-knowledge-format

Limitations:

• BigQuery is the only implemented source (the Source interface exists but nothing else plugs in)
• Requires Gemini API key or Vertex AI configured
• Web pass can burn through tokens fast if you feed it too many seeds
• No incremental updates — runs from scratch every time

🟡 Maturity: Functional proof of concept. The bundles it produces are legit and useful. But the agent itself is a demo of what’s possible, not a product. It genuinely works for BigQuery public datasets. For production use, you’ll want to customize prompts and seeds — and probably add caching.

2. Static HTML Visualizer (viz.html)

What it is: A visualize subcommand that takes any OKF bundle and spits out a self-contained HTML file — interactive concept graph, detail panel, search, type filters, backlinks. No backend, no installation on the viewer side.

What you get:

• Force-directed graph (Cytoscape.js) with nodes colored by type
• Side panel with rendered frontmatter + markdown body
• Navigable internal links within the viewer
• “Cited by” section (computed backlinks)
• Search by title, ID, tags
• Alternative layouts (cose, concentric, breadthfirst, circle, grid)

Generating it:

.venv/bin/python -m reference_agent visualize --bundle ./bundles/ga4
# Produces bundles/ga4/viz.html

# Customize
.venv/bin/python -m reference_agent visualize \
    --bundle ./bundles/crypto_bitcoin \
    --out /tmp/btc.html \
    --name "Bitcoin OKF"

Using it: Open viz.html in any modern browser. Host on a static file server, email it to someone, commit it to the repo. It just works.

Link: Same repo — open-knowledge-format/README.md#visualize

Limitations:

• Large bundles produce heavy HTML files (everything is inlined as JSON)
• The viewer is a minimal SPA — no pagination, no lazy loading
• Depends on CDN for Cytoscape.js and marked.js (not truly offline without tweaks)

🟢 Maturity: This one actually works. It’s simple, does what it promises, and the viz.html files committed to the repo are great for demos. For bundles with 10–50 concepts, it’s perfect. At 500+, you’ll probably hit performance walls.

3. kcmd CLI + MCP Server (Metadata as Code)

What it is: A bidirectional sync tool between local metadata (YAML/markdown on your filesystem) and Google Cloud Knowledge Catalog (formerly Dataplex). Think “git for metadata” — you edit locally and push/pull to the cloud catalog.

Format: YAML for entries, sidecar .md files for rich content (overviews, descriptions). Hierarchical layout mirroring the resource structure.

Distribution: TypeScript library (npm install kcmd), standalone CLI (kcmd), and an MCP server.

Heads-up: the upstream README says npm install kcmd, but the kcmd package currently on the npm registry is an unrelated 2022 project (v1.0.16). Until a matching package is published, build from source: clone knowledge-catalog and run npm install inside toolbox/mdcode.

CLI usage:

# Initialize a snapshot from a BigQuery dataset
kcmd init --bigquery-dataset <projectId>.<datasetId>

# Pull metadata from catalog
kcmd pull

# Check local changes
kcmd status

# Push changes to catalog (with dry-run)
kcmd push --dry-run
kcmd push

MCP Server config:

{
  "mcpServers": {
    "kc-mac": {
      "command": "kcmd",
      "args": ["mcp", "--path", "/path/to/root"]
    }
  }
}

Available MCP tools: pull, push, list-entries, lookup-entry, modify-entry (details in 6.3 MCP Servers).

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode

Limitations:

• Requires a GCP project with Knowledge Catalog enabled
• Auth via gcloud only (no direct service account support)
• The YAML/sidecar format differs from pure OKF (it’s oriented toward the Dataplex catalog)
• Documentation is still sparse — the referenced docs/concept.md exists but is conceptual

🟡 Maturity: Early product, but well-structured. The CLI works, the MCP server is real, and the push/pull workflow makes intuitive sense. The fact that it ships as library + CLI + MCP shows intent to serve varied environments. Still no versioned npm releases though — so pin your expectations accordingly.

4. Enrichment Agent (Toolbox — kcenrich)

What it is: A more production-oriented take on enrichment, built into the kcmd workflow. Unlike the OKF reference agent (which generates standalone bundles), this one enriches metadata that already lives in the catalog’s format.

How it differs from the OKF agent:

• The OKF agent generates standalone markdown bundles
• kcenrich enriches Knowledge Catalog snapshots (the kcmd format)
• Uses MCP servers as sources (e.g. md-fileset to crawl local markdown docs)
• Customizable via prompt.md plus a tools/skills/ directory

How to use:

# Prerequisite: an initialized kcmd snapshot
kcmd init --bigquery-dataset <project>.<dataset>
kcmd pull

# Run enrichment with custom tools
kcagent enrich --catalog-path . --tools-path tools --prompt-path prompt.md

The README calls the CLI kcenrich; the binary its build produces (package kcagent) is kcagent.

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/enrichment

Limitations:

• Depends on a configured kcmd (Metadata as Code) setup
• The demo works but needs a real BigQuery setup
• No published standalone binary release yet (build from source with npm run build)

🟡 Maturity: More proof of concept than product. The demo is instructive and works, but it’s clearly a showcase of how to combine MCP + skills + catalog. Not “install and go” — you have to build the tools infrastructure around it.

5. Google Cloud Knowledge Catalog (The Backend)

What it is: The GCP product (formerly Dataplex) that acts as an AI-powered metadata catalog. It’s the “official backend” that the tools above sync with.

Relevant features for OKF:

• 🆕 Native OKF ingestion — Knowledge Catalog now ingests OKF bundles directly. See the demo and code.
• 🆕 Enterprise OKF distribution (August 2026) — scale OKF bundles across your organization:
  • Push bundles via kcmd push with AspectType okf (signals OKF v0.2 trust fields: sources, generated, verified, status, stale_after)
  • IAM-governed Entries: agents see only what they’re authorized for
  • Agent retrieve path: searchEntries → LookupContext → entries.get(view=ALL)
  • Read more: Scaling OKF with Knowledge Catalog (Aug 26, 2026)
• Automatic harvesting from BigQuery, AlloyDB, Spanner, Cloud SQL, Firestore, Looker
• Third-party integrations: Ab Initio, Anomalo, Atlan, Collibra, Datahub
• Native Gemini enrichment — generates descriptions, glossaries, maps entities
• Sub-second semantic search for agents
• Context APIs + MCP tools for agents to discover assets
• Data products — asset packaging with SLAs and governance

Pricing (summary):

• Free tier: 100 DCU-hour/month + 1 MiB storage + 1M API calls/month
• Standard: $0.06/DCU-hour
• Premium (lineage, quality, profiling): $0.089/DCU-hour
• Storage: $2/GiB/month (above 1 MiB)

Link: cloud.google.com/products/knowledge-catalog

Limitations:

• GCP vendor lock-in (that’s literally why kcmd exists — portability bridge)
• Pricing can scale fast with heavy DCU-hour usage
• The “native format” is NOT OKF — OKF is the portable interop layer

🟢 Maturity: GA Google Cloud product. It’s real, runs in production, has SLA, has enterprise support. The Knowledge Catalog itself is mature — what’s new is the open-source tooling around it.

6. Possible Integrations

6.1 Obsidian

Status: No official plugin. But OKF was deliberately designed to work with Obsidian out of the box.

Why it just works:

• OKF bundles are directories of .md files with YAML frontmatter — exactly what Obsidian expects
• Internal links work as relative paths
• Frontmatter tags show up natively
• The index.md works as an index note

How to use today:

1. Generate a bundle with the enrichment agent
2. Open the bundle directory as a vault in Obsidian
3. Navigate, edit, use the native graph view

What a proper plugin would add:

• Inline validation (OKF conformance linting)
• Templates for new concepts
• Sync with Knowledge Catalog via kcmd

🟢 Natural compatibility. No plugin needed — works by design. A plugin would be nice for validation, but it’s not blocking anything.

6.2 GitHub Actions

Status: No official Action published. But every command is scriptable.

Possible workflows:

# .github/workflows/okf-validate.yml
name: Validate OKF Bundle
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.13'
      - run: pip install okflint
      - run: okflint validate ./bundles/

# .github/workflows/okf-enrich.yml (advanced)
name: Enrich on Schedule
on:
  schedule:
    - cron: '0 6 * * 1'  # Every Monday
jobs:
  enrich:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -e ./okf[dev]
      - run: |
          python -m reference_agent enrich \
            --source bq --dataset ${{ secrets.BQ_DATASET }} \
            --no-web --out ./bundles/weekly
      - uses: peter-evans/create-pull-request@v6
        with:
          title: "chore: weekly OKF enrichment"

🟡 High potential, zero official implementation. The “enrich → commit → PR” workflow is natural for OKF. Someone should publish a reusable Action — it’s low-hanging fruit.

6.3 MCP Servers

Status: kcmd mcp is real and documented. It’s the most mature integration point.

What the kcmd MCP server offers:

Where you can plug it in:

• Gemini CLI / Google AI Studio
• Claude Desktop (via MCP config)
• Cursor / VS Code (any editor with MCP support)
• Custom agents (LangChain, ADK, etc.)

Also available: the md-fileset MCP server (used by toolbox/enrichment) to browse markdown directories as a knowledge base.

🟡 Maturity: kcmd MCP is functional. Documented with a JSON config example and clear tools, but there are no versioned npm releases yet (build from source). md-fileset is more basic but works as a pattern.

6.4 Coding Agents (Claude, Codex, Cursor, Gemini)

Status: No official skill published. This is the most obvious gap.

What exists today:

• The OKF README works as documentation for an agent to understand the format
• The SPEC.md is readable enough for an LLM to generate conformant bundles
• The toolbox/enrichment uses tools/skills/ as an agent skill directory

What’s missing:

• A standalone .md skill that teaches any agent to produce OKF
• Generation-time validation (the agent checks conformance before saving)
• Reusable templates for common scenarios (SaaS metrics, analytics, APIs)

Skill pattern already used by the toolbox:

---
name: fileset-source
description: >
  Use the fileset source to find relevant markdown documents...
---

[tool usage instructions]

🟡 Clear opportunity. The OKF format was made to be agent-friendly, but nobody has packaged it as a distributable skill yet.

Maturity Map

For a visual overview of where every tool sits (maturity × ease of use), see the dedicated Ecosystem Map.

Conclusion

The OKF ecosystem splits cleanly into two layers:

1. Portable layer (pure OKF): Format spec + enrichment agent + visualizer. Works standalone, no GCP required. This is where community opportunities live.

2. Enterprise layer (Knowledge Catalog): kcmd + kcenrich + GCP catalog. Works in production but demands Google Cloud infrastructure.

If you’re building for the portable layer, you can start today with zero cloud dependencies. If you need the enterprise layer, budget for GCP setup and expect a steeper ramp.

This project (okf.md / okf.ia.br) sits in layer 1 — making OKF accessible, validatable, and producible by any agent, with no cloud-provider dependency.

7. Community Tools

The OKF spec went live June 12, 2026. Within weeks, independent implementations appeared across every category.

Generators & Producers

Tools that create OKF bundles from existing content.

AgentFitech

A startup that built OKF support (producer + consumer) within 24 hours of the spec’s release. Documented their process on Medium: “Google just standardized ‘How AI Agents read the web’. Here’s how we shipped it in a day.”

Takeaway: The format is simple enough that a small team can go from zero to conformant in one sprint.

Link: medium.com/@AgentFitech

Groma — C4 Architecture Maps

Groma scans a code repository into a C4 architecture map stored as linked OKF Markdown. Developers and coding agents curate component responsibilities, relationships, and flows; the architecture is available as a live browser map and a terminal view.

Quick start:

npm install --global groma.md
cd your-repository
groma web

Profile and compatibility: Groma uses an OKF v0.2 application profile for C4 architecture. Its v0.6.2 bundle passed OKF conformance with @mfdaves/okf-mcp@0.9.1. Groma consumes this marked profile and does not claim to import arbitrary OKF bundles. A separate project-policy check flagged 89 source links outside the bundle and four directory-navigation links; those findings do not negate format conformance.

Stack: TypeScript and Bun · npm package · MIT · v0.6.5 (Oct 5, 2026) · Node.js 20.19+. Supports Linux and Windows on x64/ARM64, and macOS on Apple Silicon.

Link: github.com/MrLesk/groma.md · Architecture Markdown contract

🟡 Maturity: Early. A working package, release workflow, and installation checks are documented, with independent evidence that its bundle conforms to OKF. The project is still early and its supported profile is specialized.

KL4A — Knowledge Layer For Agents

KL4A turns SOPs, policies, and regulatory documents into small, source-backed knowledge claims. Its distinctive move is a human review gate: a mined claim remains proposed until a reviewer approves, rejects, defers, or edits it, with an identified reviewer, rationale, and before/after values recorded in the bundle’s plain-file review history.

It accepts Markdown, text, PDF, and DOCX sources; inventories and checksums them, normalizes them into sections, mines obligation-shaped claims, then exports an OKF-shaped bundle plus graph JSON and RDF. Each claim links to evidence with offsets into the retained source text. A desktop app, Rust CLI, and read-only-by-default MCP server all use the same bundle.

The worked GLP-1 example makes the value concrete: it rejects an extraction that turns a payer-conditional documentation requirement into an unconditional obligation, while preserving the source span and the review rationale.

Stack: Rust (10 crates), Tauri desktop app, CLI, MCP server, HTTP server. Apache-2.0. Current version: 0.0.1-alpha.

Link: github.com/CogniSwitch/KL4A

Limitations:

• Pre-alpha software; desktop builds are not code-signed.
• Its current export uses generated.actor/generated.date and verified.actor/verified.date rather than OKF v0.2’s by/at; approved examples currently write a null verification date. Treat its trust metadata as a draft profile until that is corrected.
• The offline miner misses sentences split across lines, which makes PDF extraction thin unless an LLM miner is used.
• Evidence offsets address text only, not image regions or video timestamps.

🔴 Maturity: Pre-alpha, but fills a real gap. The pipeline and worked bundle demonstrate claim-level evidence and persisted human review, but the project is new and its trust-field export is not yet interoperable with the OKF v0.2 convention. Worth evaluating for compliance or policy workflows where a reviewer must validate an extraction before an agent relies on it.

okf-postgres (PostgreSQL Producer)

A read-only producer that turns PostgreSQL system catalogs into an OKF v0.2 bundle with explicit generation provenance — database, schemas, tables (including partitioned and foreign tables), views and materialized views, columns, enum types, constraints, indexes, comments, and foreign-key relationships. It never reads application rows and never stores credentials in the bundle.

Quick start:

npm install --global @mfdaves/okf-postgres   # Node.js 22+

# The command only receives the NAME of the env var holding the URL
export OKF_PG_URL='postgresql://user:password@localhost:5432/app'
okf-postgres generate --connection-env OKF_PG_URL --source app-db --schema public --out ./postgres-okf

Output: index.md, database.md, schemas/, tables/<schema>/, views/<schema>/, types/<schema>/, plus a .okf-producer.json manifest with the SHA-256 digest of every owned file. Re-runs only remove stale files whose digest still matches the manifest; hand-authored files are preserved.

Honest metadata: records generated.by/generated.at, but deliberately does not claim verified. When PostgreSQL has no comment, it emits a structural fallback instead of inventing business meaning.

Two ways to run: standalone CLI, or as a producer hosted by okf-mcp (producer preview / producer run), which validates the candidate before publishing.

Stack: JavaScript/Node.js (>=22) · MIT · v0.1.0 (Sep 19, 2026) · PostgreSQL 14–18

Links: github.com/mfdaves/okf-postgres · npm

Limitations:

• Stays on 0.1.x until the live PostgreSQL compatibility gate has been exercised across all supported server versions (per its README)
• Metadata only: describes structure, not business meaning — unless your database already has comments
• Brand new: a single release (v0.1.0) so far

🟡 Maturity: Early, but tightly scoped. Published on npm with build provenance, CI against PostgreSQL 14 and 18, and conservative file-ownership rules. Still a first release — try it on your own schema before wiring it into a scheduled pipeline.

Korpus.cloud (Hosted Platform)

A hosted knowledge platform where people and their AI agents work in the same space, with revision tracking on every write. Korpus describes itself as agent-native and born in 2026, rather than MCP added to an older tool. Submitted by its founder and listed here in Oct 2026; public documentation of its OKF support is still pending, so treat compatibility as unconfirmed for now.

What it offers:

• Bundles — folders of markdown concepts, private or shared, with typed links between them
• Multi-user collaboration — people (owners, contributors, viewers) and agents (Claude, ChatGPT, Cursor, CI jobs) work in the same bundle
• Per-person agents — each agent works for one person, with only the paths and rights that person grants
• Revision tracking — every write is stamped with who wrote it (e.g., @mara via archivist or @jonas in person) and names the revision it read, preventing blind overwrites
• Access via MCP, REST, or Web — connect however your workflow needs
• Hosted in Frankfurt (eu-central-1) — for teams that care about data residency

Use cases:

• Multi-cloud landing zone specs
• Incident response (from Slack chaos to blameless postmortem)
• Security audit evidence that stays current all year

Pricing: Free (up to 5 bundles, 500 MB), Plus at €5/month (up to 50 bundles, 5 GB), and Enterprise deployed in your own AWS account on request.

Link: korpus.cloud

🟡 Maturity: Early listing. The hosted service is live, and its bundles of typed markdown concepts look close to OKF, but OKF import/export isn’t documented publicly yet. Check with Korpus before relying on it for OKF bundles.

xMatrix (Team Workspace)

A team workspace where humans and AI agents collaborate in channels, with living Pages that clone over git as OKF v0.2 bundles. Push an OKF bundle back and its concepts become pages. The integration treats git as an access protocol — git clone https://<hub>/git/<space>.git gives you the pages you can read as a portable OKF bundle.

What makes it interesting:

• Bi-directional OKF — pages export as bundles (producer) AND bundles import as pages (consumer)
• Git as protocol — no special tooling, just git clone / git push with an xMatrix token
• Per-user views — people with different permissions clone different bundles; nothing leaks through history
• OKF v0.2 conformant — every page is a concept with type: xMatrix Page, frontmatter includes generated.by/generated.at, directories have index.md, root declares okf_version: "0.2"
• Validated — bundles checked with the reference parser (OKFDocument.parse + validate)

How the bundle looks:

• Each page becomes <title>.md with OKF frontmatter (type, title, description, resource, generated, xmatrix_page, xmatrix_revision)
• Page references become bundle-absolute links: [page:<id>](/company/relay.md)
• Every directory has an index.md; root declares okf_version
• Push reads the bundle back: frontmatter is xMatrix’s, index.md and log.md are reserved, links become page:<id> references

Quick start:

# Install CLI
curl -fsSL https://xmatrix.sh/install.sh | bash

# Clone a space as OKF bundle
git clone https://<hub>/git/<space>.git

# Edit pages locally, push changes back
cd <space>
# ... edit markdown files ...
git add . && git commit -m "Update docs"
git push

Stack: TypeScript (Cloudflare Workers hub, Next.js web) + Rust (CLI/daemon) · FSL-1.1-ALv2 · Active development

Link: github.com/LambdaLabsHQ/xmatrix · xmatrix.sh

Limitations:

• Requires xMatrix account and space
• FSL license (source-available, not OSI-approved open source)
• Git push doesn’t create/delete pages — only updates existing ones
• Merge commits are refused

🟡 Maturity: Early. Active product with documented OKF integration. The git-as-protocol approach is elegant, and bi-directional sync fills a real gap. Still early for OKF specifically — the integration shipped Sep 2026.

Standards & Profiles

Formal extensions and profiles built on top of OKF.

W3C Holon CG (DataBook)

The W3C Holon Community Group (30+ participants at inaugural meeting, June 19, 2026) is proposing DataBook as a formal OKF profile for semantic web use cases.

What DataBook adds on top of OKF:

• IRI-based identity (id: field)
• Version tracking and author provenance
• Typed fenced blocks carrying RDF (Turtle, JSON-LD), SPARQL, SHACL
• Push to SPARQL triplestore via Graph Store Protocol
• SHACL validation gating deployment

Status: Proposal stage, published Jun 23, 2026; the authors said they would file an issue on the OKF GitHub repo.

Implication: The semantic web community sees OKF as a valid base layer worth extending — not a competitor to displace.

Link: The Ontologist — “The Format Convergence”

🟡 Maturity: Proposal. Validates OKF’s extensibility design. If it lands, OKF gets formal ontological typing for free via profiles.

AIX — AI eXchange Format

A strict superset of OKF v0.2 that adds the capabilities OKF deliberately stops short of: stable identity, typed relationships, media identity, and federation. Every AIX bundle is also a valid OKF bundle — publish once, consumed by both.

What AIX adds on top of OKF v0.2:

• Stable identity (id field) — concept identity survives file moves and renames; no more broken references when you reorganize your vault
• Typed relationships (links array) — depends-on, supersedes, contradicts, describes, and more, with defined inverses; consumers can infer backlinks automatically
• Media identity (media array) — content-hash identity for binary assets (diagrams, recordings, screenshots) plus embedding pointers for multimodal retrieval
• Federation — bundle namespaces, qualified cross-bundle references (namespace/id), shared vocabulary declarations; multiple teams’ bundles interoperate without merging repos

Compatibility contract: AIX adopts OKF v0.2’s trust fields (sources, generated, verified, status, stale_after) unchanged. AIX-only data lives in frontmatter keys OKF consumers preserve or ignore. Every typed links edge is also mirrored by a plain markdown body link, so OKF-only readers still see the (untyped) graph.

Conformance ladder:

Validate any bundle:

python3 tools/ai-xf-validate.py path/to/bundle --level 2
python3 tools/ai-xf-validate.py path/to/bundle --json

Stack: Spec (markdown), reference validator (single-file Python, PyYAML optional), worked example bundle. MIT license.

Link: github.com/DavidROliverBA/ai-xf-format (spec, validator, examples; v0.2 released 2026-08-20; renamed AI-XF on 2026-09-27, latest v0.4.2)

Limitations:

• One producer and one consumer so far — this is a published hypothesis, not an established standard
• The federation design is untested until a second team’s bundle exists
• Typed-edge mirroring costs some redundancy per file

🟡 Maturity: Early. Spec + validator + example bundle are real and versioned; ecosystem is not. The design rationale was published in two essays: “I Was Going to Adopt Google’s Knowledge Format. I Wrote the Superset Instead.” and “OKF v0.2 Quietly Admits the Folder Has a Ceiling”. Worth watching if you’ve hit OKF’s identity or relationship limitations.

Publishing & Visualization

Tools that turn bundles into sites or visual graphs.

Suganthan Web Converter

Paste a URL or sitemap, and it crawls up to 100 pages, strips the chrome, converts each page into an OKF concept with cross-links, and hands you the bundle as a zip. The visual graph alone — dots for pages, lines for links — is worth running even if you never touch the bundle. You’ll spot orphan pages in seconds.

Link: suganthan.com/free-seo-tools/okf-generator/

🟡 Maturity: Functional. Works at page level (one file per page). True concept extraction — pulling distinct ideas out of prose — is the harder next step nobody’s cracked yet.

Suganthan WordPress Plugin

This is probably the fastest path to a live OKF bundle for most sites on the web. Install a plugin, activate it, and your content is already serving at /okf/. No export step, no cron job, no markdown files to maintain by hand.

The plugin watches publish and edit events. Every time you hit “Update” on a post, the bundle rebuilds. The dashboard shows a graph of your internal links — same engine as the web tool above, wired straight into WordPress.

The practical bits:

• Posts and pages become OKF concept files (frontmatter + clean markdown body)
• Served at yoursite.com/okf/ with pretty permalinks, or yoursite.com/?okf=index.md without
• Settings page lets you include/exclude by post type
• GPL, free, open source — read-only (never touches your content, removing it leaves zero traces)

Needs: WordPress 6.0+, PHP 7.4+, pretty permalinks on (Settings → Permalinks — anything except “Plain”).

Install:

1. Grab the zip: uploads.suganthan.com
2. Plugins → Add New → Upload Plugin → pick the zip → Install → Activate
3. Done. Check the OKF menu for the graph. Already live at /okf/.

Also submitted to the WordPress Plugin Directory — pending review.

Link: suganthan.com/blog/open-knowledge-format/

🟢 Maturity: Ready. WordPress powers roughly 40% of the web. For that slice, this is install-and-forget — the bundle stays current without you thinking about it.

superops-team/okf CLI

A Go CLI that scans a Git repository and generates an OKF bundle from the source code — think okf init and you get a .okf/knowledge/ directory with one concept per meaningful file. Comes with incremental updates via git hooks, a built-in linter (13 rules), and a query engine for searching by type, tags, or full-text.

What makes it interesting:

• okf init → scans your repo, generates the bundle
• okf hook -type post-commit → installs a git hook that keeps the bundle fresh on every commit
• okf lint → validates against OKF spec (errors for missing type/title, warnings for style)
• okf search -q "database" → filter by type, tags, or free text
• Incremental updates — only regenerates concepts for files changed since last commit

Install: one-liner (curl | bash), go install, or pre-built binaries (Linux, macOS, Windows — amd64/arm64).

# One-liner
curl -fsSL https://raw.githubusercontent.com/superops-team/okf/main/scripts/install.sh | bash

# Or via Go
go install github.com/superops-team/okf/cmd/okf@latest

Stack: Go, Apache 2.0 license. v0.4.0 released Aug 30, 2026.

Link: github.com/superops-team/okf

🟢 Maturity: Functional, released. Clean architecture (separate packages for parsing, linting, querying, git). The git hook approach fills a real gap — most other tools are one-shot generators, this one keeps the bundle in sync as code evolves. Now includes semantic search (MiniLM embeddings, HNSW index), MCP server for AI agents, and document import (PDF, DOCX, XLSX). 29 stars, active development (last push Sep 29, 2026).

Validators & Linters

Tools that check OKF conformance.

okflint (Linter)

Remember the gap on this page that said “a plugin would be nice for validation, but it’s not blocking anything”? okflint fills it — not as a plugin, but as a CLI. A deterministic linter (zero LLM) that validates OKF bundles against the spec and against rules you declared in your own manifest.

The honest analogy: Ruff for documentation. Runs, reports, exits with a code. That’s it.

Two commands, different philosophies:

• okflint audit — X-ray of your base. Broken links, split candidates, stats. Always exit 0 — observation, not a gate.
• okflint validate — CI gate. Pass? exit 0. Fail? exit 1. Period. Built for pre-commit hooks and pipelines.

The clever bit is the three-tier system:

The middle layer is where it gets interesting. OKF is deliberately minimal (basically just requires type in frontmatter). But in practice every team wants more: “every ADR needs a created field”, “status can only be draft/prod/obsolete.” okflint lets you declare that in a YAML manifest (okf-base.yaml) and then enforces it. No vocabulary comes hardcoded — the engine is fully generic.

One detail that matters if you use Obsidian: it resolves [[wikilinks]] against the entire vault, not just the bundle. A link to a note outside the bundle won’t trigger a false positive.

Install:

# Via uv (recommended)
uv tool install okflint

# Or pip
pip install okflint

# Validate a bundle
okflint validate --manifest okf-base.yaml ./my-bundle/

In CI it looks like this:

- name: Validate OKF conformance
  run: |
    pip install okflint
    okflint validate --manifest docs/okf-base.yaml docs/

18 documented rules (with error examples and fix instructions for each), JSON output for pipeline parsing.

Stack: Python 3.12+, MIT. v0.4.1 released Sep 14, 2026.

Links: github.com/mattdav/okflint · PyPI · API docs

Author: mattdav

How it fits with superops-team/okf: complementary, not competing. The Go CLI generates bundles from source code and keeps them in sync via git hooks. okflint doesn’t generate anything — it only validates. One produces, one gates. Makes sense to use both.

🟢 Maturity: Released. Tight scope — does one thing well. The real differentiator is the profile system: you declare your rules, it enforces them. No magic, no AI, no baked-in opinions.

okf-guard (Content Safety)

A content-safety scanning layer that runs before your OKF generator. While okflint validates bundle structure, okf-guard screens the source files (PDF, DOCX, PPTX, XLSX, HTML) for hidden text and prompt-injection patterns before they’re converted into trusted knowledge.

The problem it solves: attackers can smuggle malicious instructions into documents using white-on-white text, zero-width characters, hidden spreadsheet rows, or off-canvas shapes. A human reviewing the document sees nothing; an LLM parser extracts everything. okf-guard catches this before the content enters your knowledge base.

Three actions:

• pass — clean content, no issues found
• quarantine — suspicious signals, needs human review
• block — high-confidence attack detected

Philosophy: Screen before write. Hidden content + pattern matching (not just regex). Conservative defaults — v0.1.0 is deterministic with no LLM judgment layer, so it prefers false positives over false negatives.

Quick start (CLI):

# Install via pipx (recommended for CLI use)
pipx install "okf-guard[all]"

# Scan a file
okfguard scan document.docx

# Scan a directory recursively, JSON output for CI
okfguard scan -r /docs/uploads --json > scan_log.json

Quick start (Python API):

from okfguard import sanitize

result = sanitize("suspicious_document.pdf")
print(f"Action: {result.action}")       # "pass", "quarantine", or "block"
print(f"Risk Score: {result.risk_score}")
print(f"Clean Text: {result.clean_text}")

# OKF v0.2 provenance fields ready for your bundle
print(result.provenance_fields)

Exit codes: 0 pass, 1 quarantine, 2 block, 3 error — ready for CI gates.

Stack: Python · Apache-2.0 · v0.1.0 (Aug 2026)

Link: github.com/darshanNhb/okf-guard

Limitations:

• No OCR or image analysis (steganography, text in images)
• No macro/VBA analysis — content only
• PDF render mode 3 detection is partial (underlying libs don’t reliably expose it)
• Doesn’t move/delete files — returns a decision, your pipeline enforces it

How it fits with okflint: Sequential, not competing. okf-guard screens source documents before conversion; okflint validates OKF bundles after generation. Pipeline: sources → okf-guard → generator → okflint → deploy.

🟡 Maturity: Early. v0.1.0, single maintainer, minimal stars. But the implementation is solid: proper package structure, tests, CI, honest documentation of limitations. Fills a real gap — nobody else is doing pre-generation content safety for OKF pipelines.

OKPH (OKF + Graph)

CLI and library that builds Mermaid dependency graphs over OKF bundles, runs Git-based impact analysis, and validates bundles against the spec. Think of it as git diff for your knowledge base — but instead of showing line changes, it shows which documents are affected by what changed.

What makes it interesting:

• okph graph ./docs → generates Mermaid dependency graph with clickable links
• okph affected --git main → shows changed files + transitive dependents (great for PR reviews)
• okph validate ./docs → checks bundle against OKF spec (errors for MUSTs, warnings for SHOULDs)
• okph deps/dependents → trace what a file links to or what links to it
• Respects reserved files (index.md, log.md) per spec §3.1
• No network calls, no telemetry — fully offline
• Library API available for programmatic use

Example — “what might need review after this branch”:

# See what changed
$ git diff --name-status main -- docs/
A       docs/new-policy.md
M       docs/orders.md
D       docs/legacy.md

# Generate affected graph (skipping reserved files)
$ okph affected --git main --root docs --graph --exclude '**/{index,log}.md' \
    --base-url https://github.com/octocat/okf-docs/blob/main/docs

Changed files are colored by status: green = added, amber = modified, red = deleted. Nodes link straight to the files on GitHub.

Install:

npm install -g @fcmam5/okph
# Or use npx
npx @fcmam5/okph graph ./docs

Stack: TypeScript / Node.js (>=24) · MIT · v0.7.0 (Sep 22, 2026)

Links: github.com/Fcmam5/okph · npm

How it compares to other validators: okflint focuses on spec conformance (MUST/SHOULD rules) and profile enforcement. okf-guard screens source documents for hidden content. OKPH adds the dimension of change impact — it doesn’t just tell you if your bundle is valid, it tells you which documents are affected when you change something. Particularly useful in CI pipelines where you want to know the blast radius of a PR.

🟡 Maturity: Functional. Well-documented CLI with clear API. Supports OKF v0.2 spec validation and graph generation. New tool in early adoption phase, but the feature set for impact analysis workflows is solid.

OKF-Schema (JSON Schema Validation)

Brings JSON Schema validation to OKF bundles. Instead of just checking “does this file have a type field?”, okf-schema validates the structure of your frontmatter against schemas you define per type. Think of it as type-checking for your knowledge base.

The core idea: For each type in your bundle, there’s a corresponding schema file under _schema/. Schemas can be written in YAML, JSON, or JSON5 (JSON with comments and trailing commas). The schema defines required fields, allowed values, and documentation for each property. When you run okf-schema validate, it checks every concept file against its type’s schema and gives you actionable feedback.

What the project provides:

The clever bit: The schemas are committed inside the bundle (_schema/ folder), so they travel with your knowledge. No external registry, no version mismatch. Clone the bundle, run the validator, done.

Quick start:

# Install the CLI in an isolated environment (recommended)
uv tool install okf-schema

# Validate a bundle
okf-schema validate --path ./my-bundle/

# Or use the okfkb workflow
okfkb init ./new-kb
okfkb validate ./new-kb

Example schema (in _schema/concept.schema.json):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["type", "title", "status"],
  "properties": {
    "type": { "const": "concept" },
    "title": { "type": "string", "minLength": 1 },
    "status": { "enum": ["draft", "review", "accepted"] },
    "sources": {
      "type": "array",
      "items": { "type": "string", "format": "uri" }
    }
  }
}

Stack: Python · MIT · v0.12.0 (Sep 2, 2026) · PyPI

Links: github.com/gsemet/okf-schema · Documentation · Examples

How it compares to okflint: Different philosophies. okflint validates against a fixed rule set (OKF spec + your profile YAML). okf-schema validates against JSON Schemas you define per type — more configurable, more explicit, and intentionally stricter. A valid OKF bundle can fail when it doesn’t match the schemas committed with that bundle. okflint is “does this follow OKF conventions?”; okf-schema is “does this match the exact shape I declared?”. Both can run in CI.

Limitations:

• There is no built-in schema inference. In practice, an LLM can derive a starting schema from a few representative concepts
• The okfkb and okfreq workflows are opinionated — useful if they match your use case, overhead if they don’t

🟢 Maturity: Production-ready. Published on PyPI with 22 GitHub stars, documented on ReadTheDocs, real examples in the repo. The most mature Python validator in the ecosystem — still under active development (commits through Oct 2026).

Author: gsemet

okf-mcp (Validator + MCP Server)

A local-first consumer, validator, graph index, CLI, and MCP stdio server for OKF v0.2 bundles. Its distinctive part is the write side: configured producers read an external system and return a candidate bundle; okf-mcp validates it, then publishes it under an ownership manifest that records exactly which files it owns. Hand-authored content is never adopted, and a source that didn’t change rewrites nothing.

What it offers:

• Validation of OKF v0.2, with v0.1 compatibility (timestamp and # Citations fallbacks) and review-only migration checks
• Search and graph navigation — in-memory BM25+ search (MiniSearch), neighbors, paths, provenance traversal, trust tiers, and freshness checks
• MCP stdio server exposing validation, search, graph, and provenance tools; proposal-based authoring with explicit acceptance (mcp --authoring)
• Producer host — producer list|preview|run; okf-postgres is the first producer
• Attested Computation contracts are inspected statically — nothing is executed, nothing is attested

Zero infrastructure: no database, no embeddings, no build step, no hosted service. --root mode makes no network calls; optional remote loading only fetches public Markdown from GitHub.

Quick start:

# Validate a bundle (Node.js 22+)
npx -y @mfdaves/okf-mcp@0.9.1 --root ./my-bundle validate

# Or install globally (ships the `okf` and `okf-mcp` binaries)
npm install --global @mfdaves/okf-mcp@0.9.1
okf --root ./my-bundle search "orders"
okf-mcp --root ./my-bundle mcp

MCP config:

{
  "mcpServers": {
    "okf": {
      "command": "npx",
      "args": ["-y", "@mfdaves/okf-mcp@0.9.1", "--root", "/absolute/path/to/okf", "mcp"]
    }
  }
}

Stack: JavaScript/Node.js (>=22) · MIT · v0.9.1 (Sep 19, 2026)

Links: github.com/mfdaves/okf-mcp · npm

Watch the name: a different project, travisjakel/okf-mcp (okf-mcp on PyPI, v0.5.1), exposes okf-ingest’s consume verbs as MCP tools. This section covers the npm package @mfdaves/okf-mcp.

How it compares to other validators: okflint and OKF-Schema are CI gates; OKPH measures change impact. okf-mcp is the one that also serves the bundle to agents over MCP and safely writes generated content into it.

Limitations:

• Pre-1.0 and moving fast (0.3.2 in Jul → 0.9.1 in Sep 2026); flags and APIs still change
• Small community (7 GitHub stars)
• Workspaces (okf.project.yaml), okf:// locators, and typed relations are okf-mcp extensions, not part of OKF v0.2
• The package installs a binary named okf — the same name used by superops-team/okf and OKF Agent Memory

🟢 Maturity: Released, moving fast. Published on npm with build provenance and listed in the official MCP Registry. Unusually clear documentation of what is OKF v0.2 versus what is an okf-mcp extension. Still pre-1.0, so pin the version (@0.9.1) in production configs.

Kiso (Publishing)

Kiso takes an OKF bundle and turns it into a static website that serves both humans and AI agents. It’s a Java CLI (Apache-2.0) with a dead-simple surface: check validates your markdown structure, build generates the site. The output automatically includes llms.txt and sitemap.xml — no extra config needed.

What makes it worth a look: it ships a GitHub Action so you can wire it into CI in minutes, supports DaisyUI themes for styling without touching CSS, and uses publishing profiles (.kiso/<profile>/configuration.yaml) so you can maintain multiple output configs from one bundle. The check command runs validation before building, which means broken structure fails fast instead of producing a broken site.

Quick start:

# Validate your bundle
./kiso-cli check --source=my-bundle

# Build the static site
./kiso-cli build --source=my-bundle --destination=public

GitHub Action:

- name: Build with Kiso
  uses: oak-invest/kiso/applications/kiso-cli-action@v0.2.5
  with:
    command: build
    source: my-bundle
    destination: public

Configuration (.kiso/configuration.yaml):

site:
  baseUrl: https://knowledge.example.com/
  language: en
  title: My Knowledge Base
  description: Documentation for humans and AI agents

theme:
  name: corporate

content:
  ignorePatterns:
    - drafts/**
    - internal/**

Stack: Java · Apache-2.0 · v0.2.5 (Sep 23, 2026)

Link: github.com/oak-invest/kiso · Website

🟢 Maturity: Released. It works, it ships tagged releases, and the GitHub Action means you can actually use it in production pipelines today. v0.2.0 added full OKF v0.2 support (provenance, trust, computation metadata) and an MCP server for AI agents. 47 stars, active development.

OpenWiki 0.2 (LangChain)

Reads your codebase, generates a structured wiki in OKF format, and wires it into agent instruction files (CLAUDE.md, .cursorrules, AGENTS.md). Coding agents then read the wiki instead of re-discovering project context from scratch every session. Harrison Chase announced OKF support with “there needs to be an OPEN standard for memory. OKF is one such standard.”

The practical value: you stop repeating yourself to agents. OpenWiki maintains a living knowledge base that stays in sync with your code. It handles the tedious parts (architecture summaries, module relationships, key decisions) and outputs them in a format any LLM can parse without custom tooling.

Quick start:

# Node.js 22.22+ (the PyPI package named "openwiki" is an unrelated project)
npm install -g openwiki

# Connect your coding agent (codex, claude, cursor, opencode, ...)
openwiki integrations install claude

# Then ask the agent: "Initialize this repository's OpenWiki from the current source and tests."
# Or run it standalone with your own model provider:
openwiki code --init

Stack: TypeScript / Node.js · MIT · v0.7.0 (Oct 2, 2026)

Link: github.com/langchain-ai/openwiki · Blog post

🟢 Maturity: Production-ready. Backed by LangChain (the org, not just the framework). 16.9K stars, 1.2K forks, very active development. The openwiki integrations install command that wires it into your coding agent solves a real daily pain point. v0.4.0 adopted OKF v0.2 with auto-generated provenance. OKF adoption here signals that the format has crossed from “spec Google published” to “thing other companies build on.”

Libraries & SDKs

Native implementations for embedding OKF in your own tooling.

W4G1/okf (Rust)

The most complete native implementation of OKF outside of Google’s reference tools. A pure-Rust toolkit covering the full OKF v0.2 spec: parsing, validation, linting, trust tiers, and an interactive TUI for exploring bundles.

What you get:

CLI commands:

• okf init — scaffold a new bundle
• okf new — create a new concept file
• okf validate — check conformance against OKF v0.2
• okf lint — style and hygiene checks
• okf trust — manage trust tiers
• okf graph — visualize the link graph
• okf mv, okf rm — refactor without breaking links
• okf split, okf merge — bundle operations
• okf diff, okf fmt — comparison and formatting
• okf studio — launch the TUI explorer

Install:

# From crates.io
cargo install okf

# Or as a Cargo plugin (`cargo okf <command>`)
cargo install cargo-okf

Stack: Rust · Apache-2.0 · v0.2.7 (Sep 4, 2026) · crates.io

Link: github.com/W4G1/okf

Limitations:

• Pre-1.0: the okf, okf-core, and cargo-okf crates are still at 0.2.x
• The TUI is functional but minimal
• No MCP server (yet)

🟢 Maturity: Released. 27 stars, 72 commits, active development. The only Rust implementation with full v0.2 coverage. If you’re building Rust tooling that needs to read/write OKF, this is it. The CLI alone is worth trying — okf studio makes bundle exploration genuinely pleasant.

Roteiro (Knowledge Graph — Producer + Consumer + Validator)

A provenance-tagged knowledge graph for codebases that writes AND reads OKF bundles, with a conformance checker and a viewer for bundles it did not produce. The most complete OKF implementation outside the reference tools — covering all three categories: generator, consumer, and validator.

What it does with OKF:

• Writes bundles from the graph (roteiro render okf) — per-directory index.md, typed concepts, markdown links between them
• Reads external bundles (roteiro import --from okf) and imports as external knowledge, recording the upstream’s trust tier without inheriting it
• Validates conformance (roteiro okf validate — errors gate) and hygiene (roteiro okf lint — reports only), alongside info, trust, links, syntax, computations, and diff
• Screens imported concept bodies before they become graph content — three verdicts, with a block reserved for a model directive that is also concealed
• Views external bundles, resolving links through a key-to-path map built after placement

Key commands:

# Install from crates.io
cargo install roteiro

# Generate OKF bundle from codebase
roteiro index .
roteiro render okf --output ./knowledge-bundle/

# Import external bundle as knowledge
roteiro import --from okf /path/to/external-bundle

# Validate OKF conformance
roteiro okf validate ./my-bundle/   # gate — fails on error
roteiro okf lint ./my-bundle/       # reports only

Stack: Rust · MIT/Apache-2.0 · v6.1.0 (Sep 29, 2026) · Separate library rto-okf-syntax for fenced code block parsing

OKF version: v0.2, pinned at commit ad30107c — interoperability fixtures vendor two of the spec repo’s own bundles at exactly that commit

Dependency: Uses okf-core (W4G1/okf) as the underlying parser

Link: github.com/OffeneDatenmodellierung/Roteiro

Declared limitations:

• sources entries carry resource only — no id, title, or author
• No footnotes or log.md emission
• The reader currently discards a peer’s title and author on import
• Two hygiene lints (L5 and L6) cannot fire against own output due to the above

🟢 Maturity: Production tool. 2,000+ commits, mature codebase, published on crates.io. The only tool covering producer + consumer + validator in a single package. If you want a knowledge graph that speaks OKF fluently — reading, writing, and validating — this is the most complete option.

OKF-Runtime (Consumer + Library)

A lightweight, deterministic consumption engine for OKF bundles. While most OKF tooling focuses on authoring, validation, or enrichment, OKF-Runtime focuses on efficient consumption: discovering bundles, parsing metadata, indexing, and building link graphs — all without requiring a database, daemon, or external services.

What it does:

• Filesystem scanner — discovers OKF bundles automatically
• Markdown/YAML parser — extracts frontmatter metadata
• Cache-based indexes — metadata, tags, types, all indexable
• Link graph construction — forward and reverse link graphs between concepts
• Composition — creates temporary topic bundles without mutating source files
• Validation — checks links, anchors, and graph structure
• Trust & provenance — derives trust tiers and staleness from v0.2 frontmatter (sources, generated, verified, status, stale_after)

Design principles:

• Deterministic before AI — solve retrieval tasks without consuming LLM context
• Library first — runtime logic in reusable modules, not just CLI wrappers
• Filesystem is source of truth — markdown files remain authoritative
• Zero infrastructure — no database server, no background daemon, no cloud service
• Progressive enhancement — features layer cleanly from filesystem to CLI to optional agent integrations

CLI commands:

• discovery — find OKF bundles in a directory tree
• catalog — list concepts with metadata
• query — search by type, tags, or text
• graph — visualize forward/reverse links
• compose — create temporary bundles by topic
• lint — validate bundle structure

Repository structure:

okf_runtime/    ← runtime library and CLI
scripts/        ← thin agent-facing entry point
references/     ← agent-facing usage and specification material
docs/           ← architecture, decisions, contribution guidance
tests/          ← runtime tests and fixtures

Stack: Python · MIT · SKILL.md-conformant Agent Skill · no tagged releases yet (last push Sep 19, 2026)

OKF version: v0.1 and v0.2 supported

Link: github.com/spomytkin/OKF-Runtime

How it compares to other tools: Roteiro and W4G1/okf are producer + validator tools (they generate and check bundles). OKF-Runtime is a pure consumer — it reads bundles efficiently without modifying them. Use OKF-Runtime when you’re building tooling that needs to traverse and query existing bundles deterministically, without spinning up an LLM.

Limitations:

• Python only (additional runtimes on roadmap)
• No MCP server yet (agent-facing entry point exists in scripts/)
• Phase 1.5 implementation — some advanced features still in roadmap

🟡 Maturity: Functional. Clean architecture with separation between runtime library and CLI. The deterministic approach fills a real gap — most other tools either require LLM calls or focus on generation rather than consumption. Worth evaluating if you’re building agent tooling that needs to read OKF bundles at scale without burning tokens.

Trust & Provenance

Verification, signatures, and on-chain proof for bundles.

signed-okf (Trust Layer)

OKF v0.1 metadata stopped at a timestamp (v0.2 adds generated/verified, but still no signatures). No way to verify who wrote it, whether it was tampered with, or if the claimed authorship is real. signed-okf adds the missing trust layer: it hashes every file in a bundle, wraps the hashes plus a provenance envelope in a manifest (okf.manifest.json), and Ed25519-signs it.

The problem this solves becomes obvious when OKF bundles start flowing between organizations. If an agent ingests a bundle claiming to be “Goldman Sachs investment criteria,” how does it know? signed-okf gives you verify as a one-liner. Google acknowledged this gap in the v0.1 spec discussion.

Quick start:

# Not on PyPI/npm: clone the repo and run the scripts (needs `cryptography`)
git clone https://github.com/Fluxdyne/signed-okf && cd signed-okf
pip install cryptography

python sign_okf.py keygen
python sign_okf.py sign examples/okf-bundle --issuer acme.example --source "ACME Data Warehouse"
python verify_okf.py examples/okf-bundle --jwks issuer.pub.json

Stack: Python 3.8+ (scripts) · Apache-2.0 · no tagged releases (published Jun 23, 2026)

Link: github.com/Fluxdyne/signed-okf · dynamicfeed.ai

🟡 Maturity: Early but solving a real gap. The signing and verification scripts work. It’s two Python scripts plus a SPEC.md — no package, no tagged release, and no commits since Jun 23, 2026. Small star count, young project. Worth watching because provenance becomes critical once OKF bundles are consumed across trust boundaries.

Agent Memory & Skills

OKF as runtime memory or instruction set for AI agents.

hermes-okf (Agent Memory)

A filesystem-based memory system that stores everything an agent decides, observes, and plans as OKF concept files. Every session builds on the last. The knowledge graph is human-readable markdown you can inspect, edit, or version-control with git.

What separates this from “just dump JSON to disk”: the memory is structured by OKF types (decisions, observations, context, plans), cross-linked with internal references, and queryable through the HermesAgent tool registry. The agent doesn’t just remember; it navigates its own history as a knowledge base.

Quick start:

pip install hermes-okf

# Register the Hermes plugin and check the setup
hermes-okf install-plugin
hermes-okf validate-config

# Select hermes-okf as the memory provider
hermes memory setup

# Then, inside Hermes
hermes okf search "dark mode"

Stack: Python · MIT · v0.5.9 (Jun 23, 2026)

Link: github.com/EliaszDev/hermes-okf · PyPI

🟡 Maturity: Functional, niche audience. Works as advertised. The tight coupling to HermesAgent limits adoption to that ecosystem. If you use Hermes, this is the obvious memory backend. If you don’t, the architecture is still interesting as a reference for how OKF can serve as agent memory. 35 stars, 71 commits; no commits since Jun 25, 2026.

OKF Agent Memory

Git-native persistent project memory for AI coding agents, built on OKF v0.2 in pure Go with zero external dependencies. Not related to hermes-okf: it’s a standalone okf binary (CLI + embedded MCP server) that works with Claude Code, Cursor, Codex, and any other MCP client.

The idea, which the project calls Dual-Memory Agent Architecture (DMAA): keep AGENTS.md as a tiny normative “push” layer (~100–150 tokens of rules and triggers, written in a compact micro-syntax called Agent Action Grammar), and move everything else into an OKF bundle in knowledge/ that the agent “pulls” on demand via search. The bundle costs zero tokens until it’s queried, and the whole memory is plain Markdown you can review with git diff.

What it offers:

• In-memory BM25 search over the bundle (okf search), plus --for-path to find decisions and constraints bound to a source file via code_refs before editing it
• Validation with graph-connectivity and description-drift checks (okf validate --strict --drift)
• Authoring with bookkeeping — okf create / okf update maintain index.md and log.md automatically
• okf bootstrap — scaffolds knowledge/, an agent skill, AGENTS.md, and a Makefile into any repo
• MCP stdio server (okf mcp knowledge)
• v0.5.0 (Oct 1, 2026): OKF Registry client (registry.okf-memory.dev), okf pull / okf restore / okf vendor with an okf.lock lockfile (SHA-256 checksums), and four-tier scope layering — project › vendor › user (~/.okf/) › system (/etc/okf/), where higher layers shadow concepts with the same ID

Quick start:

# Homebrew (macOS/Linux) — or grab a prebuilt binary from GitHub Releases
brew install okf-memory/tap/okf

okf bootstrap /path/to/project --name "My Project"
okf search "architecture layers" knowledge
okf validate knowledge --strict --drift

MCP config:

{
  "mcpServers": {
    "okf-memory": {
      "command": "/path/to/okf",
      "args": ["mcp", "/path/to/project/knowledge"]
    }
  }
}

Stack: Go (zero dependencies) · MIT · v0.5.0 (Oct 1, 2026) · binaries for macOS, Linux, and Windows

Links: github.com/okf-memory/okf-agent-memory · okf-memory.dev · Releases

How it compares to hermes-okf: both use OKF bundles as agent memory, but hermes-okf is a Python library tied to Hermes Agent; OKF Agent Memory is agent-agnostic — a single binary with an MCP server and an AGENTS.md convention on top.

Limitations:

• Very young and moving fast: first release Sep 5, 2026, and 16 GitHub releases up to v0.5.0 (Oct 1) — expect breaking changes
• The performance and token-savings figures (sub-300 µs search, ~80% fewer tokens) come from the project’s own benchmarks — reproduce them with make benchmark before quoting
• Adds its own conventions on top of OKF (DMAA, AAG, scope prefixes like @bundle/, user:, and system:) that other OKF tools don’t understand
• The binary is called okf, the same name as superops-team/okf (and one of okf-mcp’s binaries) — check your PATH if you use more than one

🟡 Maturity: Fast-growing, still pre-1.0. 740+ GitHub stars in its first month, CI, tests, a Homebrew tap, and cross-platform binaries. The v0.5.0 registry and lockfile just shipped — worth trying, but pin versions while the interfaces settle.

Inkeep Open Knowledge

A local-first, AI-native markdown editor that grew into a full knowledge-base platform during its Aug 17–21, 2026 launch week: desktop apps for macOS, Windows, and Linux, git-backed sync, agentic search (embeddings + hierarchical RAG), and native chat integrations with 30+ coding agents via ACP. A Notion-like rich editor that stays plain markdown on disk.

For agents, three surfaces matter:

• Native MCP server (@inkeep/open-knowledge) — read/write tools (ingest, research, consolidate) plus write-time warnings when content drifts out of conformance
• Bundled agent skills — including okf-knowledge-base for OKF semantics (see plugin below)
• Committed .mcp.json pattern — bundles like the Odyssey wiki ship repo-level configs, so Claude Code/Codex offer to start the server on open

Quick start:

# Download the desktop app (Mac/Win/Linux)
# https://openknowledge.ai/download

# Or run the MCP server headlessly
npx -y @inkeep/open-knowledge@^0.58 mcp

Stack: TypeScript · GPL-3.0 · Desktop GA (Aug 2026) · ~4.4K GitHub stars

Links: openknowledge.ai · github.com/inkeep/open-knowledge

🟢 Maturity: Released. Went from web preview to multi-platform desktop apps in five weeks. The OKF plugin below is what makes it an OKF-native editor rather than just another markdown app.

OKF Plugin (OpenKnowledge)

Announced Aug 21, 2026 as “part linter, part skill, part MCP tools.” Translates OKF v0.2 into continuous conformance feedback inside the OpenKnowledge editor, CLI, and agents. Everything it flags is a warning — it never blocks writes.

Six frontmatter rulesets (schemas generated to .ok/okf/*.schema.json):

• Required — non-empty type on every concept file
• Recommended — title, description, tags (a list), resource
• Provenance/lifecycle — sources[], generated {by, at}, verified[], status, stale_after
• Computation — type: Attested Computation shape (runtime, parameters, executor.receipt, attester)
• Index files ×2 — no frontmatter, except okf_version: "0.2" in root

Plus body/portability rules: index list shape, ISO-8601 log headings, no wikilinks, no .mdx.

Three ways to run it:

It can also auto-generate machine-owned index.md files per directory (grouped by type), kept merge-conflict-free via a .gitattributes rule. Ships with the okf-knowledge-base skill so agents know both the spec and the tooling.

How it compares to okflint: same philosophy — deterministic lint, warnings not blocks. Different delivery: okflint is a standalone Python CLI built for CI pipelines; this lives where agents write. Both can run together.

Links: Announcement · Docs

🟢 Maturity: Released. Day-one coverage of OKF v0.2 including Attested Computation.

knowledge-template (Science)

A conformant, empty OKF bundle designed specifically for scientific knowledge management, with four annotated example concepts (a dataset, a gotcha, a recipe, a convention).

Conformance target: OKF v0.2 plus the Open Science Pillars knowledge-layer requirements (docs/SPECIFICATION.md in open-science-pillars/marketplace). Fork it, delete the examples, start filling in your own research. That’s the entire workflow.

Quick start:

# Copy the repository (it is not marked as a GitHub template)
git clone https://github.com/open-science-pillars/knowledge-template.git my-research-kb
cd my-research-kb
# Rename it in .osp/repository.yaml, delete the four example-* concepts,
# then run the OKF v0.2 checker described in the README

Stack: Markdown (no runtime) · Apache-2.0 · no tagged releases (last push Sep 20, 2026)

Link: github.com/open-science-pillars/knowledge-template

🟢 Maturity: Ready to use. It’s a template. There’s nothing to break. The annotated examples are genuinely helpful for understanding how OKF maps to scientific concepts. If you’re in academia or research and want to organize knowledge in a format agents can consume, start here.

OriginTrail DKG + OKF

Connects OKF bundles to the OriginTrail Decentralized Knowledge Graph. Each bundle gets an owner, a cryptographic proof of origin, and immutability recorded on-chain. The import is deterministic (no LLM in the path) and produces Knowledge Assets with cryptographic provenance (a Merkle root plus an EIP-712 attestation). The real value: AI agents can query the DKG, verify who published a bundle, and decide whether to trust it based on on-chain attestation rather than blind faith. This is the first integration that treats OKF bundles as verifiable assets rather than static files.

Quick start:

# Requires a running DKG node (github.com/OriginTrail/dkg)
dkg okf import ./bundle --context-graph-id my-graph --create-context-graph

Stack: TypeScript · Apache-2.0 · ships in the OriginTrail DKG node (packages/okf; node v10.0.19, Sep 28, 2026)

Link: Google’s OKF comes to the OriginTrail DKG: A memory AI agents can trust · DKG docs: OKF import/export

🟡 Maturity: Concept proven, not production-hardened. Announced Jul 1, 2026; the importer ships in the DKG node and as the npm package @origintrail-official/dkg-okf (latest 10.0.20, Sep 29, 2026). Requires familiarity with OriginTrail’s DKG node setup. Interesting direction, but early.

openknowledgeformat.com

A community site where you paste YAML frontmatter and get instant validation against the OKF spec. No install, no CLI, no dependencies. Also includes starter templates and interactive examples showing valid bundle structures. Useful for quick checks when you’re hand-authoring bundles or debugging why a tool’s output isn’t conformant.

Quick start:

# No install needed. Open the site, paste your frontmatter, validate.

Stack: Web · N/A · Live (Jun 13, 2026)

Link: openknowledgeformat.com

🟢 Maturity: Ready to use today. Works in the browser, zero setup. Validates against the current spec. Good first stop for anyone new to OKF who wants to see what a valid bundle looks like before committing to a CLI tool.

okf-skill (Agent Skill)

A single markdown file that acts as an Agent Skill for Claude Code, Cursor, Hermes, or any agent supporting the skills format. Drop it into your .agents/skills/ directory and the agent learns how to produce and consume OKF-conformant bundles. References the full spec inline. Fills a specific gap: instead of building tooling around OKF, this makes the agent itself the tool.

Quick start:

# Via skills.sh (detects Claude Code, OpenCode, Codex, ...)
npx skills add rakibtg/okf-skill

# Or manually: copy the skills/okf-skill folder from the repo
mkdir -p .claude/skills && cp -r skills/okf-skill .claude/skills/okf-skill

Stack: Markdown + Python stdlib scripts (Agent Skill) · Apache-2.0 · no tagged releases · vendors the OKF v0.1 spec

Link: rakibtg/okf-skill

🟡 Maturity: Works, but scope is narrow. It’s a single file with instructions. Effectiveness depends on your agent’s ability to follow skill files consistently. No validation logic built in. Pairs well with openknowledgeformat.com for verification after generation.

leadcraft

A Claude Code plugin that helps tech leads write and refine structured deliverables (plans, estimates, architecture decisions, design docs) and stores them as an OKF v0.1 conformant Knowledge Bundle. Output is YAML frontmatter plus a markdown directory tree, organized by a five-level planning model (Objective / Initiative / Epic / Story / Task). Readable by humans and AI agents. Version-controllable with git.

Quick start:

# Inside Claude Code
/plugin marketplace add dskst/leadcraft
/plugin install leadcraft

Stack: Claude Code plugin (Markdown skills) · MIT · no tagged releases (Jun 24, 2026)

Link: dskst/leadcraft

🟡 Maturity: Early stage, limited documentation. The core idea works: planning artifacts out, as an OKF bundle. But docs are sparse and the project is new (no commits since Jun 24, 2026). Expect to read the skill files to understand configuration options. Worth watching if you want your plans and decisions to be agent-readable.

pi-openwiki (Pi coding agent)

LangChain’s OpenWiki agent adapted as an extension for the Pi coding agent. Automatically generates and maintains comprehensive codebase documentation using Pi’s AI capabilities. Produces the same OKF output format as the original OpenWiki project. If you already work in Pi, this gives you OKF bundle generation without switching toolchains.

Quick start:

# Install the extension through Pi, then run its commands inside Pi
pi install npm:pi-openwiki
/openwiki:init
/openwiki:update

Stack: TypeScript (Pi extension) · MIT · v1.0.0 on npm (Jul 7, 2026)

Link: barvhaim/pi-openwiki

🟡 Maturity: Fresh port, narrow audience. Published Jul 2026; no pushes since Jul 7, 2026. Requires Pi, which limits who can run it. Outside Pi, the original OpenWiki is more accessible (and now integrates with Pi itself). But it validates that OKF output is portable across agent frameworks.

8. Emerging Patterns (Not Yet Tools)

These aren’t tools yet, but patterns that multiple teams are converging on:

OKF + llms.txt Discovery

Several analysts (Marie Haynes, StartupHub) speculate that llms.txt will point agents to OKF bundles. No official mechanism exists yet. The pattern would be:

# llms.txt
...
## Knowledge Bundle
- /knowledge/index.md: OKF bundle root — organizational knowledge for agents

Status: Speculation. Makes logical sense but not confirmed by Google.

OKF Marketplace / Bundle Commerce

Marie Haynes argues OKF bundles will become sellable products — lawyers, accountants, SEOs packaging their expertise as purchasable bundles that integrate into your own OKF.

Status: Pure speculation. Interesting but no infrastructure exists.

OKF + Obsidian as IDE

Karpathy’s framing: “Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.” Several teams now use Obsidian to author OKF bundles while agents maintain cross-references.

Status: Working pattern. No dedicated plugin but zero friction.

Ecosystem Timeline & Opportunities

Moved to the dedicated Ecosystem Map.

See also

• OKF Spec — the annotated format guide
• OKF FAQ — what the format is and how agents use it
• OKF Skill — teach your coding agent the format
• Ecosystem Map — maturity and opportunity gaps