Quando o passado vira contrato: snapshots de execução imutáveis

Imagine esta cena...

Dezoito meses após uma execução crítica, alguém te pede provas. Não uma explicação aproximada. Provas.

Querem saber quais entradas foram realmente consumidas, quais contratos estavam ativos, qual resultado foi aceito como verdade e se aquilo ainda pode ser reproduzido sem depender do estado atual do sistema.

Existem logs. Já existe o estado persistido no banco de dados. Existe o código atual. Talvez exista até um stream de eventos. O que geralmente não existe é um único artefato com autoridade suficiente para, por si só, explicar a execução histórica.

É nesse momento que muitos sistemas descobrem uma verdade incômoda: eles não preservam o passado. Preservam resíduos do passado.

O tema aqui não é armazenamento nem observabilidade. O tema é mais específico: qual artefato tem autoridade para responder por uma execução depois que o código, o tempo de execução e a equipe já mudaram.

As testemunhas erradas

Quase todos os sistemas tentam resolver esse problema sem admitir que estão tentando.

Fragmentos de verdade se espalham por diferentes camadas. Em algum momento, alguém precisa reconstruir a história correta a partir deles. Essa expectativa costuma se apoiar em quatro testemunhas ruins.

Logs

Logs são ótimos para responder perguntas operacionais: onde existiu latência, qual requisição falhou, qual nó processou a chamada, quanto tempo levou uma execução.

O problema é que os logs não têm nenhuma obrigação estrutural de representar a superfície causal de uma execução. Eles carregam um excesso de contexto incidental e carecem precisamente da delimitação deliberada que a auditoria exige.

Log é rastro. Rastro não é contrato.

Estado mutável de banco

Uma linha de banco de dados parece histórica até o dia em que ela é corrigida, enriquecida, reprocessada ou parcialmente sobrescrita por uma rotina posterior.

O problema aparece quando o mesmo registro tenta desempenhar dois papéis incompatíveis: representar o resultado aceito de ontem e continuar disponível para conveniência operacional amanhã.

A aplicação continua funcionando. O que colapsa é a autoridade do registro sobre o passado.

Stream de eventos

Streams são úteis para descrever transições. Mas a pergunta histórica mais importante raramente é "quais transições ocorreram". Ela geralmente é: qual artefato final foi aceito como verdade causal daquela execução.

Sem um snapshot final explicitamente selado, o stream transfere a responsabilidade para o consumidor. Cada consumidor precisa decidir qual redução, projeção e política de compatibilidade definem o que de fato aconteceu.

Isso é arquitetura insuficiente disfarçada de flexibilidade.

Reexecução com o código atual

Esse é o atalho mais traiçoeiro.

As equipes dizem: "se alguém pedir depois, a gente recalcula". O verbo é elegante; a semântica é falsa.

Se o modelo mudou, a validação mudou, os casos de borda mudaram, a ordenação mudou ou a biblioteca mudou, você não está reproduzindo a execução antiga. Está executando o presente sobre uma representação imperfeita do passado.

Isso pode ser útil para comparação, mas não pode ser chamado de replay sem degradar o significado da palavra.

O artefato que falta

Se logs, banco de dados mutável, stream e reexecução não têm autoridade suficiente, então a execução precisa produzir seu próprio artefato soberano.

É isso que um snapshot de execução imutável faz.

Ele não é um cache. Não é um objeto de conveniência. Não é um dump arbitrário. Ele é o ponto em que a execução deixa de ser um processo e passa a ser um registro histórico com identidade própria.

O que muda aqui não é só a persistência. O que muda é a topologia da verdade.

O conceito central aqui é o envelope histórico: o recorte deliberado do que atravessa o tempo como verdade da execução. Sem ele, o sistema não consegue distinguir causalidade preservada de contexto incidental.

Esse padrão não torna o sistema inteiro determinístico. O que ele preserva, com força de replay, é a superfície causal que a execução aceitou como verdade. Fontes de tempo, chamadas externas e outros efeitos não entram na história por existência própria; entram quando seus efeitos relevantes são explicitamente vinculados ao envelope histórico.

Em vez de reconstruir a execução a partir de várias fontes imperfeitas, o sistema passa a declarar: esta é a execução histórica. O resto orbita em torno dela.

O que precisa caber dentro desse envelope

Um snapshot bom não tenta capturar tudo. Ele tenta capturar o suficiente para permanecer autossuficiente.

Essa distinção é central. Sistemas frágeis erram em duas direções:

• ou gravam pouco demais e forçam reconstrução externa;

• ou gravam tanto ruído operacional que tornam o artefato instável e semanticamente confuso.

O critério correto é outro: toda informação que altera a interpretação causal da execução precisa estar dentro do envelope histórico.

Visto em fluxo, o envelope histórico opera assim:

graph LR
    INPUTS["Entradas normalizadas"] --> ENGINE["Motor determinístico"]
    BINDINGS["Bindings de contrato"] --> ENGINE
    ENGINE --> ENVELOPE["Envelope histórico"]
    ENVELOPE --> CANON["Canonicalização"]
    CANON --> HASH["snapshot_hash"]
    HASH --> SNAPSHOT["Snapshot selado"]
    LOGS["Logs e métricas"] -. suporte operacional .-> ENGINE

Se um campo altera a resposta para "o que o sistema realmente executou", ele pertence ao snapshot. Se apenas auxilia na operação ou investigação do tempo de execução, não deve ter autoridade histórica.

Essa separação é menos intuitiva do que parece. Muitas equipes confundem importância operacional com importância causal. O envelope histórico existe para impedir exatamente essa mistura antes que ela contamine o snapshot selado.

Selar não é salvar

Salvar um objeto em JSON não o torna histórico. Calcular um hash isoladamente também não.

Um artefato só fica selado de verdade quando três decisões acontecem em ordem correta:

1. a superfície causal é definida explicitamente;

2. essa superfície é canonicalizada;

3. o digest é calculado sobre a forma canônica, não sobre uma serialização incidental.

Em termos mínimos, o envelope selado se parece mais com isto do que com um dump arbitrário:

{
	"inputs": { "...": "..." },
	"outputs": { "...": "..." },
	"contract_versions": {
		"engine": "1.8.0",
		"ruleset": "2.4.0"
	},
	"plan_hash": "sha256:...",
	"binding_hash": "sha256:...",
	"snapshot_hash": "sha256:..."
}

O hash não é a parte mais sofisticada dessa história. O ponto difícil é anterior: decidir o que entra no objeto, em que forma entra e quais ambiguidades de serialização foram eliminadas antes do digest.

Sem isso, o hash é apenas um selo bonito colado sobre uma estrutura semanticamente mal definida.

Append-only

Append-only não é uma decisão de armazenamento. É uma decisão de honestidade histórica.

Quase todas as equipes, cedo ou tarde, sentem a tentação de "corrigir" um registro antigo.

A entrada pode estar errada. O contrato pode ter sido ajustado. Um modelo pode ter sido corrigido. O impulso operacional é compreensível: editar o artefato antigo parece mais barato do que emitir um novo.

Mas o preço epistemológico é alto demais.

Quando um snapshot histórico é editado, o sistema mistura dois fatos incompatíveis no mesmo objeto:

• o que realmente aconteceu;

• o que gostaríamos que tivesse acontecido.

Depois dessa mistura, o registro continua existindo, mas já não responde por nenhum dos dois com precisão.

Por isso, um snapshot histórico sério é append-only. Se algo muda, um novo snapshot nasce. O antigo continua existindo como verdade histórica daquele momento. O novo representa a nova execução, sob novas premissas, novos bindings ou novas correções.

O passado não é atualizado. Ele é preservado como fato histórico, enquanto novos snapshots passam a representar execuções sob novas premissas.

O núcleo histórico não precisa carregar tudo que o sistema sabe

Esse ponto costuma gerar outro tipo de erro estrutural.

Depois que uma equipe aceita a ideia de snapshot, ela passa a querer colocar tudo dentro dele: explicabilidade detalhada, grafos de justificativa (reason graphs), relatórios de auditoria, visualizações, anotações e projeções analíticas. A intenção é boa. O efeito costuma ser ruim.

O snapshot principal deve conter o que é necessário para replay, auditoria e identidade histórica. Artefatos derivados, mesmo valiosos, não precisam contaminar esse núcleo se puderem ser gerados deterministicamente a partir dele.

Essa separação compra duas propriedades importantes ao mesmo tempo:

• o núcleo histórico permanece pequeno, estável e difícil de corromper;

• camadas derivadas podem evoluir sem reescrever o contrato fundamental do passado.

O núcleo histórico não existe para absorver tudo o que o sistema sabe. Existe para preservar, com autoridade, o que aquela execução realmente foi.

O que essa disciplina custa

Essa disciplina cobra o que equipes impacientes quase sempre tentam adiar: permanência, contrato explícito e custo operacional assumido no presente para evitar arqueologia distribuída no futuro.

Ela exige armazenamento que não pode ser descartado por conveniência, binding de versões que não pode virar detalhe opcional e evolução de esquema que não pode ser tratada como refatoração inocente. Exige também índices para consulta histórica, políticas de retenção, compatibilidade entre versões de snapshot e validação de replay toda vez que o tempo de execução muda de forma relevante.

Mas o custo mais incômodo não é de infra. É cultural. Atalhos operacionais deixam de ser aceitáveis quando podem contaminar o passado. O sistema perde conveniência local para ganhar autoridade histórica.

Esse custo é real. O custo da alternativa é pior: um sistema que continua funcionando sem conseguir mais responder, com precisão e autoridade, pelo que realmente executou. A recompensa dessa disciplina não aparece como uma feature isolada; aparece como redução de ambiguidade. Auditoria deixa de ser arqueologia distribuída, replay recupera significado forte, consumidores passam a operar sobre a mesma verdade histórica e o tempo de execução pode evoluir sem reescrever retroativamente o passado.

O nome correto para isso não é burocracia. É integridade.

O teste decisivo

Existe um teste simples para saber se esse padrão é necessário.

Pergunte ao sistema:

Se eu voltar daqui a dois anos, com outra equipe, o código evoluído e o tempo de execução diferente, existe um único artefato capaz de me dizer o que foi executado, sob quais contratos, e me permitir validar essa execução sem reconstrução manual?

Se a resposta for não, o sistema ainda não tem memória histórica. Tem resíduos.

E software crítico não deveria tratar o passado como resíduo.

Deveria tratá-lo como contrato.