Main idea

Detail corrections are not what makes a product description evolve. The two most frequent movements, once the first cards are written, are the merging of two objects thought to be distinct and the splitting of an object that was hiding two. They carry an understanding that has changed, and they rewrite the links of every neighbouring card at the same time.

No tool tells that story: a repository shows one card deleted and two cards created, a matching engine shows an object that stops corresponding. The sentence "these two objects were only ever one" exists only if somebody writes it, in the log of the cards concerned.

The same goes for the extreme case: an object rethought from top to bottom isn't modified, it gives rise to a new card, and the old one stays. It describes what the product used to be, and it remains necessary in order to interpret data and exchanges predating the change.

Why it matters

This points to what the log of a reference model has to carry as a priority: not the small corrections, which can be guessed, but the movements in how things are divided up, which are invisible and structural.

And it protects a capability rarely anticipated: understanding old data presupposes having the description of the model in force at the time, not just the current model.

Nuances and limits

Merging and splitting are not equally safe. Splitting is reversible: the two cards link to each other and you can go back. Merging erases a distinction that later work may demand, and that loss can only be recovered by rereading the sources.

And not every movement is progress: a split motivated by a technical exception divides the model along the structure of the code rather than along the business.

Open questions

• How do you attach an old piece of data to the right state of an object, when that object has been split in the meantime?