Um contrato portátil para sistemas de agentes.

Contrato do documento.

Um arquivo .ohm é um documento UTF-8 declarativo. YAML é a representação destinada à autoria humana; após a leitura, o conteúdo converge para um modelo normalizado comum. O formato não é um arquivo executável, um modelo de linguagem ou uma autorização implícita para executar scripts.

schemaVersion

Versão do contrato de dados. Ela não identifica a sintaxe YAML ou JSON.

manifest

Identidade, versão, descrição, licença declarada e taxonomia do harness.

graph

Participantes (nodes) e relações explícitas (edges), referenciados por identificadores estáveis.

content

Artefatos incorporados, como prompts, agentes, skills, hooks, comandos e scripts.

runtime

Preferências de execução, CLI, ambiente e referências de segredos. Credenciais não pertencem ao documento.

validation

Metadados e perfis usados para verificação estrutural e simulação controlada.

Âncoras e aliases YAML não representam topologia. Ciclos no grafo de dados também não concedem, por si, semântica de repetição: loops exigem contrato específico para condição, orçamento, timeout, cancelamento, estado por iteração e intervenção humana.

Exemplo mínimo.

O exemplo abaixo demonstra a estrutura 1.0.0. O grafo vazio e o prompt multilinha são dados declarativos; nenhum conteúdo é executado ao abrir ou validar o arquivo. O campo license pertence ao exemplo e não declara a licença do aplicativo.

# OHM em YAML 1.2 — contrato declarativo.
schemaVersion: "1.0.0"
manifest:
  id: hello
  name: Hello
  version: "0.1.0"
  description: Exemplo mínimo do Open Harness Model.
  license: MIT
  tags: []
graph:
  nodes: []
  edges: []
content:
  prompts:
    objetivo: |-
      Descreva o objetivo do trabalho.
      Defina as evidências para aceitar o resultado.
  agents: {}
  skills: {}
  hooks: {}
  commands: {}
  scripts: {}
runtime:
  preferred: api
  cli: null
  env: []
  secrets: []
validation:
  mockProfile: default

Validação em camadas e autoridade explícita.

A conformidade estrutural é necessária, mas não suficiente. O OpenHarness separa quatro níveis: leitura segura da sintaxe; validação do modelo normalizado; elegibilidade determinística para execução; e avaliação operacional do resultado. Essa separação evita que uma decisão probabilística seja confundida com uma garantia de segurança.

JSON Schema e invariantes de domínio verificam forma, referências e limites conhecidos. Gates determinísticos permanecem como autoridade para políticas objetivas — permissões, assinaturas, dependências, testes, budgets, timeouts e critérios de release. Aprovação humana permanece obrigatória nos pontos de impacto definidos pelo processo.

Um documento estruturalmente válido não comprova qualidade das instruções, disponibilidade de provedores, segurança de scripts, equivalência entre runtimes ou aptidão para produção. Cada implementação deve declarar capacidades, restrições e evidências de conformidade.

Decisões probabilísticas são auxiliares, não soberanas.

Classificadores e modelos especializados podem reduzir latência e custo em decisões semânticas bem delimitadas, como roteamento sugerido, classificação de contexto e priorização. Eles não substituem controles determinísticos quando a regra pode ser expressa e testada diretamente.

A Laya está sendo avaliada em modo shadow: produz evidência consultiva sem bloquear execução, reduzir severidade, alterar findings ou autorizar releases. No desktop, em caráter experimental, ela também pode escolher na porta de entrada do chat entre responder direto e iniciar o harness; abaixo de 0,80 de confiança, ou sem a Laya disponível, a triagem pelo modelo decide. Nesse papel ela não tem autoridade sobre gates, decisão humana ou merge. Qualquer promoção futura exige conjunto rotulado representativo, métricas previamente definidas, análise de falsos negativos, limites de confiança, fallback seguro e reversibilidade. Treinamento específico para casos do OpenHarness é possível, mas não elimina esse protocolo de validação.

O contrato OHM atual não define um campo normativo system_one_evaluator nem delega autoridade de gate a Laya, LLMs ou outros classificadores.

Escopo e maturidade.

O OHM adota YAML 1.2 para autoria e preserva JSON nos contratos de API e execução. Documentos legados em JSON continuam relevantes para compatibilidade. A serialização canônica busca determinismo após normalização, sem prometer identidade textual, preservação de comentários ou estilo de entrada.

A capacidade de representar um grafo é distinta da capacidade de executá-lo. Semântica de loops, portabilidade integral, roundtrip entre ferramentas e equivalência operacional exigem contratos e testes próprios; não são consequências automáticas da escolha do formato.

O OHM é uma proposta técnica do OpenHarness em evolução. Ainda não constitui um padrão independente, mas foi concebido para buscar adoção ampla, interoperabilidade entre ferramentas e, à medida que amadureça, uma governança aberta e independente.

O manifesto apresenta os princípios institucionais que orientam essa evolução.