Ferramentas do Ecossistema OKF

Curadoria honesta das ferramentas que existem hoje (out/2026) ao redor do Open Knowledge Format. Para cada item: o que faz, como usar, onde encontrar, e minha opinião sobre maturidade. Versões, datas de release e stars do GitHub conferidas no GitHub, PyPI, npm e crates.io em 2 out 2026.

Migração de Repositório: OKF agora tem repositório próprio. O endereço canônico é GoogleCloudPlatform/open-knowledge-format. O caminho antigo (knowledge-catalog/okf/) é um snapshot congelado — não use para trabalhos novos.

1. Enrichment Agent (OKF — BigQuery → Bundles)

O que é: Um agente de referência que ingere metadata de uma fonte plugável (hoje BigQuery) e emite um bundle OKF completo — diretório de markdowns com YAML frontmatter prontos para humanos, LLMs e ferramentas de catálogo.

Como funciona:

• BQ pass: Gera um doc OKF por conceito usando apenas metadados do BigQuery (schemas, descrições, tabelas).

• Web pass: Aqui o bicho fica interessante. O LLM (Gemini via ADK) vira o próprio crawler. Recebe uma lista de seed URLs (via --web-seed ou --web-seed-file), busca via tool fetch_url, e decide sozinho quais links outbound vale a pena seguir — basicamente: “isso parece documentação autoritativa pro conceito X?” Se sim, segue. Pra cada página buscada, ele toma uma de três decisões:

  • (a) Enrich — adiciona citações, schemas ou join paths a docs existentes
  • (b) Mint — cria um doc standalone em references/<slug> pra aquela página
  • (c) Skip — não vale o token

  Pra não virar um webcrawl descontrolado: --web-max-pages define um cap hard e --web-allowed-host restringe por same-domain. Use --no-web pra pular o web pass inteiro.

Stack: Python 3.13, Google Agent Development Kit (ADK), Gemini como backend de modelo.

Como rodar:

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

# Credenciais
gcloud auth application-default login
export GEMINI_API_KEY=<sua-key>  # ou Vertex AI

# Rodar (mínimo)
.venv/bin/python -m reference_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file seeds.txt \
    --out ./bundles/<nome>

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

Bundles de exemplo incluídos:

• 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

Limitações:

• Só BigQuery como source (interface Source existe mas nenhuma outra implementação)
• Exige Gemini API key ou Vertex AI configurado
• O web pass pode consumir bastante token se os seeds forem muitos
• Não suporta incremental updates — roda do zero cada vez

🟡 Maturidade: Proof of concept funcional. Os bundles gerados são legítimos e úteis, mas o agente em si é uma demo do que é possível, não um produto pronto. Funciona de verdade para datasets públicos do BigQuery. Para uso em produção, você vai querer customizar o prompt e os seeds.

2. Static HTML Visualizer (viz.html)

O que é: Um subcomando visualize que pega qualquer bundle OKF e gera um arquivo HTML self-contained — grafo interativo de conceitos, painel de detalhes, busca, filtros por tipo, backlinks. Zero backend, zero instalação no lado do viewer.

O que mostra:

• Grafo force-directed (Cytoscape.js) com nós coloridos por tipo
• Painel lateral com frontmatter + body renderizado em markdown
• Links internos navegáveis dentro do viewer
• Seção “Cited by” (backlinks computados)
• Busca por título, ID, tags
• Layouts alternativos (cose, concentric, breadthfirst, circle, grid)

Como gerar:

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

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

Como consumir: Abra o viz.html em qualquer browser moderno. Pode hospedar em file server estático, compartilhar por email, commitar no repo.

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

Limitações:

• Bundles muito grandes podem gerar HTMLs pesados (tudo é inline no JSON)
• O viewer é um SPA minimal — não tem paginação, não tem lazy loading
• Depende de CDN para Cytoscape.js e marked.js (não é 100% offline sem ajuste)

🟢 Maturidade: Funciona de verdade. É simples, faz o que promete, e os viz.html commitados no repo são ótimos para demo. Para bundles de 10-50 conceitos, perfeito. Para 500+, provavelmente precisa de otimização.

3. Metadata as Code (kcmd) — Sync com Knowledge Catalog

O que é: Ferramenta de sync bidirecional entre metadata local (YAML/markdown no filesystem) e o Google Cloud Knowledge Catalog (antigo Dataplex). Pense em “git para metadados” — você edita localmente e faz push/pull para o catálogo cloud.

Formato: YAML para entries, sidecar .md para conteúdos ricos (overviews, descriptions). Organização hierárquica espelhando a estrutura de recursos.

Distribuição: TypeScript library (npm install kcmd), CLI standalone (kcmd), e MCP server.

Atenção: o README upstream diz npm install kcmd, mas o pacote kcmd que está hoje no registry do npm é um projeto sem relação, de 2022 (v1.0.16). Até sair um pacote correspondente, faça o build do source: clone o knowledge-catalog e rode npm install dentro de toolbox/mdcode.

Como usar (CLI):

# Inicializar snapshot de um dataset BigQuery
kcmd init --bigquery-dataset <projectId>.<datasetId>

# Puxar metadata do catálogo
kcmd pull

# Ver mudanças locais
kcmd status

# Enviar mudanças para o catálogo (com dry-run)
kcmd push --dry-run
kcmd push

Como usar (MCP Server):

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

Tools MCP disponíveis: pull, push, list-entries, lookup-entry, modify-entry (detalhes em 6.3 MCP Servers).

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

Limitações:

• Exige projeto GCP com Knowledge Catalog habilitado
• Autenticação via gcloud (não suporta service accounts direto)
• O formato YAML/sidecar é diferente do OKF puro (mais voltado para o catálogo Dataplex)
• Documentação ainda esparsa — o docs/concept.md referenciado existe mas é conceitual

🟡 Maturidade: Early product, mas bem estruturado. A CLI funciona, o MCP server é real, e o workflow push/pull faz sentido. O fato de ter library + CLI + MCP mostra intenção de ser usado em ambientes variados. Ainda não tem releases versionadas no npm.

4. Enrichment Agent (Toolbox — kcenrich)

O que é: Uma versão mais “production-oriented” do enrichment, integrada ao workflow do kcmd. Diferente do agente OKF (que gera bundles standalone), este enriquece metadata que já está no formato do catálogo.

Diferença do agente OKF:

• O OKF agent gera bundles markdown autônomos
• O kcenrich enriquece snapshots do Knowledge Catalog (formato kcmd)
• Usa MCP servers como sources (ex: md-fileset para crawlear docs locais)
• Customizável via prompt.md + diretório de tools/skills/

Como usar:

# Pré-requisito: ter um snapshot kcmd já inicializado
kcmd init --bigquery-dataset <project>.<dataset>
kcmd pull

# Rodar enrichment com tools customizados
kcagent enrich --catalog-path . --tools-path tools --prompt-path prompt.md

O README chama a CLI de kcenrich; o binário gerado pelo build (pacote kcagent) é o kcagent.

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

Limitações:

• Depende do kcmd (Metadata as Code) configurado
• O demo funciona mas requer setup BigQuery real
• Ainda não tem release binário standalone publicado (build do source com npm run build)

🟡 Maturidade: Mais proof of concept que produto. O demo é didático e funciona, mas é claramente um showcase de como combinar MCP + skills + catálogo. Não é “instala e sai usando” — precisa montar a infra de tools ao redor.

5. Google Cloud Knowledge Catalog (Ingestão Nativa)

O que é: O produto GCP (antigo Dataplex) que serve como catálogo de metadados AI-powered. É o “backend oficial” que o ecossistema de ferramentas acima sincroniza.

Features relevantes para OKF:

• 🆕 Ingestão nativa de OKF — Sim, o Knowledge Catalog agora engole bundles OKF direto e serve pros agentes. Sem conversão, sem middleware. Veja o demo e código.
• 🆕 Distribuição enterprise de OKF (agosto 2026) — escala bundles OKF pela organização:
  • Push de bundles via kcmd push com AspectType okf (sinaliza campos de trust v0.2: sources, generated, verified, status, stale_after)
  • Entries governadas por IAM: agentes veem só o que têm autorização
  • Caminho de retrieve do agente: searchEntries → LookupContext → entries.get(view=ALL)
  • Leia mais: Escalando OKF com Knowledge Catalog (26 ago 2026)
• Harvesting automático de BigQuery, AlloyDB, Spanner, Cloud SQL, Firestore, Looker
• Integrações 3P: Ab Initio, Anomalo, Atlan, Collibra, Datahub
• Enrichment nativo com Gemini — gera descrições, glossários, mapeia entidades
• Semantic search sub-segundo para agentes
• Context APIs + MCP tools para que agentes descubram assets
• Data products — empacotamento de assets com SLAs e governança

Pricing (resumo):

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

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

Limitações:

• Vendor lock-in GCP (o kcmd é a ponte para portabilidade)
• Pricing pode escalar rápido com muitos DCU-hours
• O “formato nativo” NÃO é OKF — OKF é a camada portável que interopera

🟢 Maturidade: Produto GA do Google Cloud. É real, funciona em produção, tem SLA, tem suporte enterprise. O Knowledge Catalog em si está maduro — o que é novo são as ferramentas open-source ao redor.

6. Possíveis Integrações

6.1 Obsidian

Status: Não existe plugin oficial, mas o OKF foi deliberadamente desenhado para funcionar com Obsidian out-of-the-box.

Por que funciona:

• Bundles OKF são diretórios de .md com YAML frontmatter — exatamente o que o Obsidian espera
• Links internos funcionam como wikilinks (paths relativos)
• Tags no frontmatter aparecem nativamente no Obsidian
• O index.md funciona como nota índice

Como usar hoje:

1. Gere um bundle OKF com o enrichment agent
2. Abra o diretório do bundle como vault no Obsidian
3. Navegue, edite, use o graph view nativo

O que faltaria para um plugin real:

• Validação inline (lint de conformidade OKF)
• Template para criação de novos conceitos
• Sync com Knowledge Catalog via kcmd

🟢 Compatibilidade natural. Não precisa de plugin — funciona por design. Um plugin seria nice-to-have para validação, mas não é blocker.

6.2 GitHub Actions

Status: Nenhum Action oficial publicado, mas os comandos são todos scriptáveis.

Workflows possíveis:

# .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 (mais avançado)
name: Enrich on Schedule
on:
  schedule:
    - cron: '0 6 * * 1'  # Toda segunda
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"

🟡 Potencial alto, implementação zero oficial. O workflow de “enrich → commit → PR” é natural para OKF. Nosso projeto (okf.md) poderia publicar um Action reutilizável como diferencial.

6.3 MCP Servers

Status: O kcmd mcp é real e documentado. É o ponto de integração mais maduro.

O que o MCP server do kcmd oferece:

Onde usar:

• Gemini CLI / Google AI Studio
• Claude Desktop (via MCP config)
• Cursor / VS Code (qualquer editor com suporte MCP)
• Agentes customizados (LangChain, ADK, etc.)

Também existe: O md-fileset MCP server (usado pelo toolbox/enrichment) para navegar diretórios de markdown como knowledge base.

🟡 Maturidade: kcmd MCP funcional. Está documentado com exemplo de config JSON e tools claras, mas ainda não tem releases versionadas no npm (build do source). O md-fileset é mais básico mas serve como padrão.

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

Status: Nenhuma skill oficial publicada (essa é justamente a oportunidade do nosso projeto).

O que existe hoje:

• O README do OKF funciona como documentação para um agente entender o formato
• O SPEC.md é legível o suficiente para um LLM gerar bundles conformantes
• O toolbox/enrichment usa tools/skills/ como diretório de skills do agente

O que falta (e onde entramos):

• Uma skill .md standalone que ensine qualquer agente a produzir OKF
• Validação em tempo de geração (o agente checa conformidade antes de salvar)
• Templates reutilizáveis para cenários comuns (SaaS metrics, analytics, APIs)

Padrão de skill que o toolbox já usa:

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

[instruções de uso das tools]

🟡 Oportunidade clara. O formato OKF foi feito para ser agent-friendly, mas ninguém empacotou isso como skill distribuível ainda. Nosso okf-skill será o primeiro.

Mapa de Maturidade

Pra uma visão visual de onde cada ferramenta se encontra (maturidade × barreira de entrada), veja o Mapa do Ecossistema dedicado.

Conclusão

O ecossistema OKF tem duas camadas claras:

1. Camada portável (OKF puro): Format spec + enrichment agent + visualizer. Funciona standalone, sem GCP. É onde vivem as oportunidades para comunidade.

2. Camada enterprise (Knowledge Catalog): kcmd + kcenrich + catálogo GCP. Funciona em produção mas exige infra Google Cloud.

Se você está construindo pra camada portável, dá pra começar hoje sem nenhuma dependência de cloud. Se precisa da camada enterprise, reserve orçamento pro setup GCP e espere uma rampa mais íngreme.

Nosso projeto (okf.md / okf.ia.br) se posiciona na camada 1 — tornando OKF acessível, validável e produzível por qualquer agente, sem dependência de cloud provider.

7. Ferramentas da Comunidade

A spec OKF saiu em 12 Jun 2026. Em semanas, implementações independentes apareceram em todas as categorias.

Geradores & Produtores

Ferramentas que criam bundles OKF a partir de conteúdo existente.

AgentFitech

Startup que construiu suporte OKF (producer + consumer) no dia seguinte ao lançamento. Documentaram no Medium: “Google just standardized ‘How AI Agents read the web’. Here’s how we shipped it in a day.”

Takeaway: O formato é simples o suficiente pra um time pequeno ir de zero a conformante em um sprint.

Link: medium.com/@AgentFitech

Groma — Mapas de Arquitetura C4

O Groma escaneia um repositório de código e cria um mapa de arquitetura C4 armazenado como Markdown OKF com links. Desenvolvedores e agentes de código curam responsabilidades dos componentes, relacionamentos e fluxos; a arquitetura pode ser explorada num mapa ao vivo no navegador ou no terminal.

Início rápido:

npm install --global groma.md
cd seu-repositorio
groma web

Profile e compatibilidade: O Groma usa um application profile OKF v0.2 para arquitetura C4. O bundle v0.6.2 passou na verificação de conformidade OKF com @mfdaves/okf-mcp@0.9.1. O Groma consome esse profile identificado e não afirma importar bundles OKF arbitrários. Uma verificação separada de política do projeto apontou 89 links para código fora do bundle e quatro links de navegação por diretório; isso não invalida a conformidade com o formato.

Stack: TypeScript e Bun · pacote npm · MIT · v0.6.5 (5 out 2026) · Node.js 20.19+. Suporta Linux e Windows em x64/ARM64 e macOS com Apple Silicon.

Link: github.com/MrLesk/groma.md · Contrato de Markdown de arquitetura

🟡 Maturidade: Early. O pacote funciona, o fluxo de release e os testes de instalação estão documentados, e há evidência independente de conformidade do bundle com OKF. O projeto ainda está no início e seu escopo de profile é especializado.

KL4A — Knowledge Layer For Agents

O KL4A transforma SOPs, políticas e documentos regulatórios em claims pequenas e ligadas à fonte. Seu diferencial é um gate de revisão humana: uma claim minerada continua como proposta até alguém aprovar, rejeitar, adiar ou editar, com revisor identificado, justificativa e valores antes/depois gravados no histórico de review em arquivos simples.

Aceita fontes Markdown, texto, PDF e DOCX; inventaria e calcula checksum, normaliza em seções, minera claims em forma de obrigação e exporta um bundle em formato OKF, além de JSON de grafo e RDF. Cada claim aponta para evidência com offsets no texto-fonte preservado. O app desktop, a CLI em Rust e o servidor MCP somente-leitura por padrão usam o mesmo bundle.

O exemplo de GLP-1 deixa a proposta concreta: ele rejeita uma extração que transforma uma exigência de documentação condicionada ao pagador em obrigação incondicional, preservando o span da fonte e a justificativa do revisor.

Stack: Rust (10 crates), app desktop em Tauri, CLI, servidor MCP e servidor HTTP. Apache-2.0. Versão atual: 0.0.1-alpha.

Link: github.com/CogniSwitch/KL4A

Limitações:

• Software pre-alpha; os builds desktop não têm assinatura de código.
• A exportação atual usa generated.actor/generated.date e verified.actor/verified.date, em vez de by/at do OKF v0.2; exemplos aprovados hoje escrevem data de verificação nula. Trate os metadados de trust como profile em rascunho até essa correção.
• O minerador offline perde sentenças quebradas entre linhas, o que deixa a extração de PDFs rala sem usar o minerador com LLM.
• Os offsets de evidência cobrem apenas texto, não regiões de imagem ou timestamps de vídeo.

🔴 Maturidade: Pre-alpha, mas cobre uma lacuna real. O pipeline e o bundle de exemplo demonstram evidência por claim e revisão humana persistida, mas o projeto é novo e a exportação dos campos de trust ainda não é interoperável com a convenção do OKF v0.2. Vale avaliar em fluxos de compliance ou políticas nos quais um revisor precisa validar a extração antes que um agente a use.

okf-postgres (Producer PostgreSQL)

Producer somente-leitura que transforma os catálogos de sistema do PostgreSQL num bundle OKF v0.2 com proveniência de geração explícita — database, schemas, tabelas (inclusive particionadas e foreign tables), views e materialized views, colunas, tipos enum, constraints, índices, comentários e relacionamentos de foreign key. Nunca lê linhas da aplicação e nunca grava credenciais no bundle.

Quick start:

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

# O comando recebe só o NOME da variável de ambiente com a 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

Saída: index.md, database.md, schemas/, tables/<schema>/, views/<schema>/, types/<schema>/ e um manifesto .okf-producer.json com o digest SHA-256 de cada arquivo gerado. Em novas execuções, só remove arquivos obsoletos cujo digest ainda bate com o manifesto; arquivos escritos à mão são preservados.

Metadata honesta: registra generated.by/generated.at, mas de propósito não declara verified. Quando o PostgreSQL não tem comentário, emite um fallback estrutural em vez de inventar significado de negócio.

Dois jeitos de rodar: CLI standalone, ou como producer hospedado pelo okf-mcp (producer preview / producer run), que valida o candidato antes de publicar.

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

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

Limitações:

• Fica em 0.1.x até o gate de compatibilidade com PostgreSQL ao vivo rodar em todas as versões suportadas (segundo o README)
• Só metadata: descreve estrutura, não significado de negócio — a não ser que seu banco já tenha comentários
• Novíssimo: um único release (v0.1.0) até agora

🟡 Maturidade: Early, mas com escopo bem fechado. Publicado no npm com provenance de build, CI contra PostgreSQL 14 e 18, e regras conservadoras de ownership de arquivos. Ainda é a primeira versão — teste no seu schema antes de colocar num pipeline agendado.

Korpus.cloud (Plataforma Hospedada)

Uma plataforma de conhecimento hospedada onde pessoas e seus agentes de IA trabalham no mesmo espaço, com rastreamento de revisões em cada escrita. O Korpus se descreve como agent-native e nascido em 2026, em vez de MCP acoplado a uma ferramenta antiga. Enviado pelo próprio fundador e listado aqui em out 2026; a documentação pública do suporte a OKF ainda está pendente, então trate a compatibilidade como não confirmada por enquanto.

O que oferece:

• Bundles — pastas de conceitos em markdown, privadas ou compartilhadas, com links tipados entre eles
• Colaboração multi-usuário — pessoas (owners, contributors, viewers) e agentes (Claude, ChatGPT, Cursor, CI jobs) trabalham no mesmo bundle
• Agentes por pessoa — cada agente trabalha para uma pessoa, com apenas os caminhos e permissões que essa pessoa concede
• Rastreamento de revisões — cada escrita é marcada com quem escreveu (ex: @mara via archivist ou @jonas in person) e nomeia a revisão que leu, prevenindo sobrescritas cegas
• Acesso via MCP, REST ou Web — conecta como seu workflow precisar
• Hospedado em Frankfurt (eu-central-1) — pra times que se importam com residência de dados

Casos de uso:

• Specs de landing zone multi-cloud
• Resposta a incidentes (do caos no Slack ao postmortem blameless)
• Evidências de auditoria de segurança que ficam atualizadas o ano todo

Preço: Free (até 5 bundles, 500 MB), Plus a €5/mês (até 50 bundles, 5 GB) e Enterprise implantado na sua própria conta AWS, sob consulta.

Link: korpus.cloud

🟡 Maturidade: Listagem inicial. O serviço hospedado está no ar, e os bundles de conceitos markdown tipados parecem próximos do OKF, mas import/export OKF ainda não está documentado publicamente. Confirme com o Korpus antes de depender dele pra bundles OKF.

Padrões & Profiles

Extensões formais e profiles construídos em cima do OKF.

W3C Holon CG (DataBook)

O W3C Holon Community Group (30+ participantes na reunião inaugural, 19 Jun 2026) está propondo DataBook como um profile formal do OKF para semantic web.

O que DataBook adiciona sobre OKF:

• Identidade baseada em IRI (URIs dereferenciáveis como IDs de conceito)
• Blocos tipados com RDF (Turtle, JSON-LD), SPARQL, SHACL
• Push para triplestore SPARQL via Graph Store Protocol
• Versionamento e proveniência de autor
• Validação SHACL como gate antes do deploy

Status: Fase de proposta, publicada em 23 Jun 2026; os autores disseram que abririam uma issue no repo OKF no GitHub.

Implicação: A comunidade Semantic Web vê OKF como base layer válida para estender — não como competidor. Valida a decisão de design extensível do OKF.

Link: The Ontologist — “The Format Convergence”

🟡 Maturidade: Proposta. Se aterrizar, OKF ganha tipagem ontológica formal de graça via profiles.

AIX — AI eXchange Format

Um superset estrito do OKF v0.2 que adiciona as capacidades que o OKF deliberadamente não inclui: identidade estável, relacionamentos tipados, identidade de mídia e federação. Todo bundle AIX também é um bundle OKF válido — publica uma vez, consumido por ambos.

O que AIX adiciona sobre OKF v0.2:

• Identidade estável (campo id) — a identidade do conceito sobrevive a renomeações e movimentações de arquivo; chega de referências quebradas quando você reorganiza seu vault
• Relacionamentos tipados (array links) — depends-on, supersedes, contradicts, describes, e mais, com inversas definidas; consumidores podem inferir backlinks automaticamente
• Identidade de mídia (array media) — identidade por hash de conteúdo para assets binários (diagramas, gravações, screenshots) mais ponteiros de embedding para retrieval multimodal
• Federação — namespaces de bundle, referências qualificadas cross-bundle (namespace/id), declarações de vocabulário compartilhado; bundles de múltiplos times interoperam sem precisar fazer merge de repos

Contrato de compatibilidade: AIX adota os campos de trust do OKF v0.2 (sources, generated, verified, status, stale_after) sem alteração. Dados específicos do AIX ficam em chaves de frontmatter que consumidores OKF preservam ou ignoram. Cada edge tipado em links também é espelhado por um link markdown plain no body, então leitores OKF-only ainda veem o grafo (sem tipo).

Escada de conformidade:

Validar qualquer 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), validador de referência (Python single-file, PyYAML opcional), bundle de exemplo funcional. Licença MIT.

Link: github.com/DavidROliverBA/ai-xf-format (spec, validador, exemplos; v0.2 lançada em 2026-08-20; renomeado AI-XF em 2026-09-27, última versão v0.4.2)

Limitações:

• Um produtor e um consumidor até agora — é uma hipótese publicada, não um padrão estabelecido
• O design de federação não foi testado até que um segundo time tenha seu próprio bundle
• O espelhamento de edges tipados custa alguma redundância por arquivo

🟡 Maturidade: Early. Spec + validador + bundle de exemplo são reais e versionados; ecossistema não. O racional de design foi publicado em dois ensaios: “I Was Going to Adopt Google’s Knowledge Format. I Wrote the Superset Instead.” e “OKF v0.2 Quietly Admits the Folder Has a Ceiling”. Vale acompanhar se você já bateu nas limitações de identidade ou relacionamentos do OKF.

Publicação & Visualização

Ferramentas que transformam bundles em sites ou grafos visuais.

Suganthan Web Converter

Cola uma URL ou sitemap, ele crawlea até 100 páginas, arranca o HTML decorativo, converte cada uma em conceito OKF com cross-links, e te entrega o bundle num zip. O grafo visual — pontos pras páginas, linhas pros links — já vale a pena rodar sozinho. Você enxerga páginas órfãs em segundos.

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

🟡 Maturidade: Funcional. Opera no nível de página (um arquivo por página). Extração real de conceitos — puxar ideias distintas de dentro da prosa — é o próximo passo que ninguém resolveu ainda.

Suganthan WordPress Plugin

Provavelmente o caminho mais rápido pra ter um bundle OKF ao vivo se seu site roda WordPress. Instala o plugin, ativa, e o conteúdo já tá servindo em /okf/. Sem etapa de export, sem cron, sem manter arquivos markdown na mão.

O plugin escuta eventos de publicação e edição. Toda vez que você clica “Atualizar” num post, o bundle reconstrói. No painel, aparece um grafo dos links internos — mesmo motor da ferramenta web acima, só que plugado direto no WordPress.

Na prática:

• Posts e páginas viram arquivos de conceito OKF (frontmatter + body em markdown limpo)
• Serve em seusite.com/okf/ com pretty permalinks, ou seusite.com/?okf=index.md sem
• Página de settings pra incluir/excluir por tipo de post
• GPL, gratuito, open source — só leitura (nunca mexe no seu conteúdo, remover não deixa rastro)

Precisa de: WordPress 6.0+, PHP 7.4+, pretty permalinks ligados (Configurações → Links Permanentes — qualquer opção exceto “Simples”).

Instalar:

1. Pega o zip: uploads.suganthan.com
2. Plugins → Adicionar Novo → Upload de Plugin → seleciona o zip → Instalar → Ativar
3. Pronto. Confere o menu OKF pro grafo. Já tá ao vivo em /okf/.

Também submetido ao Diretório de Plugins do WordPress — aguardando revisão.

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

🟢 Maturidade: Pronto. WordPress roda uns 40% da web. Pra essa fatia, é instalar e esquecer — o bundle fica atualizado sem você pensar nisso.

superops-team/okf CLI

CLI em Go que escaneia um repositório Git e gera um bundle OKF a partir do código-fonte — roda okf init e pronto, aparece um diretório .okf/knowledge/ com um conceito por arquivo relevante. Vem com updates incrementais via git hooks, linter embutido (13 regras), e engine de busca por tipo, tags ou texto livre.

O que chama atenção:

• okf init → escaneia o repo, gera o bundle
• okf hook -type post-commit → instala git hook que mantém o bundle atualizado a cada commit
• okf lint → valida contra a spec OKF (erros pra type/title ausentes, warnings pra estilo)
• okf search -q "database" → filtra por tipo, tags ou texto
• Updates incrementais — só regenera conceitos dos arquivos que mudaram desde o último commit

Instalar: one-liner (curl | bash), go install, ou binários pré-compilados (Linux, macOS, Windows — amd64/arm64).

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

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

Stack: Go, licença Apache 2.0. v0.4.0 lançada em 30 Ago 2026.

Link: github.com/superops-team/okf

🟢 Maturidade: Funcional, com release. Arquitetura limpa (pacotes separados pra parsing, linting, querying, git). A abordagem de git hook preenche um gap real — a maioria das outras ferramentas são geradores one-shot, essa mantém o bundle em sync conforme o código evolui. Comunidade pequena (29 stars), mas entregou com stress tests e binários cross-platform.

Validadores & Linters

Ferramentas que checam conformidade OKF.

okflint (Linter)

Lembra daquele gap na página que dizia “um plugin de validação seria legal, mas não trava nada”? O okflint é exatamente isso — só que como CLI, não plugin. Um linter determinístico (zero LLM) que valida bundles OKF contra a spec e contra as regras que você declarou no seu próprio manifesto.

A analogia mais honesta: é o Ruff da documentação. Roda, aponta, sai com exit code. Pronto.

Dois comandos, filosofias distintas:

• okflint audit — radiografia da base. Links quebrados, candidatos a split, estatísticas. Sempre exit 0 — é observação, não gate.
• okflint validate — portão de CI. Passou? exit 0. Não passou? exit 1. Ponto. Feito pra pre-commit hook e pipeline.

O pulo do gato é o sistema de três etapas:

A sacada é a camada do meio. OKF é deliberadamente mínimo (só exige type no frontmatter, basicamente). Mas na prática todo time quer mais: “todo ADR precisa ter campo created”, “status só pode ser draft/prod/obsoleto”. O okflint te deixa declarar isso num YAML (okf-base.yaml) e depois cobra. Nenhum vocabulário vem hardcoded — a engine é genérica.

Outro detalhe que importa pra quem usa Obsidian: ele resolve [[wikilinks]] contra a vault inteira, não só contra o bundle. Ou seja, um link pra uma nota fora do bundle não dispara falso positivo.

Instalar:

# Via uv (recomendado)
uv tool install okflint

# Ou pip, se preferir
pip install okflint

# Validar um bundle
okflint validate --manifest okf-base.yaml ./meu-bundle/

Na CI fica assim:

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

18 regras documentadas (com exemplo de erro e correção pra cada uma), saída JSON pra quem quer parsear no pipeline.

Stack: Python 3.12+, MIT. v0.4.1 saiu em 14 Set 2026.

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

Autor: mattdav

Como se encaixa com o superops-team/okf: são complementares, não concorrentes. O CLI Go gera bundles a partir de código-fonte e mantém em sync via git hook. O okflint não gera nada — só valida. Um produz, outro gateia. Faz sentido usar os dois juntos.

🟢 Maturidade: Com release. Escopo afiado — faz uma coisa e faz bem. O diferencial real é o sistema de profiles: você declara suas regras, ele cobra. Sem mágica, sem IA, sem opinião embutida.

okf-guard (Content Safety)

Uma camada de segurança de conteúdo que roda antes do seu gerador OKF. Enquanto o okflint valida estrutura de bundles, o okf-guard escaneia os arquivos fonte (PDF, DOCX, PPTX, XLSX, HTML) procurando texto oculto e padrões de prompt injection antes de virarem conhecimento confiável.

O problema que ele resolve: atacantes podem contrabandear instruções maliciosas em documentos usando texto branco-sobre-branco, caracteres zero-width, linhas ocultas em planilhas, ou shapes fora do canvas. Um humano revisando o documento não vê nada; um parser de LLM extrai tudo. O okf-guard pega isso antes do conteúdo entrar na sua base de conhecimento.

Três ações:

• pass — conteúdo limpo, sem problemas
• quarantine — sinais suspeitos, precisa revisão humana
• block — ataque detectado com alta confiança

Filosofia: Escanear antes de gravar. Conteúdo oculto + pattern matching (não só regex). Defaults conservadores — v0.1.0 é determinístico sem camada de julgamento LLM, então prefere falsos positivos a falsos negativos.

Quick start (CLI):

# Instala via pipx (recomendado para uso CLI)
pipx install "okf-guard[all]"

# Escaneia um arquivo
okfguard scan documento.docx

# Escaneia diretório recursivamente, output JSON para CI
okfguard scan -r /docs/uploads --json > scan_log.json

Quick start (API Python):

from okfguard import sanitize

result = sanitize("documento_suspeito.pdf")
print(f"Ação: {result.action}")        # "pass", "quarantine", ou "block"
print(f"Risk Score: {result.risk_score}")
print(f"Texto Limpo: {result.clean_text}")

# Campos de provenance OKF v0.2 prontos pro seu bundle
print(result.provenance_fields)

Exit codes: 0 pass, 1 quarantine, 2 block, 3 erro — pronto pra gates de CI.

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

Link: github.com/darshanNhb/okf-guard

Limitações:

• Sem OCR ou análise de imagens (esteganografia, texto em imagens)
• Sem análise de macros/VBA — só conteúdo
• Detecção de render mode 3 em PDF é parcial (libs subjacentes não expõem de forma confiável)
• Não move/deleta arquivos — retorna decisão, sua pipeline que aplica

Como se encaixa com o okflint: Sequencial, não concorrente. okf-guard escaneia documentos fonte antes da conversão; okflint valida bundles OKF depois da geração. Pipeline: fontes → okf-guard → gerador → okflint → deploy.

🟡 Maturidade: Early. v0.1.0, um único mantenedor, poucas stars. Mas a implementação é sólida: estrutura de pacote apropriada, testes, CI, documentação honesta das limitações. Preenche uma lacuna real — ninguém mais está fazendo segurança de conteúdo pré-geração para pipelines OKF.

OKPH (OKF + Graph)

CLI e biblioteca que constrói grafos de dependência Mermaid sobre bundles OKF, roda análise de impacto baseada em Git, e valida bundles contra a spec. Pense nisso como git diff para sua base de conhecimento — mas em vez de mostrar mudanças de linha, mostra quais documentos são afetados pelo que mudou.

O que chama atenção:

• okph graph ./docs → gera grafo de dependências Mermaid com links clicáveis
• okph affected --git main → mostra arquivos alterados + dependentes transitivos (ótimo pra PR reviews)
• okph validate ./docs → valida bundle contra spec OKF (erros pra MUSTs, warnings pra SHOULDs)
• okph deps/dependents → rastreia o que um arquivo linka ou o que linka pra ele
• Respeita arquivos reservados (index.md, log.md) conforme spec §3.1
• Sem chamadas de rede, sem telemetria — 100% offline
• API de biblioteca disponível pra uso programático

Exemplo — “o que pode precisar de review depois dessa branch”:

# Ver o que mudou
$ git diff --name-status main -- docs/
A       docs/new-policy.md
M       docs/orders.md
D       docs/legacy.md

# Gerar grafo de afetados (pulando arquivos reservados)
$ okph affected --git main --root docs --graph --exclude '**/{index,log}.md' \
    --base-url https://github.com/octocat/okf-docs/blob/main/docs

Arquivos alterados são coloridos por status: verde = adicionado, âmbar = modificado, vermelho = deletado. Os nós linkam direto pros arquivos no GitHub.

Instalar:

npm install -g @fcmam5/okph
# Ou usar npx
npx @fcmam5/okph graph ./docs

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

Links: github.com/Fcmam5/okph · npm

Como se encaixa com outros validadores: okflint foca em conformidade com a spec (regras MUST/SHOULD) e enforcement de profile. okf-guard escaneia documentos fonte procurando conteúdo oculto. OKPH adiciona a dimensão de impacto de mudança — não só diz se seu bundle é válido, mas quais documentos são afetados quando você muda algo. Especialmente útil em pipelines de CI onde você quer saber o blast radius de um PR.

🟡 Maturidade: Funcional. CLI bem documentada com API clara. Suporta validação da spec OKF v0.2 e geração de grafos. Ferramenta nova em fase inicial de adoção, mas o conjunto de features pra workflows de análise de impacto é sólido.

OKF-Schema (Validação com JSON Schema)

Traz validação JSON Schema para bundles OKF. Em vez de só checar “esse arquivo tem um campo type?”, o okf-schema valida a estrutura do seu frontmatter contra schemas que você define por tipo. Pense nisso como type-checking para sua base de conhecimento.

A ideia central: Para cada type no seu bundle, existe um arquivo de schema correspondente em _schema/. Os schemas podem ser escritos em YAML, JSON ou JSON5 (JSON com comentários e vírgulas finais). O schema define campos obrigatórios, valores permitidos e documentação para cada propriedade. Quando você roda okf-schema validate, ele verifica cada arquivo de conceito contra o schema do seu tipo e dá feedback acionável.

O que o projeto oferece:

O pulo do gato: Os schemas são commitados dentro do bundle (pasta _schema/), então viajam junto com seu conhecimento. Sem registry externo, sem mismatch de versão. Clona o bundle, roda o validador, pronto.

Quick start:

# Instalar a CLI em um ambiente isolado (recomendado)
uv tool install okf-schema

# Validar um bundle
okf-schema validate --path ./meu-bundle/

# Ou usar o workflow okfkb
okfkb init ./nova-kb
okfkb validate ./nova-kb

Exemplo de schema (em _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 (2 Set 2026) · PyPI

Links: github.com/gsemet/okf-schema · Documentação · Exemplos

Comparação com okflint: Filosofias diferentes. okflint valida contra um conjunto fixo de regras (spec OKF + seu profile YAML). okf-schema valida contra JSON Schemas que você define por tipo — mais configurável, mais explícito e intencionalmente mais estrito. Um bundle OKF válido pode falhar se não corresponder aos schemas commitados junto dele. okflint é “isso segue as convenções OKF?”; okf-schema é “isso bate exatamente com o shape que eu declarei?”. Ambos podem rodar na CI.

Limitações:

• Não há inferência de schema embutida. Na prática, um LLM pode derivar um schema inicial a partir de alguns conceitos representativos
• Os workflows okfkb e okfreq são opinados — úteis se batem com seu caso de uso, overhead se não

🟢 Maturidade: Pronto pra produção. Publicado no PyPI (22 stars no GitHub), documentado no ReadTheDocs, exemplos reais no repo. A biblioteca é estável o suficiente para validação em produção. As camadas okfkb/okfreq são mais experimentais — demonstrações interessantes do que OKF pode suportar, mas não obrigatórias para usar a validação core.

Autor: gsemet

okf-mcp (Validador + Servidor MCP)

Consumer, validador, índice de grafo, CLI e servidor MCP stdio para bundles OKF v0.2 — tudo local-first. O diferencial está na escrita: producers configurados leem um sistema externo e devolvem um bundle candidato; o okf-mcp valida e publica sob um manifesto de ownership que registra exatamente quais arquivos são dele. Conteúdo escrito à mão nunca é adotado, e uma fonte que não mudou não reescreve nada.

O que oferece:

• Validação OKF v0.2, com compatibilidade v0.1 (fallbacks de timestamp e # Citations) e checagens de migração só para revisão
• Busca e navegação no grafo — busca BM25+ em memória (MiniSearch), vizinhos, caminhos, rastreio de proveniência, trust tiers e checagem de frescor
• Servidor MCP stdio com tools de validação, busca, grafo e proveniência; autoria baseada em propostas com aceite explícito (mcp --authoring)
• Host de producers — producer list|preview|run; o okf-postgres é o primeiro producer
• Attested Computation: contratos são inspecionados estaticamente — nada é executado, nada é atestado

Zero infraestrutura: sem banco, sem embeddings, sem build step, sem serviço hospedado. O modo --root não faz chamadas de rede; o carregamento remoto opcional só busca Markdown público no GitHub.

Quick start:

# Validar um bundle (Node.js 22+)
npx -y @mfdaves/okf-mcp@0.9.1 --root ./meu-bundle validate

# Ou instalar global (vem com os binários `okf` e `okf-mcp`)
npm install --global @mfdaves/okf-mcp@0.9.1
okf --root ./meu-bundle search "pedidos"
okf-mcp --root ./meu-bundle mcp

Config MCP:

{
  "mcpServers": {
    "okf": {
      "command": "npx",
      "args": ["-y", "@mfdaves/okf-mcp@0.9.1", "--root", "/caminho/absoluto/para/okf", "mcp"]
    }
  }
}

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

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

Atenção ao nome: existe outro projeto, travisjakel/okf-mcp (okf-mcp no PyPI, v0.5.1), que expõe os verbos de consumo do okf-ingest como tools MCP. Esta seção trata do pacote npm @mfdaves/okf-mcp.

Como se encaixa com outros validadores: okflint e OKF-Schema são portões de CI; OKPH mede impacto de mudança. O okf-mcp é o que também serve o bundle para agentes via MCP e escreve conteúdo gerado nele com segurança.

Limitações:

• Pré-1.0 e andando rápido (0.3.2 em Jul → 0.9.1 em Set 2026); flags e APIs ainda mudam
• Comunidade pequena (7 stars no GitHub)
• Workspaces (okf.project.yaml), locators okf:// e relations tipadas são extensões do okf-mcp, não fazem parte do OKF v0.2
• O pacote instala um binário chamado okf — mesmo nome usado pelo superops-team/okf e pelo OKF Agent Memory

🟢 Maturidade: Released, andando rápido. Publicado no npm com provenance de build e listado no MCP Registry oficial. Documentação incomumente clara sobre o que é OKF v0.2 e o que é extensão do okf-mcp. Ainda pré-1.0, então fixe a versão (@0.9.1) em configs de produção.

Kiso (Publishing)

Kiso é um engine de publicação que pega seu bundle OKF e cospe um site estático pronto — com llms.txt e sitemap.xml gerados automaticamente. Ou seja: um comando e você tem um site legível por humanos e por agentes de IA ao mesmo tempo.

O que chama atenção: a CLI é enxuta de verdade — só dois comandos. check valida a estrutura do seu markdown antes de qualquer coisa, build gera o site. Tem GitHub Action pronta, suporte a temas DaisyUI, e um sistema de publishing profiles (.kiso/<perfil>/configuration.yaml) que deixa você manter configs diferentes pro mesmo bundle.

Quick start:

# Valida a estrutura do bundle
./kiso-cli check --source=meu-bundle

# Gera o site estático
./kiso-cli build --source=meu-bundle --destination=public

GitHub Action:

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

Configuração (.kiso/configuration.yaml):

site:
  baseUrl: https://knowledge.example.com/
  language: pt
  title: Minha Base de Conhecimento
  description: Documentação para humanos e agentes de IA

theme:
  name: corporate

content:
  ignorePatterns:
    - drafts/**
    - interno/**

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

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

🟢 Maturidade: Com release. Funciona, tem CI action, tem releases tagueadas — não é vaporware. Dito isso, é projeto jovem (47 stars, ainda pré-1.0). A proposta é sólida e a execução tá limpa, mas espere mudanças de API entre minors. Bom pra quem quer publicar bundles OKF sem inventar pipeline do zero.

OpenWiki 0.2 (LangChain)

O OpenWiki lê seu repositório e gera um wiki estruturado no formato OKF — pronto pra ser consumido por coding agents como Claude Code e Cursor. A ideia é simples: seu código já tem conhecimento implícito (decisões de arquitetura, padrões, convenções), e o OpenWiki transforma isso num artefato explícito que agentes conseguem ler sem ficar adivinhando.

Harrison Chase confirmou a direção no X: “there needs to be an OPEN standard for memory. OKF is one such standard.” O CLI conecta o wiki gerado nos instruction files do seu agent, então o contexto flui sem fricção entre o codebase e quem opera nele.

Quick start:

# Node.js 22.22+ (o pacote "openwiki" no PyPI é outro projeto, sem relação)
npm install -g openwiki

# Conecte seu coding agent (codex, claude, cursor, opencode, ...)
openwiki integrations install claude

# Depois peça ao agente: "Initialize this repository's OpenWiki from the current source and tests."
# Ou rode standalone com seu próprio provedor de modelo:
openwiki code --init

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

Link: langchain-ai/openwiki · Blog post

🟢 Maturidade: Produção. Backed pela LangChain (16.9K stars, 1.2K forks), mantido ativamente, documentação sólida. Já na segunda major release com suporte OKF nativo.

Bibliotecas & SDKs

Implementações nativas para embutir OKF nas suas próprias ferramentas.

W4G1/okf (Rust)

A implementação nativa mais completa do OKF fora das ferramentas de referência do Google. Um toolkit puro Rust cobrindo toda a spec OKF v0.2: parsing, validação, linting, trust tiers, e uma TUI interativa para explorar bundles.

O que você ganha:

Comandos CLI:

• okf init — scaffold de um novo bundle
• okf new — cria um novo arquivo de conceito
• okf validate — checa conformidade contra OKF v0.2
• okf lint — checagens de estilo e higiene
• okf trust — gerencia trust tiers
• okf graph — visualiza o grafo de links
• okf mv, okf rm — refatora sem quebrar links
• okf split, okf merge — operações de bundle
• okf diff, okf fmt — comparação e formatação
• okf studio — lança o explorador TUI

Instalar:

# Do crates.io
cargo install okf

# Ou como plugin do Cargo (`cargo okf <comando>`)
cargo install cargo-okf

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

Link: github.com/W4G1/okf

Limitações:

• Pré-1.0: os crates okf, okf-core e cargo-okf ainda estão em 0.2.x
• A TUI é funcional mas minimal
• Sem MCP server (ainda)

🟢 Maturidade: Com release. 27 stars, 72 commits, desenvolvimento ativo. A única implementação Rust com cobertura total do v0.2. Se você está construindo tooling Rust que precisa ler/escrever OKF, é isso. O CLI sozinho vale experimentar — okf studio torna exploração de bundles genuinamente agradável.

Roteiro (Knowledge Graph — Producer + Consumer + Validator)

Um knowledge graph com proveniência de codebases que escreve E lê bundles OKF, com conformance checker e viewer para bundles que ele não produziu. É a implementação OKF mais completa fora das ferramentas de referência — cobrindo as três categorias: gerador, consumidor e validador.

O que faz com OKF:

• Escreve bundles a partir do grafo (roteiro render okf) — index.md por diretório, conceitos tipados, links markdown entre eles
• Lê bundles de terceiros (roteiro import --from okf) e importa como conhecimento externo, registrando o trust tier da origem sem herdá-lo
• Valida conformidade (roteiro okf validate — gate com erro) e higiene (roteiro okf lint — só reporta), além de info, trust, links, syntax, computations e diff
• Filtra conteúdo importado antes de virar conhecimento — três verdicts, com bloco reservado para diretiva de modelo que também é ocultada
• Visualiza bundles externos, resolvendo links via mapa key-to-path construído após posicionamento

Comandos principais:

# Instalar via crates.io
cargo install roteiro

# Gerar bundle OKF do codebase
roteiro index .
roteiro render okf --output ./knowledge-bundle/

# Importar bundle externo como conhecimento
roteiro import --from okf /caminho/para/bundle-externo

# Validar conformidade OKF
roteiro okf validate ./meu-bundle/   # gate — falha com erro
roteiro okf lint ./meu-bundle/       # só reporta

Stack: Rust · MIT/Apache-2.0 · v6.1.0 (29 Set 2026) · Biblioteca separada rto-okf-syntax para parsing de fenced code blocks

Versão OKF: v0.2, pinned no commit ad30107c — os fixtures de interoperabilidade vendem dois bundles do próprio repo da spec nesse commit exato

Dependência: Usa okf-core (W4G1/okf) como parser subjacente

Link: github.com/OffeneDatenmodellierung/Roteiro

Limitações declaradas:

• Entries de sources carregam apenas resource — não popula id, title ou author
• Não emite footnotes nem log.md
• O reader atualmente descarta title e author do peer ao importar
• Dois lints de higiene (L5 e L6) não disparam contra output próprio por causa das limitações acima

🟢 Maturidade: Ferramenta de produção. 2.000+ commits, codebase maduro, publicado no crates.io. A única ferramenta que cobre producer + consumer + validator em um pacote só. Se você quer um knowledge graph que fala OKF fluentemente — lendo, escrevendo e validando — é a opção mais completa.

OKF-Runtime (Consumer + Library)

Engine de consumo leve e determinística para bundles OKF. Enquanto a maioria das ferramentas OKF foca em autoria, validação ou enrichment, o OKF-Runtime foca em consumo eficiente: descobrir bundles, parsear metadata, indexar e montar grafos de links — tudo sem banco de dados, daemon ou serviços externos.

O que faz:

• Scanner de filesystem — descobre bundles OKF automaticamente
• Parser Markdown/YAML — extrai metadata do frontmatter
• Índices em cache — metadata, tags e tipos, tudo indexável
• Grafo de links — links diretos e reversos entre conceitos
• Composição — cria bundles temporários por tópico sem alterar os arquivos fonte
• Validação — checa links, âncoras e estrutura do grafo
• Trust & proveniência — deriva trust tiers e staleness do frontmatter v0.2 (sources, generated, verified, status, stale_after)

Princípios de design:

• Determinístico antes de IA — resolve tarefas de recuperação sem gastar contexto de LLM
• Library first — a lógica do runtime fica em módulos reutilizáveis, não só em wrappers de CLI
• Filesystem é a fonte da verdade — os arquivos markdown continuam sendo a referência
• Zero infraestrutura — sem servidor de banco, sem daemon em background, sem serviço na nuvem
• Melhoria progressiva — features se empilham do filesystem à CLI e a integrações opcionais com agentes

Comandos da CLI:

• discovery — encontra bundles OKF numa árvore de diretórios
• catalog — lista conceitos com metadata
• query — busca por tipo, tags ou texto
• graph — visualiza links diretos/reversos
• compose — cria bundles temporários por tópico
• lint — valida a estrutura do bundle

Estrutura do repositório:

okf_runtime/    ← biblioteca de runtime e CLI
scripts/        ← entry point fino voltado a agentes
references/     ← material de uso e especificação para agentes
docs/           ← arquitetura, decisões, guia de contribuição
tests/          ← testes do runtime e fixtures

Stack: Python · MIT · Agent Skill conforme SKILL.md · ainda sem releases tagueadas (último push 19 Set 2026)

Versão OKF: v0.1 e v0.2 suportadas

Link: github.com/spomytkin/OKF-Runtime

Comparação com outras ferramentas: Roteiro e W4G1/okf são ferramentas producer + validator (geram e checam bundles). O OKF-Runtime é consumer puro — lê bundles de forma eficiente sem modificá-los. Use o OKF-Runtime quando estiver construindo tooling que precisa percorrer e consultar bundles existentes de forma determinística, sem subir um LLM.

Limitações:

• Só Python (outros runtimes no roadmap)
• Ainda sem servidor MCP (existe um entry point para agentes em scripts/)
• Implementação na Fase 1.5 — algumas features avançadas ainda estão no roadmap

🟡 Maturidade: Funcional. Arquitetura limpa, com separação entre a biblioteca de runtime e a CLI. A abordagem determinística preenche uma lacuna real — a maioria das outras ferramentas ou exige chamadas de LLM ou foca em geração em vez de consumo. Vale avaliar se você está construindo tooling de agentes que precisa ler bundles OKF em escala sem queimar tokens.

Confiança & Proveniência

Verificação, assinaturas e proof on-chain pra bundles.

signed-okf (Trust Layer)

O OKF resolve estrutura. Mas quem garante que aquele bundle não foi adulterado? O signed-okf adiciona proveniência criptográfica: assinatura, verificação e cadeia de custódia pro conteúdo OKF. O metadata padrão do OKF para num timestamp estático — o signed-okf preenche exatamente esse gap que o próprio Google reconheceu na spec v0.1.

Feito pela Dynamic Feed: cada arquivo do bundle é hasheado, os hashes e um envelope de proveniência vão para um manifesto (okf.manifest.json), e o manifesto é assinado com Ed25519. Qualquer um re-verifica com a chave pública do emissor. Se você opera em contextos onde proveniência auditável importa (pesquisa, compliance, supply chain de dados), é exatamente essa camada.

Quick start:

# Não está no PyPI/npm: clone o repo e rode os scripts (precisa de `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 · sem releases tagueadas (publicado em 23 Jun 2026)

Link: Fluxdyne/signed-okf · dynamicfeed.ai

🟡 Maturidade: Early adopter. Conceito forte, execução ainda jovem. Poucas stars, time pequeno. São dois scripts Python mais uma SPEC.md — sem pacote publicado e sem commits desde 23 Jun 2026. Se você precisa de trust layer pro OKF hoje, é a única opção — mas vá sabendo que a API pode mudar.

Memória & Skills de Agentes

OKF como memória ou instrução runtime pra agentes IA.

hermes-okf (Memória)

Cada decisão que seu agente toma, cada observação sobre o projeto, cada pedaço de contexto — tudo vive num knowledge graph no filesystem, legível por humanos e por máquinas. O hermes-okf é o sistema de memória do Hermes Agent, mas formatado como OKF. Memória versionada, estruturada, que sobrevive entre sessões.

O diferencial: não é só um dump de contexto. Tem tool registry (o agente sabe quais ferramentas tem), plans (sequências de ação persistidas) e integração nativa com o HermesAgent. Se você já usa Hermes, plugar o OKF como backend de memória leva minutos.

Quick start:

pip install hermes-okf

# Registra o plugin no Hermes e valida o setup
hermes-okf install-plugin
hermes-okf validate-config

# Escolhe o hermes-okf como provedor de memória
hermes memory setup

# Depois, dentro do Hermes
hermes okf search "dark mode"

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

Link: EliaszDev/hermes-okf · PyPI

🟡 Maturidade: Funcional, mas nicho. Publicado no PyPI, versionado. Comunidade pequena (35 stars) e sem commits desde 25 Jun 2026. Se você não usa o Hermes Agent, o valor cai bastante — a lib foi construída pra aquele ecossistema específico. Documentação ok, mas com gaps nos edge cases.

OKF Agent Memory

Memória persistente e Git-native para agentes de código, construída sobre OKF v0.2 em Go puro, sem dependências externas. Não tem relação com o hermes-okf: é um binário okf standalone (CLI + servidor MCP embutido) que funciona com Claude Code, Cursor, Codex e qualquer outro cliente MCP.

A ideia, que o projeto chama de Dual-Memory Agent Architecture (DMAA): o AGENTS.md vira uma camada normativa mínima, de “push” (~100–150 tokens de regras e gatilhos, escritos numa micro-sintaxe chamada Agent Action Grammar), e todo o resto vai para um bundle OKF em knowledge/ que o agente “puxa” sob demanda via busca. O bundle custa zero tokens até ser consultado, e a memória inteira é Markdown puro que você revisa com git diff.

O que oferece:

• Busca BM25 em memória no bundle (okf search), mais --for-path para achar decisões e restrições ligadas a um arquivo de código via code_refs antes de editá-lo
• Validação com checagem de conectividade do grafo e de drift das descrições (okf validate --strict --drift)
• Autoria com bookkeeping — okf create / okf update mantêm index.md e log.md automaticamente
• okf bootstrap — cria knowledge/, uma agent skill, AGENTS.md e um Makefile em qualquer repo
• Servidor MCP stdio (okf mcp knowledge)
• v0.5.0 (1 Out 2026): cliente do OKF Registry (registry.okf-memory.dev), okf pull / okf restore / okf vendor com lockfile okf.lock (checksums SHA-256) e memória em quatro escopos — project › vendor › user (~/.okf/) › system (/etc/okf/), em que camadas superiores sobrepõem conceitos com o mesmo ID

Quick start:

# Homebrew (macOS/Linux) — ou baixe um binário pronto nos GitHub Releases
brew install okf-memory/tap/okf

okf bootstrap /caminho/do/projeto --name "Meu Projeto"
okf search "camadas de arquitetura" knowledge
okf validate knowledge --strict --drift

Config MCP:

{
  "mcpServers": {
    "okf-memory": {
      "command": "/caminho/para/okf",
      "args": ["mcp", "/caminho/do/projeto/knowledge"]
    }
  }
}

Stack: Go (zero dependências) · MIT · v0.5.0 (1 Out 2026) · binários para macOS, Linux e Windows

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

Comparação com o hermes-okf: os dois usam bundles OKF como memória de agente, mas o hermes-okf é uma biblioteca Python amarrada ao Hermes Agent; o OKF Agent Memory é agnóstico de agente — um binário único com servidor MCP e uma convenção de AGENTS.md por cima.

Limitações:

• Muito novo e andando rápido: primeiro release em 5 Set 2026 e 16 releases no GitHub até a v0.5.0 (1 Out) — espere breaking changes
• Os números de performance e economia de tokens (busca abaixo de 300 µs, ~80% menos tokens) vêm dos benchmarks do próprio projeto — reproduza com make benchmark antes de citar
• Adiciona convenções próprias por cima do OKF (DMAA, AAG, prefixos de escopo como @bundle/, user: e system:) que outras ferramentas OKF não entendem
• O binário se chama okf, mesmo nome do superops-team/okf (e de um dos binários do okf-mcp) — confira o PATH se usar mais de um

🟡 Maturidade: Crescendo rápido, ainda pré-1.0. Mais de 740 stars no GitHub no primeiro mês, CI, testes, tap Homebrew e binários multiplataforma. O registry e o lockfile da v0.5.0 acabaram de sair — vale testar, mas fixe versões enquanto as interfaces estabilizam.

Inkeep Open Knowledge

Um editor markdown AI-native e local-first que virou plataforma completa de knowledge base na launch week de 17–21 ago 2026: apps desktop pra macOS, Windows e Linux, sync via git, busca agêntica (embeddings + RAG hierárquico) e chat nativo com 30+ coding agents via ACP. Editor rico estilo Notion que continua sendo markdown puro no disco.

Pra agentes, três superfícies importam:

• MCP server nativo (@inkeep/open-knowledge) — tools de leitura/escrita (ingest, research, consolidate) mais avisos em tempo de escrita quando o conteúdo sai da conformância
• Agent skills embutidas — incluindo a okf-knowledge-base com semântica OKF (ver plugin abaixo)
• Padrão .mcp.json commitado — bundles como o wiki Odyssey trazem config a nível de repo, então Claude Code/Codex oferecem subir o server ao abrir

Quick start:

# Baixar o app desktop (Mac/Win/Linux)
# https://openknowledge.ai/download

# Ou rodar o MCP server headless
npx -y @inkeep/open-knowledge@^0.58 mcp

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

Links: openknowledge.ai · inkeep/open-knowledge

🟢 Maturidade: Lançado. De preview web a app desktop multiplataforma em cinco semanas. O plugin OKF abaixo é o que faz dele um editor OKF-native, não só mais um app markdown.

OKF Plugin (OpenKnowledge)

Anunciado em 21 ago 2026 como “parte linter, parte skill, parte MCP tools”. Traduz o OKF v0.2 em feedback contínuo de conformância dentro do editor, CLI e agentes do OpenKnowledge. Tudo que ele aponta é warning — nunca bloqueia escrita.

Seis rulesets de frontmatter (schemas gerados em .ok/okf/*.schema.json):

• Required — type não vazio em todo concept
• Recommended — title, description, tags (lista), resource
• Provenance/lifecycle — sources[], generated {by, at}, verified[], status, stale_after
• Computation — formato do type: Attested Computation (runtime, parameters, executor.receipt, attester)
• Index files ×2 — sem frontmatter, exceto okf_version: "0.2" na raiz

Mais regras de body/portabilidade: formato de lista do index, headings de log em ISO-8601, sem wikilinks, sem .mdx.

Três formas de rodar:

Também gera index.md automáticos por diretório (agrupados por tipo), machine-owned e à prova de merge conflict via regra no .gitattributes. Vem com a skill okf-knowledge-base pra agentes conhecerem spec e ferramenta.

Comparação com okflint: mesma filosofia — lint determinístico, warnings sem bloqueio. Entrega diferente: okflint é CLI Python standalone feito pra CI; esse vive onde os agentes escrevem. Podem rodar juntos.

Links: Anúncio · Docs

🟢 Maturidade: Lançado. Cobertura day-one do OKF v0.2, incluindo Attested Computation.

knowledge-template (Ciência)

Template vazio e conformante de bundle OKF voltado pra ciência aberta. Você clona, preenche com seu conteúdo, e sai com um bundle que atende a spec OKF v0.2 e os requisitos da camada de conhecimento do Open Science Pillars (docs/SPECIFICATION.md no repo open-science-pillars/marketplace). Inclui quatro conceitos de exemplo anotados — um dataset, uma gotcha, uma recipe e uma convention — pra você entender o que vai onde.

Não é framework, não é CLI, não tem dependência. É um template. Faz uma coisa só e faz bem.

Quick start:

# Copie o repositório (ele não está marcado como template no GitHub)
git clone https://github.com/open-science-pillars/knowledge-template.git my-knowledge
cd my-knowledge
# Renomeie em .osp/repository.yaml, apague os quatro conceitos example-*
# e rode o checker OKF v0.2 descrito no README

Stack: Markdown/YAML · Apache-2.0 · sem releases tagueadas (último push 20 Set 2026)

Link: open-science-pillars/knowledge-template

🟢 Maturidade: Completo pro que se propõe. É template — não tem bug, não tem runtime, não quebra. Conformante com OKF v0.2, exemplos claros. Se você trabalha com conhecimento científico e quer OKF, começa aqui.

OriginTrail DKG + OKF

Junta o Open Knowledge Format com o Decentralized Knowledge Graph da OriginTrail. Na prática: seus bundles OKF ganham um dono verificável, prova de origem e imutabilidade registrada em blockchain. A importação é determinística (sem LLM no caminho) e gera Knowledge Assets com proveniência criptográfica (Merkle root + atestação EIP-712).

O ponto forte aqui é confiança. Um agente IA consulta o DKG, encontra um bundle OKF e consegue verificar criptograficamente quem publicou, quando, e se o conteúdo foi alterado. Sem trust-me-bro. Sem depender de um servidor central dizendo “esse dado é legítimo”. O grafo descentralizado faz isso sozinho.

Quick start:

# Requer um node DKG rodando (github.com/OriginTrail/dkg)
dkg okf import ./bundle --context-graph-id meu-grafo --create-context-graph

Stack: TypeScript · Apache-2.0 · vem no node DKG da OriginTrail (packages/okf; node v10.0.19, 28 Set 2026)

Link: Google’s OKF comes to the OriginTrail DKG · Docs do DKG: import/export OKF

🟡 Maturidade: Conceito validado, adoção ainda inicial. Anunciada em 1 Jul 2026; o importador vem no node DKG e no pacote npm @origintrail-official/dkg-okf (última versão 10.0.20, 29 Set 2026), e a documentação está dividida entre o blog post e o repo do DKG. Promissor pra quem precisa de proveniência verificável, mas prepare-se pra montar o quebra-cabeça sozinho por enquanto.

openknowledgeformat.com

Site comunitário que resolve o problema mais básico: “meu bundle OKF tá certo?”. Cola seu YAML frontmatter, recebe validação instantânea. Sem instalar nada. Sem CLI. Sem dependência.

Além do validator, tem templates prontos pra copiar e exemplos interativos que mostram bundles reais em ação. Perfeito pra quem tá começando e quer entender a estrutura sem ler a spec inteira. Também funciona como referência rápida quando você esquece um campo obrigatório (acontece).

Quick start:

# Não precisa de terminal. Abra no browser:
# https://openknowledgeformat.com/
# Cole seu YAML → veja erros em tempo real
# Copie templates → adapte pro seu caso

Stack: Web · Gratuito · Publicado Jun 13, 2026

Link: openknowledgeformat.com

🟢 Maturidade: Pronto pra uso. Funciona, é direto, faz o que promete. Zero fricção. Limitação óbvia: só valida — não gera, não publica, não integra com pipelines. Mas pro que se propõe, resolve.

okf-skill (Agent Skill)

Um arquivo markdown. Só isso. Mas esse arquivo transforma qualquer agente com suporte a Agent Skills (Claude Code, Cursor, Hermes, etc.) num produtor e consumidor de bundles OKF. Referencia a spec completa e dá instruções claras pro agente seguir.

Preenche um gap real: coding agents sabem escrever código, mas não sabem estruturar conhecimento no formato OKF sem orientação explícita. Esse skill é essa orientação. Joga no diretório de skills do seu agente e pronto — ele passa a gerar bundles conformantes.

Quick start:

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

# Ou manual: copie a pasta skills/okf-skill do repo
mkdir -p .claude/skills && cp -r skills/okf-skill .claude/skills/okf-skill

Stack: Markdown + scripts Python stdlib (Agent Skill) · Apache-2.0 · sem releases tagueadas · embute a spec OKF v0.1

Link: github.com/rakibtg/okf-skill

🟡 Maturidade: Funcional, mas depende do agente host. A qualidade da saída varia conforme o modelo e o agente que consome o skill. Não tem testes automatizados — você confia que o agente vai seguir as instruções. Repo pequeno, sem muita atividade ainda, mas a ideia é sólida.

leadcraft

Plugin do Claude Code que ajuda tech leads a escrever e refinar entregáveis estruturados (planos, estimativas, decisões de arquitetura, design docs) e guarda tudo como Knowledge Bundle conformante com OKF v0.1. A saída é YAML frontmatter + directory tree em markdown — legível tanto por humanos quanto por agentes, e versionável com git como qualquer outro arquivo do projeto.

A proposta é simples: um modelo de planejamento em cinco níveis (Objective / Initiative / Epic / Story / Task), com as stories em markdown local por padrão (GitHub Issues + Projects é opcional). Útil quando outros agentes vão consumir seus planos e decisões depois.

Quick start:

# Dentro do Claude Code
/plugin marketplace add dskst/leadcraft
/plugin install leadcraft

Stack: Plugin do Claude Code (skills em Markdown) · MIT · OKF v0.1 · sem releases tagueadas (24 Jun 2026)

Link: github.com/dskst/leadcraft

🟡 Maturidade: Early stage, documentação limitada. Repo recente com pouca documentação além do básico. Funciona pro caso de uso principal (gerar bundles de planejamento), mas não espere configuração avançada ou edge cases cobertos. Contribuições bem-vindas — o código tá lá, é aberto.

pi-openwiki (Pi coding agent)

O agente OpenWiki da LangChain adaptado como extensão do Pi coding agent. Gera e mantém documentação de codebase automaticamente, com o mesmo formato de saída OKF que o OpenWiki original produz.

A diferença é o runtime: ao invés de rodar standalone, roda como extensão dentro do Pi. Se você já usa o Pi, é uma forma natural de adicionar geração de docs OKF ao fluxo.

Quick start:

# Instale a extensão pelo Pi e rode os comandos dentro do Pi
pi install npm:pi-openwiki
/openwiki:init
/openwiki:update

Stack: TypeScript (extensão Pi) · MIT · v1.0.0 no npm (7 Jul 2026)

Link: github.com/barvhaim/pi-openwiki

🟡 Maturidade: Funcional, mas nicho. Publicado em Jul 2026, sem pushes desde 7 Jul 2026. Depende do Pi — se você não tá nesse ecossistema, o OpenWiki original faz mais sentido (e hoje ele mesmo integra com o Pi). Documentação básica, poucos contributors. Mas se o Pi é seu mundo, essa é a porta de entrada pro OKF.

8. Padrões Emergentes (Ainda Não São Ferramentas)

OKF + llms.txt para Discovery

Vários analistas especulam que llms.txt vai apontar agentes para bundles OKF:

# llms.txt
...
## Knowledge
- /knowledge/index.md: OKF bundle — conhecimento organizacional para agentes

Status: Especulação lógica, não confirmada oficialmente.

Marketplace de Bundles OKF

Marie Haynes argumenta que bundles OKF serão produtos vendáveis — advogados, contadores, SEOs empacotando expertise como bundles compráveis.

Status: Pura especulação. Interessante mas sem infraestrutura.

OKF + Obsidian como IDE

Framing do Karpathy: “Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.” Vários times já usam Obsidian pra autorar bundles OKF enquanto agentes mantêm cross-references.

Status: Padrão funcional. Sem plugin dedicado mas zero fricção.

Timeline & Oportunidades

Movido para o Mapa do Ecossistema dedicado.

Veja também

• Spec OKF — guia anotado do formato
• FAQ OKF — o que é o formato e como agentes usam
• Skill OKF — ensine o formato ao seu agente de código
• Mapa do Ecossistema — maturidade e oportunidades