Test Changes Before Broad Release

A definition change silently alters every historical number computed from it. That is one of the more alarming things that can happen to a reporting system and it happens routinely, because changing a definition looks like editing a field.

So configuration changes get validation before they publish: what does this change, how many records move, and what does the historical series look like before and after. That is a preview, in exactly the sense Pillar 3 used the word, applied to a definition rather than to a bulk operation.

Test on a slice with no external dependency

The delivery sequence from a real technical guide doubles as a test method: map the decision and the source data, build a read-only slice, add review and exception paths, introduce automation, then monitor.

The read-only slice is the part worth extracting. Prove the change produces the right answer somewhere it cannot affect anything, before it can fail for reasons outside your control.

Write the acceptance criterion first

Before making the change, write what would count as it having worked, and what would count as it having failed. Both, in advance, in numbers where possible.

Written afterwards, the criterion is chosen to match whatever happened. That is not dishonesty, it is how people work, and writing it first is the only defence.