Reversibility is what makes confirming a merge a four-second decision rather than a careful one, and it is only real if the right things were stored beforehand. An undo built from a diff produces a third record that matches neither original.
Key takeaways
Store both original records in full, plus every related-record move.
Undo restores; it never reconstructs. A diff is not enough.
Anything that happened after the merge stays with the record it was created on.
Ninety days is a sensible window, and the report says what has passed it.
The number to watch is undos as a share of merges; it should be very low and not zero.
What has to be stored
Fig 1. What is captured before a merge runs. The bundle is written before the change rather than after it, which also makes a partial failure recoverable.
Storage
Database
Machine learning
Management
Snapshots, not diffs
A diff is smaller and it is not enough. Reversing from a diff requires the current state to be exactly what the merge produced, and by the time somebody wants an undo, somebody else has usually edited the merged record. Applying a reverse diff to a changed record produces a third state that never existed.
Storing both records in full means undo is a restore: put record A back as it was, put record B back as it was, and move the related records back to whichever they came from. That is unambiguous regardless of what happened in between.
What cannot be undone
Fig 2. The one case an undo cannot resolve on its own. Records created after the merge belong to neither original and need a person’s judgement.
App integration
Management
Analytics
People
This is genuinely undecidable by the system and the honest handling is to say so: the undo restores both records, moves back everything that was moved, leaves anything created afterwards on whichever record survived, and reports exactly what it left behind. A person then spends thirty seconds deciding where the Tuesday order belongs.
The window
Ninety days is a reasonable default. Undo bundles are small but not nothing, and the practical observation is that almost every undo request comes within a fortnight — somebody notices the merged record looks wrong the next time they open it.
What matters more than the exact number is that the report says which merges have passed the window, so “can we undo the merge from March” has an answer before somebody starts looking for it.
The numbers
Fig 3. A month of merging in five numbers. The undo count is the calibration signal and it should be low rather than absent.
Machine learning
Security & identity
Management
Analytics
The rejection count is the more useful tuning signal. Seventeen rejections out of fifty-eight proposals means about thirty per cent of what the scorer proposes is wrong, which is high but not alarming for a system where rejecting costs four seconds. Fifty per cent would mean the threshold is too low; five per cent would suggest it is too high and real duplicates are being scored below the proposal line.
A zero undo rate sustained over months is worth noticing rather than celebrating: it usually means the automatic band is set so conservatively that almost nothing merges without a person, which is safe and may be leaving obvious duplicates in place.