Preview Before Changing Important Data

Preview is the cheapest control in this guide and the most commonly faked.

A screen that says “this will affect 1,412 records” is not a preview. It is a count. The person looking at it has no way to tell whether the population is right, and the population is the thing that is usually wrong.

Three things a preview must show

The population, defined. Not the number, the definition. Which records, by what rule, so the reader can disagree with the rule.

The actual before and after. For a sample, and for the specific fields that will change. A preview that shows what will be written but not what is currently there cannot surface the case that matters, which is the record where the new value is worse than the old one.

The count, by category. Not one total. How many will be added, how many removed, how many are blocked by a gate and why, and how many are already correct and will not be touched. That last number is the one that tells you whether the operation is doing what you think, because for a correctly scoped operation it is never zero.

The button that fixes something is an action

The remediation button, the one that repairs a problem the system found, is itself an action with a blast radius. It needs to be idempotent, so pressing it twice does not do it twice. It needs to be permission-checked, because the person looking at the problem is not always entitled to fix it. And it needs its own audit entry, separate from the thing it repaired.

A fix-it button that skips those is how a data-quality tool becomes a data-quality incident.