Why Automation Needs Proof of Change, Not Just a Success Code

A software team continued manually verifying an automated provisioning job despite its apparent reliability, and their caution proved justified. Two years earlier, the job had silently skipped a step while still reporting success, because it checked whether its request was accepted rather than whether the intended change had actually occurred. The gap went undetected for weeks until an engineer noticed a group had no members. In response, the team redesigned all jobs to log before-and-after state changes, revealing that around four percent of runs were silently skipping steps by design. A daily reconciliation process now flags drift between intended and actual system state, and a named owner has been assigned to formally retire the manual check once trust in the automation is established.