Post-Implementation Verification (PIV)
Concept
Post-Implementation Verification is the set of automated checks that run immediately after a change is deployed, to confirm it actually achieved its intended effect — as opposed to merely confirming the deploy mechanism itself exited without error. The distinction matters because a deploy command returning success only tells you the action was applied, not that the system is now in the desired state: a network device can accept a configuration push and report success while the interface it configured stays down, a service can restart cleanly and still fail every real request, an upgrade can apply and still leave the underlying capability broken.
The term originates in network engineering and change-management practice (ITIL calls the broader review step a "post-implementation review"), but the underlying idea is identical to what CI/CD calls a smoke test: run a narrow, fast, automated check against real outcomes right after the change lands, before the change is considered complete. Concrete PIV checks in a network-automation context include reading back the actual device configuration and diffing it against the intended state, measuring traffic through the reconfigured path against an expected range, checking for new error conditions in the device's own state, and verifying neighbor/connectivity relationships came back up — checks aimed at "does this work," not "did the command run."
Tradeoffs
| Approach | Benefit | Cost |
|---|---|---|
| No PIV (deploy success = done) | Fastest, simplest pipeline | A bad change looks identical to a good one until a user or a downstream system reports the failure — often much later, with a much larger blast radius by the time it's noticed |
| PIV as a status check (runs, reports pass/fail, no automated action on failure) | Catches the problem sooner than "wait for a user report" | Still relies on a human noticing the failed status and acting on it — if no one is watching the dashboard at that moment, a failed PIV is functionally the same as no PIV at all |
| PIV wired to automatic action (halt further rollout, alert on-call, or trigger rollback on failure) | Failure is caught and acted on within the deploy window itself, before the blast radius grows (especially critical in a staged/fleet-wide rollout, where halting stops the next batch from also failing) | Requires PIV checks to be trustworthy enough to act on autonomously — a false-positive-prone check now halts or rolls back good deploys, which trains teams to distrust and eventually ignore the gate |
The middle tier — PIV that runs and reports but doesn't do anything on failure — is a common trap: it looks like verification exists, but if failure is just another line of pipeline output, it delivers none of the safety of the third tier while still paying the engineering cost of writing the checks.
When to use / when not to
- Run PIV immediately after every deployment, automatically, as a required gate in the pipeline — not as an optional or manually-triggered step someone has to remember to run.
- Wire PIV failure to a concrete next action appropriate to the blast radius: halt the rollout to the remaining fleet, alert on-call with the specific failure, or trigger an automatic rollback — the value of PIV is almost entirely in what happens after it fails, not in the check itself.
- Check outcomes that reflect real functionality (does the reconfigured path actually pass traffic, does the neighbor relationship establish), not just deploy-mechanism success (did the push command return 0) — a check that only re-validates the mechanism that already reported success adds no new information.
- At fleet scale (many devices, many changes per deploy), plan for PIV output itself becoming a data-volume problem — diffing raw output against expected state and summarizing only what changed matters as much as the checks themselves, or the volume of PIV output becomes its own thing nobody actually reads.
- Less critical for changes with a trivially verifiable, immediate, visible effect where a human is already watching in real time — but this is the exception, not something to assume by default.
Common pitfall
A PIV check that fails silently instead of triggering action. The failure mode isn't "we forgot to check" — it's building the check, having it correctly detect that something broke, and then having that detection go nowhere: no halt, no alert, no rollback, just a status a human was expected to notice and didn't. This is functionally worse than not having PIV at all in one specific way — it creates false confidence that the deploy is being verified, when the actual safety net is "did anyone happen to be looking." The fix isn't a better check, it's closing the loop from detection to automated response, so a PIV failure is guaranteed to produce a visible, acted-on consequence rather than an ignorable status line.
Engineering Lens
The design-review question for PIV isn't "do we verify after deploy" — most mature pipelines claim to. It's whether a PIV failure is guaranteed to produce action, or merely capable of being noticed by someone paying attention at the right moment. A pipeline that checks the right things but leaves the response to human vigilance has the appearance of a safety gate without the substance of one — and that gap is invisible until the one time no one happens to be watching when it matters. The stronger answer in review is naming exactly what happens, automatically, the moment a specific PIV check fails — not just that the check exists.
Related
- Golden Image and Immutable Infrastructure — PIV is what makes an automatic rollback to a previous golden image safe to trigger without human confirmation
- Code Review and Static Analysis in CI — the same "verify automatically, don't rely on a human noticing" principle applied before merge instead of after deploy