OKF Ecosystem Tools

An honest inventory of what exists today (Sep 2026) around the Open Knowledge Format. For each tool: what it does, how mature it actually is, and whether you should bother.

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 enrichment_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file seeds.txt \
    --out ./bundles/<name>

# BigQuery only (no web crawl)
.venv/bin/python -m enrichment_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

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.

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.

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.)

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

🟡 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. 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.

5. Possible Integrations

5.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.

5.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 okf-validator  # when it exists
      - run: okf 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 enrichment_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.

5.3 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.

6. 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

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.

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. Filing issue on 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/aix-validate.py path/to/bundle --level 2
python3 tools/aix-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/aix-format (spec, validator, examples; v0.2 released 2026-08-20)

Limitations:

• One producer 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). 22 stars, active development with frequent releases.

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.0 released Aug 29, 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.

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.11.1 · 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 18 stars, documented on ReadTheDocs, real examples in the repo. The most mature Python validator in the ecosystem — active development with updates every few days.

Author: gsemet

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.3
  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.3 (Aug 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. 33 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:

pip install openwiki

# Generate wiki from your codebase
openwiki init --path .

# Update after changes
openwiki sync

# Wire into agent instruction files
openwiki wire --target claude,cursor

Stack: Python · MIT · v0.5.0 (Sep 2026)

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

🟢 Maturity: Production-ready. Backed by LangChain (the org, not just the framework). 16K stars, 1.2K forks, very active development. The wire command that injects context into agent files 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:

# Via cargo (from source)
cargo install --git https://github.com/W4G1/okf

# Or clone and build
git clone https://github.com/W4G1/okf
cd okf && cargo build --release

Stack: Rust · Apache-2.0 · v0.2.6 (Aug 2026)

Link: github.com/W4G1/okf

Limitations:

• Not yet published to crates.io (install from git)
• The TUI is functional but minimal
• No MCP server (yet)

🟢 Maturity: Released. 19 stars, 69 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 · v5.13.0 (Sep 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. 1,527 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.

Trust & Provenance

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

signed-okf (Trust Layer)

OKF metadata includes a last_updated timestamp. That’s it. 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: cryptographic signatures on individual concept files and entire bundles, with optional on-chain anchoring via OriginTrail’s Decentralized Knowledge Graph.

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:

pip install signed-okf

# Sign a bundle
signed-okf sign ./my-bundle/ --key ~/.keys/okf-signing.pem

# Verify a bundle
signed-okf verify ./their-bundle/

# Anchor to OriginTrail DKG (optional)
signed-okf anchor ./my-bundle/ --network mainnet

Stack: Python · Apache 2.0 · v0.2.1 (Jul 2026)

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

🟡 Maturity: Early but solving a real gap. The signing and verification work. The OriginTrail integration is functional but adds complexity most teams don’t need yet. 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

# Initialize memory for a project
hermes-okf init --project my-app

# Use with HermesAgent
from hermes_okf import HermesAgent, MemoryStore

store = MemoryStore("./memory/")
agent = HermesAgent(memory=store)

Stack: Python · MIT · v0.5.9 (Jun 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. 34 stars, 71 commits, active development.

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) · ~3.6K 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. One fully annotated example per concept type (hypothesis, method, dataset, finding, review). Every file includes inline comments explaining why each frontmatter field exists and what goes there.

Conformance target: OKF v0.1 core plus the Open Science Pillars requirements from SPECIFICATION.md §5 (reproducibility metadata, citation chains, data provenance links). Fork it, delete the examples, start filling in your own research. That’s the entire workflow.

Quick start:

# Clone the template
gh repo create my-research-kb --template open-science-pillars/knowledge-template

# Or just grab the structure
git clone https://github.com/open-science-pillars/knowledge-template.git
cd knowledge-template
# Read SPECIFICATION.md §5 for the profile requirements
# Delete example files, keep the structure

Stack: Markdown (no runtime) · CC-BY-4.0 · v1.0 (Jul 3, 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. Published two weeks ago, already referenced by three university labs.

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. Built on top of signed-okf. 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:

# See the integration guide in the blog post below.
# Requires a DKG node or access to the OriginTrail testnet.

Stack: TypeScript · MIT · v0.1 (Jul 2026)

Link: Google’s OKF comes to the OriginTrail DKG: A memory AI agents can trust

🟡 Maturity: Concept proven, not production-hardened. Published Jul 4, 2026 as a blog post with working code. No standalone package yet. 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:

# Clone into your skills directory
git clone https://github.com/rakibtg/okf-skill .agents/skills/okf-skill

# Or just copy the SKILL.md file into your agent's skill folder

Stack: Markdown (Agent Skill) · MIT · v1.0 (2026)

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

Analyzes a repository and generates OKF v0.1 conformant Knowledge Bundles. Output is YAML frontmatter plus a markdown directory tree. Readable by humans and AI agents. Version-controllable with git. Point it at a repo, get a bundle that describes the codebase structure in OKF format.

Quick start:

# Clone and run against your repo
git clone https://github.com/dskst/leadcraft
cd leadcraft
# See README for usage

Stack: Unknown · Unknown · v0.1 (2026)

Link: dskst/leadcraft

🟡 Maturity: Early stage, limited documentation. The core idea works: repo in, OKF bundle out. But docs are sparse and the project is new. Expect to read source code to understand configuration options. Worth watching if you want automated bundle generation from codebases.

pi-openwiki (IBM PI)

LangChain’s OpenWiki agent ported to the PI (IBM) harness. 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’re already in IBM’s PI ecosystem, this gives you OKF bundle generation without switching toolchains.

Quick start:

git clone https://github.com/barvhaim/pi-openwiki
cd pi-openwiki
# Requires PI harness setup - see README

Stack: Python · Unknown · v0.1 (Jul 2026)

Link: barvhaim/pi-openwiki

🟡 Maturity: Fresh port, narrow audience. Published Jul 2026. Requires the PI harness, which limits who can run it. If you’re outside IBM’s ecosystem, the original OpenWiki is more accessible. But it validates that OKF output is portable across agent frameworks.

7. 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.

The Two Layers

The OKF ecosystem splits cleanly into two:

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 + catalog enrichment + GCP product. 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.

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