Ideia principal

O gesto natural, quando uma regra muda, é atualizar o documento que a registrava. Dois anos depois de ter escrito "francês e inglês por padrão, outros idiomas condicionados a faturamento assinado", a equipe que decide traduzir automaticamente os idiomas secundários, com revisão humana nas jornadas críticas, abre o arquivo e corrige a frase.

Esse gesto destrói exatamente o que o documento servia para guardar. Uma decisão não é um estado, é um par: uma escolha e o contexto que a tornava razoável. Reescrever não substitui só a escolha antiga, apaga também o contexto antigo — o custo de tradução da época, a qualidade que dava para atingir na época, as ferramentas de suporte da época. O que sobra é uma regra atual sem passado, impossível de distinguir de uma regra que sempre tivesse sido aquela.

A forma certa, portanto, é a acumulação: a decisão antiga continua no lugar, marcada como substituída, e aponta para a que a substitui. A antiga explica por que a empresa tinha recusado; a nova explica por que essa recusa não faz mais sentido. Nenhuma das duas diz que a outra estava errada.

A mesma forma vale para a descrição de um objeto, e por um motivo a mais. Quando um objeto de um produto é repensado de cabo a rabo, você não altera a ficha dele: cria uma nova, e a antiga continua lá. Ela não serve só para explicar o que se pensava na época — ela continua necessária para interpretar os dados e as trocas anteriores à mudança, que continuam existindo e sendo lidos segundo o modelo antigo.

Camada trazida por "Escrevi a ontologia de um produto. Três vezes achei que tinha terminado." (2026-08-11).

Camada trazida por "Ontology-Driven Design: e se a ontologia virasse a rede de segurança do código gerado por IA?" (2026-10-29). A regra se estende às evoluções de uma ontologia de negócio mantida em relação ao código. Um conceito renomeado não deve virar dois conceitos independentes, e uma regra de negócio removida — "todo pedido de venda vem de um orçamento", num ERP — precisa continuar ligada à decisão que justificou o seu fim, por exemplo num pequeno registro inspirado nos ADR. A evolução do modelo precisa ser tão rastreável quanto a do código.

Por que isso importa

Isso impede um uso comum, e pouco confessável, dos documentos de decisão: reescrevê-los para esconder uma mudança de posição, o que dá à organização a aparência retrospectiva de ter sempre tido razão.

Isso também fornece o material que ninguém pensa em guardar — a sequência dos contextos sucessivos —, que é a única forma de saber em que velocidade as premissas de uma empresa vencem.

Nuances e limites

A acumulação tem um custo de leitura: várias decisões sobrepostas sobre o mesmo assunto obrigam a saber qual está em vigor, o que pressupõe uma marcação disciplinada que nada garante.

E nem toda correção é uma substituição: corrigir um erro de redação ou precisar uma formulação ambígua não muda a decisão e não pede um documento novo.

Questões em aberto

• Depois de quantas substituições sucessivas uma série de decisões sobre o mesmo assunto deixa de ser legível, e o que fazer com ela nesse momento?