Autopilot · 27 August 2026
Automated validation for network changes
Why 'the change went in cleanly' is not evidence, and how to build automated before/after validation that makes network changes boring.
Most network incidents are not caused by features that never worked. They are caused by changes that looked fine at the moment of deployment and broke something else later. The gap is validation: we tend to prove that a change applied, not that the network still works.
Proof of application is not proof of correctness
Configuration management tools are good at telling you a device accepted the configuration. They are not good at telling you:
- whether the routing table now matches intent,
- whether an underlay path still carries the right traffic class,
- whether the change introduced a subtle asymmetry,
- whether the service actually responds the way it did before.
That evidence has to be collected deliberately.
Build a pre/post validation harness
A practical pattern is a harness that runs the same checks before and after any change, and fails the change if the “after” state regresses:
- Intent checks. Rendering and asserting intent (addresses, adjacencies, VLANs, routing) against the device.
- Path checks. Traceroute or packet-walk tests between representative endpoints.
- Service checks. Real probes against the services the network carries.
- Protocol health. BGP/OSPF/EVPN state, control-plane counters, and route counts.
- Fabric health. PFC/ECN/queue counters for lossless fabrics.
Run them as code, store the results, and diff them. The diff is the deliverable.
Make it boring on purpose
The goal is not a clever pipeline. It is change that is boring because it is proven. That means:
- The same harness runs in a lab and in production.
- Validation is a gate, not a report nobody reads.
- Results are durable, so you can answer “what changed?” months later.
Where automation actually pays
Automation pays when it encodes engineering judgement, not when it types commands faster. The value is in the assertions — the things you decide a healthy network must satisfy — and in the discipline of running them every time.
Do that, and the phrase “it should be fine” disappears from your change reviews. You either have the evidence or you do not, and the harness tells you which.