Why visible change history belongs to the product, not the docs

Every recipe version, every reversing entry, every migration leaves a change behind. In many systems that change only lands in the developers' commit log or in a wiki nobody opens during a shift. Whoever asks in the afternoon why today's batch looks different from yesterday's needs an answer inside the system, not in a separate tool.

History is not a reporting feature bolted on afterwards. It is the other side of the same irreversibility that already applies to bookings: if a reversing entry keeps a correction visible instead of deleting it, it must also be visible when and why the recipe version behind it changed.

In practice that means every version carries a timestamp, a reason and, where possible, a person or role. Not as a free-text field that often stays empty, but as a required entry at the point where the change happens. When the recipe version changes on the workbench, that is the same moment the reason gets recorded.

Without that coupling, the explanation moves into someone's head. The person who changed the version still remembers. Three months later, nobody does. Then no one is left to answer a customer's question about why a batch in March was composed differently than one in January.

For technical decision-makers: ask for a change history that grows out of daily operation, not out of a bolted-on export function. The test is the same as for the day close: can someone explain in six months why a given version was valid at a given time, without digging through the git log or a ticket system.