Main idea

The natural move, when a rule changes, is to update the document that held it. Two years after writing "French and English by default, other languages subject to signed revenue", the team that decides to machine-translate secondary languages with human review on critical journeys opens the file and corrects the sentence.

That move destroys exactly what the document was there to preserve. A decision is not a state; it is a pair: a choice and the context that made it reasonable. Rewriting does not just replace the old choice, it deletes the old context — the translation costs of the time, the quality then achievable, the support tooling of the day. What is left is a current rule with no past, indistinguishable from a rule that had always been the rule.

The right form is therefore accumulation: the old decision stays in place, marked as superseded, and points to the one that takes over. The old one explains why the company had said no; the new one explains why that no longer fits. Neither says the other was wrong.

The same form holds for the description of an object, and for one further reason. When an object in a product is rethought from top to bottom, you do not modify its card: you create a new one, and the old one stays. It does not only explain what people thought at the time — it is still needed to interpret the data and exchanges that predate the change, which go on existing and being read according to the old model.

Layer added by "I wrote a product's ontology. Three times, I thought I was done." (2026-08-11).

Layer added by "Ontology-Driven Design: what if the ontology became the safety net for AI-generated code?" (2026-10-29). The rule extends to changes in a business ontology kept up against the code. A renamed concept must not turn into two independent concepts, and a deleted business rule — "every order originates from a quote", in an ERP — must stay linked to the decision that justified removing it, for example in a small log inspired by ADRs. Changes to the model must be as traceable as changes to the code.

Why it matters

It prevents a common and not very honourable use of decision documents: rewriting them to hide a change of position, which gives the organisation the retrospective appearance of having always been right.

It also supplies the material nobody thinks of keeping — the succession of contexts — which is the only way to know how fast a company's assumptions go out of date.

Nuances and limits

Accumulation has a reading cost: several decisions stacked on the same subject mean you have to know which one is in force, which assumes disciplined marking that nothing guarantees.

And not every correction is a replacement: fixing a drafting error or clarifying an ambiguous wording does not change the decision and calls for no new document.

Open questions

• After how many successive replacements does a series of decisions on the same subject stop being readable, and what should be done with it then?