O ledger estava grande demais. Não quebrado — grande. Grande a ponto de eu evitar consultá-lo diretamente, porque cada leitura do histórico inteiro era mais cara que a pergunta que eu queria responder. E aí veio a tentação que quase virou erro: resumir.
No texto anterior, mostrei duas camadas: o ledger preserva a verdade histórica, e o esquecimento governado protege a verdade operacional — memórias ativas separadas de aposentadas, com registro da decisão e caminho de volta.
O problema que sobra é de peso. O ledger nunca apaga, então ele só cresce. Com meses de uso, o volume de entradas vira um bloco que o sistema precisa ler, filtrar e curar sempre que monta contexto para uma decisão nova. Mesmo com o filtro do esquecimento governado — que já isola as memórias aposentadas — só o que está ativo pode ser grande demais para o uso fluido. O sistema começa a gastar mais tempo lendo o passado do que pensando no presente.
A pergunta que surge é: como um sistema que nunca apaga o histórico impede que o peso do passado trave o presente?
O caminho que parece óbvio — e falha
A primeira ideia que vem à mente é resumir. Pegar o bloco de entradas e comprimir: juntar o que é parecido, eliminar repetições, extrair o essencial e guardar só o resumo. O ledger fica menor, o sistema lê mais rápido, e a informação importante — em tese — está toda lá dentro do resumo.
Falha por um motivo que só aparece quando você tenta: resumo quebra proveniência.
Proveniência é o que permite ao sistema responder "de onde veio esta informação?". Sem ela, uma decisão armazenada perde o vínculo com o contexto que a gerou. O resumo diz "preferência: TypeScript para módulos novos" — mas não diz mais quando foi decidido, com base em que critério, nem qual era o estado do projeto na época. A informação sobrevive; a história morre.
E sem história, o sistema perde a capacidade de rever uma decisão com evidência. Perde o que o ledger existia para preservar.
A consequência prática é sutil e grave. O resumo parece uma otimização de desempenho. É uma perda de verdade disfarçada de compressão.
O que compactação significa neste contexto
Compactação não é resumo. É o inverso: é reconstrução do estado ativo a partir da fonte, sem perder o vínculo com a origem.
Pense na diferença com um exemplo simples. Você tem dez entradas no ledger: três decisões de arquitetura, duas preferências de ferramenta, cinco observações sobre o andamento do projeto. Com o tempo, duas decisões foram superadas por revisões, uma preferência mudou, e três observações perderam contexto. O ledger inteiro tem dez itens; o que realmente importa para as próximas decisões são quatro — as que ainda estão ativas e conectadas ao contexto atual.
Compactação faz o seguinte: lê as dez entradas, reconstroi o estado ativo (as quatro que importam), e escreve um novo bloco compactado que contém exatamente essas quatro — mas cada uma carrega o identificador da entrada original no ledger. A proveniência não se perde: aponta de volta para o histórico completo.
O ledger original continua existindo. O que muda é que o sistema pode agora ler um bloco menor para montar contexto, e só consultar o histórico completo quando precisa auditar uma decisão específica.
A lista ordenada a seguir mostra os passos do mecanismo:
- o sistema identifica quais entradas ativas ainda são elegíveis para o contexto atual;
- lê as entradas originais no ledger, uma a uma;
- reconstroi o estado combinado — decisões, preferências, critérios — como um bloco novo;
- cada item do bloco novo carrega um ponteiro de volta para a entrada original no ledger;
- o ledger registra a operação de compactação como uma entrada nova: data, escopo, e ponteiros;
- o sistema passa a usar o bloco compactado para leitura corrente, mantendo o ledger completo como fonte histórica.
Nada é perdido. Nada é inventado. O que encolhe é o que o sistema precisa carregar para funcionar hoje.
A diferença mecânica que importa
Há uma maneira de ver a distinção que ajuda a fixar. Resumo é uma operação sobre o significado — você julga o que é importante e descarta o resto. Compactação é uma operação sobre a estrutura — você reconstroi o estado de um conjunto de entradas sem interpretar ou descartar.
Resumo perde o que não coube na interpretação. Compactação preserva o que foi registrado, porque parte da fonte, não do julgamento.
A consequência prática é que compactação pode ser automática e auditável do mesmo jeito que o ledger: cada compactação deixa um registro do que foi compactado, quando, e quais entradas originais foram usadas. Se algo parecer errado no estado compactado, o sistema volta ao ledger original e reconstroi — sem depender de interpretação humana.
Resumo, ao contrário, é uma operação irreversível. Uma vez que você descarta a entrada original e guarda só o resumo, não há caminho de volta para o que foi perdido. O ledger que existia para impedir perda silenciosa teria, por ironia, introduzido o maior buraco de todos.
O momento que ensinou a diferença
Passei tempo demais tentando reparar um banco de desenvolvimento que tinha divergido do esquema real. Cada conserto criava uma divergência nova — porque eu estava tentando remendar a superfície em vez de reconstruir o estado a partir da fonte. O banco funcionava. As respostas estavam certas. Mas a cada reparo, a distância entre o que o banco dizia e o que o ledger registrava aumentava um pouco.
A decisão que ficou foi a mesma que define compactação: ambiente divergente não se conserta, se recria do zero. Estado reconstruível vale mais que estado estimado.
O que a compactação muda na arquitetura
Sem compactação, o ledger é fiel e pesado. Com ela, o ledger permanece fiel — e o sistema ganha um pavimento intermediário entre o histórico completo e a próxima decisão.
A arquitetura ganha três coisas:
- Velocidade de leitura. O bloco compactado é menor, e o sistema percorre menos entradas para montar contexto.
- Proveniência preservada. Cada item do bloco compactado aponta para a entrada original. Não há perda de história.
- Reconstrução possível. Se o bloco compactado corromper ou ficar desatualizado, o sistema pode reconstruí-lo do ledger completo sem perda.
O que a arquitetura perde:
- Complexidade de implementação. Compactação não é trivial — requer identificar escopo, garantir consistência, e lidar com compactações concorrentes durante gravações ativas no ledger.
- Custo de execução. Reconstruir o estado consome recursos — não é uma operação que se faça a cada leitura, e sim um processo periódico.
A troca é justa para um sistema que cresce com o tempo. O ledger garante que nada se perde. O esquecimento governado garante que o que morreu para de pesar. A compactação garante que o que ainda pesa não imobilize o presente.
O que este degrau fecha na escada de memória
Com este texto, a escada de memória do Atlas fecha três camadas que funcionam juntas: proveniência garante que toda memória tem fonte; esquecimento governado garante que o sistema esquece com critério; compactação garante que o que sobrevive ao critério cabe no presente.
A pergunta que fica é sobre o que acontece quando o próprio critério de decisão — não a memória, mas a capacidade de agir — precisa ser governado. Quando o sistema não só decide, mas decide se deve ou não decidir.
O próximo texto da série é Recusa como feature de produto.