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 recibo real do nosso próprio repo, abreviado.
{
"schemaVersion": "rootblocks.evidence/v1",
"evidenceId": "observed-pr-57-d1aea6afcbf1",
"operationType": "code.merge",
"status": "passed",
"assurance": "observed",
"actor": { "type": "tool", "id": "rootblocks-scan" },
"checks": [
{ "id": "review-gap", "status": "failed", "severity": "error" }
],
"provenance": {
"pullRequest": "Rootblocks/rootblocks-cloud#57",
"review": { "decision": "merged", "reviewer": "anrasi" }
},
"redaction": { "status": "not-needed", "rules": [] }
}
// + uma assinatura ed25519 destacada { keyId, value }
Verifique um recibo offline, só com a chave pública:
$ npx rootblocks-verify rootblocks-receipt.json --key rootblocks.pub
✓ signature valid · schema evidence.v1 · not tampered
Sim: este recibo registra um check reprovado, um PR escrito por um agente que fez merge sozinho, sem revisão, no nosso próprio repo. O escaneamento completou (status: passed) e registrou a lacuna com honestidade. Essa lacuna é exatamente o que o RootBlocks existe para expor.
Entregue este arquivo para qualquer pessoa. Ela não precisa de nós para verificá-lo.
Apache-2.0 O formato de recibo é uma especificação aberta, publicada em standards.rootblocks.com, e o verificador também: você roda com npx, sem conta e sem cadastro. Leia, faça um fork, ou escreva o seu a partir do esquema. Se desaparecêssemos amanhã, cada recibo que você já tem continua verificando. Evidência que depende do fornecedor continuar vivo não é evidência.
- operationType o evento governado: um merge, uma execução, um release.
- provenance.agent qual agente produziu a mudança, e com qual modelo rodou. Distinto do ator da operação.
- decisionRefs a decisão humana que autorizou essa mudança, referenciada por id. A âncora da trilha.
- assurance o selo: quão forte é o respaldo do recibo. observed, proven, traced, enforced.
- 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.
- signature destacada: ed25519 sobre os bytes canônicos, mais o id da chave de assinatura.
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.* + decisionRefs mapeia para a Cláusula 8 da ISO 42001 (controle operacional) e SOC 2 CC8.1 (gestão de mudanças).