evidence.v1 · ed25519

O recibo, explicado

Toda mudança governada produz um recibo assinado: evidence.v1. Esta página é o detalhe completo: o que ele contém, por que é assinado do jeito que é, e como qualquer pessoa o verifica sem confiar em nós.

O recibo, anotado

// evidence.v1, um merge governado { "schema": "evidence.v1", "operationType": "code.merge", "actor": { "agent": "claude-code", "session": "7f3a" }, "provenance": { "decision": "DEC-214", "pr": 477 }, "checks": { "typecheck": "pass", "test": "pass:142", "scope": "src/payments/*" }, "redaction": "none", "sig": "ed25519:46367c53", "keyId": "sha256:", "ledger": "#9f2a" }
Verifique um recibo offline, só com a chave pública: $ rootblocks verify receipt.json --key rootblocks.pub ✓ signature valid · ledger #9f2a · not tampered

Entregue este arquivo para qualquer pessoa. Ela não precisa de nós para verificá-lo.

  • operationType o evento governado: um merge, uma execução, um release.
  • actor.agent qual agente produziu a mudança, e sua sessão.
  • provenance.decision a decisão humana que autorizou essa mudança. A âncora da trilha.
  • checks os gates e o escopo de caminhos aplicado, como de fato rodaram.
  • redaction o que foi omitido do recibo, declarado, para que a ausência também seja auditável.
  • sig / keyId / ledger ed25519 sobre bytes canônicos, a chave de assinatura, a posição no ledger somente de anexação.

Por que ed25519

As assinaturas são feitas sobre os bytes canônicos do recibo, então qualquer mudança em qualquer campo quebra a assinatura. Não há espaço para um recibo que diz uma coisa e prova outra.
ed25519 é um esquema de assinatura moderno e amplamente auditado: chaves pequenas, assinaturas pequenas, assinatura determinística, e sem necessidade de uma autoridade certificadora. A verificação é uma única operação de chave pública que roda em qualquer lugar, inclusive em máquinas isoladas da rede.
A chave privada é gerada por instalação e nunca sai do host do daemon. Cada recibo carrega seu keyId, então rotação e revogação são parte do formato de evidência, não uma reflexão tardia.

Por que a verificação offline importa

Um auditor, um cliente ou um regulador não deveria precisar confiar na RootBlocks para checar sua evidência. O rootblocks verify pega um recibo e a chave pública, e responde com matemática, não com nossa palavra.
Essa é a diferença entre um log e evidência. Um log vive dentro de um sistema que pode editá-lo. Um recibo é assinado em um ledger somente de anexação e se verifica em qualquer lugar, em qualquer máquina, sem conta e sem rede.

Uma política, na íntegra

policy: payments-tier scope: allow: ["src/payments/**", "test/payments/**"] deny: ["**/secrets/**", "infra/**"] gates: [ typecheck, test, lint ] # all required allowedTools: [ Edit, Read, "Bash(npm *)" ] limits: { maxFiles: 40, maxRuntime: "20m" } onGateFail: block # no commit, no receipt

Modos de falha

Daemon fora do ar configurável por política: fail-closed (agentes não conseguem mergear sem prova) ou fail-open (roda, marca como observado, reconcilia depois).
Plano de controle fora do ar os recibos são escritos primeiro localmente, no ledger somente de anexação, que é o que roda hoje. A sincronização com a nuvem (chegando com os design partners) retoma ao reconectar.
Gate falha sem commit, sem recibo. A própria tentativa fica registrada como evidência.

O que sai da sua infraestrutura

Sai
Nunca sai
hashes de conteúdo
código-fonte
assinaturas ed25519
diffs
metadados de checks (passou/falhou)
prompts do agente
IDs de decisão e de PR
conteúdo dos arquivos

Chaves, e o que a assinatura prova

Gerada por instalação, na primeira execução. A chave privada nunca sai do host do daemon.
Rotação cada recibo carrega seu keyId, então rotação e revogação já fazem parte do formato de evidência. O procedimento de reancoragem vem com o programa enterprise.
Nós provamos que essa execução, sob essa política, ficou vinculada a essa decisão humana ratificada. Não certificamos o raciocínio interno do agente, que é exatamente por que ancoramos a evidência na decisão humana, não na narrativa do modelo.
checks.* + provenance.decision mapeia para a Cláusula 8 da ISO 42001 (controle operacional) e SOC 2 CC8.1 (gestão de mudanças).
ISO 42001 · SOC 2 →