the deletion test that had to roll back to mean anything

Every retention policy is a promise to delete, and deletion is the one operation you cannot review by reading it. A predicate with the wrong comparison either keeps everything forever or removes a row that mattered, and both look identical in a report that says the job ran successfully.

The procedure in question deletes in committed batches, which is right for work that must not hold a long transaction and inconvenient for testing, because it cannot simply be wrapped and rolled back. So the rehearsal ran the exact predicates instead: the same conditions, executed as delete-with-returning inside a single transaction against a live populated database, with counts captured and then the whole thing rolled back.

The honest part is what zero meant. On freshly seeded data nothing was old enough to delete, and the record says so plainly rather than presenting zero as proof of correctness. What made the run evidence was the second half: a backup family younger than the retention window was correctly retained, the rows that should survive did, the post-rollback state matched the pre-run state exactly, and no unexpected row was touched.

A dry run that deletes nothing is only meaningful once you have also shown that it deletes the right things, only those, and leaves the state unchanged when it finishes.

What it proves: irreversible operations are rehearsed as reversible experiments, and the team can tell a policy with nothing to do apart from a policy that works.