24 · Hash, arquivamento e auditoria externa

Sem rastreabilidade, não há infraestrutura — só análise sofisticada. Este capítulo descreve o mecanismo simples (e deliberadamente leve) que permite a um auditor independente refazer qualquer cálculo do agente em até dois anos.

24.0 · Auditabilidade como propriedade arquitetural

Auditabilidade não é um anexo do sistema — é uma propriedade que precisa estar embutida na arquitetura desde o primeiro byte. Em termos de Lessig (1999), "code is law": se o código não preserva o estado exato em que uma decisão foi tomada, nenhuma cláusula de governança recupera essa rastreabilidade depois. A literatura de pesquisa reproduzível (Peng, 2011; Stodden et al., 2016) converge em três requisitos mínimos: (i) determinismo — mesmas entradas produzem mesmas saídas, bit a bit; (ii) congelamento — entradas, código e parâmetros são imutáveis após publicação; (iii) verificabilidade independente — um terceiro, sem acesso aos autores originais, consegue reproduzir o resultado em tempo razoável.

O agente atende esses três requisitos via uma combinação deliberadamente simples: hash determinístico sobre o JSON canônico da calibração, snapshot congelado dos dados de entrada e script de verificação em ~200 linhas. Note a escolha por simplicidade extrema: nada de blockchain, nada de assinatura digital criptográfica, nada de timestamping externo. Essas tecnologias não são ruins — são excessivas para o problema. O risco real não é fraude criptográfica (improvável em uma fundação com governança colegiada e auditoria contábil anual); é perda silenciosa de rastreabilidade por edição manual, sobrescrita acidental ou erro de versionamento. Contra isso, FNV-1a + JSON canônico + snapshot são suficientes e têm a virtude de poderem ser reimplementados em qualquer linguagem em uma tarde.

24.1 · Por que FNV-1a 32-bit

A escolha do hash Fowler–Noll–Vo (FNV-1a, 32-bit) é deliberada: ele não é criptograficamente seguro (não precisa ser — não estamos protegendo segredos), mas é determinístico, rápido, sem dependências externas e legível por humanosem 8 caracteres hexadecimais.

24.2 · O ciclo de arquivamento

1. Conselho aprova nova calibração na tela /score.
2. Sistema gera hash, congela snapshot dos dados, calcula Top 10.
3. Cria PDF executivo carregando o hash no rodapé de cada página.
4. Armazena tupla (hash, JSON canônico, PDF, autor, timestamp) no Arquivo de Calibrações.
5. Drift Log é atualizado com diff em relação à calibração anterior.

24.3 · O que um auditor externo recebe

• O JSON canônico da calibração (~3 KB).
• O snapshot dos dados de entrada (~50–80 MB compactado).
• O PDF executivo publicado.
• Um script de verificação (~200 linhas Python) que recomputa o hash, recalcula o Score e diffa o Top 10 contra o publicado.

Se os três coincidirem (hash, Score, Top 10), a auditoria está atestada. Divergências em qualquer um dos três disparam investigação formal e congelamento de novas calibrações até a causa-raiz ser identificada.

24.4 · Retenção

Calibrações são retidas por 10 anos a partir da data de publicação. PDFs executivos por tempo indeterminado. Snapshots de dados maiores que 100 MB são movidos para storage frio após 24 meses, mas continuam recuperáveis em até 48h via solicitação ao Comitê de Tecnologia.