Most network automation workflows are very detailed until they reach production.
There is usually a configuration, some pre-checks that are run, how the change is deployed to the network, and then some technical post checks. There’s one last box though and it usually says something like:
“Application team validates”
There is a lot of work in those three words.
Application teams should contribute to validation. The problem is that this box often means the network workflow has ended and the outcome has been handed to another team during the change window. We engineered the deployment path and left assurance as coordination.
Not every change needs an elaborate test program. It should still be clear what the change must accomplish, what has to remain true, and what evidence will demonstrate both.
A central view of the network is not intent
One of the first things engineers reach for in an automation program is centralization. I understand the instinct. Useful state is scattered across device configurations, controllers, routing, MAC and ARP tables, APIs, monitoring platforms, and whatever documentation is still accurate. Bringing it together makes a distributed system easier to understand and operate.
It can also create something we quickly start calling a source of truth.
The trouble is that an operational source of truth can be accurate and still describe a network we do not want. Old firewall rules, residual routes, stale DHCP helpers, permanent “temporary” exceptions, and orphaned objects can all be present. If discovered state becomes intended state without review, automation can preserve technical debt with impressive consistency.
Operational data is still a good starting point. A versioned snapshot can establish the cleanup baseline, but somebody has to decide what belongs in the intended state. Continuous collection should remain available for validation and drift detection, not define intent on its own.
A live network also contains learned routes, leases, sessions, and neighbor state that do not belong in a deployment model. The useful comparison is not field-for-field equality. It is whether the functioning network conforms to what the organization decided must be true.
Deployment answers a narrow question
A green deployment proves several important things. The configuration rendered, the checks passed, the diff looked right, and the devices or controller accepted it.
That is real engineering work. It is also a narrow definition of success.
A routing policy can deploy cleanly while selecting the wrong path. An old firewall rule or residual route can leave a way around a segmentation boundary. A stale helper can preserve a dependency the cleanup was supposed to remove. A successful push does not prove the forwarding, security, or application outcome is correct.
This is related to why I separate deterministic automation from AI-assisted engineering. The production workflow needs repeatable controls and evidence that outlive the conversation that produced the change, regardless of who or what drafted it. I wrote more about that in AI-Assisted Network Engineering Is Not Network Automation.
The change should say what it has to prove
For a higher-risk change, the workflow should carry more than configuration. It should state the intended outcome, preserve pre-change evidence, identify what must change and remain stable, and define the conditions for acceptance, investigation, continued observation, or rollback.
Where tooling allows, the proposed configuration should be evaluated before deployment. Afterward, the workflow should collect fresh network state, run path or policy checks, consume application-owned health signals, and store the result. Drift checks can determine whether the validated condition continues to hold.
The depth should be proportional to risk. Changing an interface description is not the same as removing a firewall rule from a segmentation boundary. Validation should be designed before production becomes the place where everyone figures out what should have been tested.
Application validation matters, but it should not automatically mean asking an application engineer to click around. Application teams already own some definition of health: service checks, synthetic transactions, availability, error rates, latency, or dependency health. A usable platform path would expose those signals to the workflow without making either team recreate the other’s expertise.
That turns a handoff into evidence.
What deeper network modeling can add
This is where a model built from configuration and live network state becomes especially useful.
The capability I care about is not another configuration backup or discovered topology. It is the ability to collect configuration and operational state, reason across routing and forwarding decisions, and derive the path traffic should take. Device tables, interfaces, adjacencies, forwarding information, and policy all contribute to that answer.
A synthetic test can tell us that a source reached a destination. A useful network model may also show which route won, where policy was applied, and whether another path could avoid the expected enforcement point. It can ask the question against proposed state before a change and newly collected production state afterward.
This is the tool I wish I had during command-center-style operations. Monitoring told us something changed. The expensive part was reconstructing the path and finding which table, policy, or dependency made it possible.
A model is not an oracle. Its answer depends on data freshness, platform coverage, model fidelity, and assumptions. It does not replace application observability or production tests. The model can provide deeper validation, but production still has to answer for what happened.
The same requirement, tested from both sides
A commercial product isn’t required. The minimum useful pattern is to express the requirement in a testable form and evaluate it before and after deployment, even when different tools provide the evidence.
For a segmentation change, the requirement might be:
- Traffic between these zones must traverse the designated enforcement point.
- No alternate routed or permitted path may bypass that boundary.
- The approved application transaction must continue to succeed.
Before deployment, a model, lab, dry run, or differential analysis can test the proposal. After deployment, fresh tables, APIs, path tests, synthetic transactions, and application health signals can test production. The implementations can differ. They need to evaluate the same intended behavior.
Julio PDX’s 2021 network CI/CD series is a useful example. Batfish and a NAPALM dry run covered pre-change work, while SuzieQ supplied operational state for post-change testing. I have not followed the open-source landscape closely enough to prescribe that exact 2021 stack in 2026 but the durable part is the workflow: model, deploy, collect, and test.
The workflow will reflect the organization
No team can manufacture every piece of cross-domain evidence. The organization still owns whether the full service works, while each team owns the signals and capabilities its domain contributes.
Chris Grundemann’s article on intelligent network organizations applies Conway’s Law to infrastructure teams and their handoffs. The same problem appears when a workflow ends with the network team deploying and the application team validating. The automation has inherited the boundary between the teams.
That does not require one giant team. Platform teams can provide paved paths. Network specialists can define path and policy assertions. Application or stream-aligned teams can publish durable service-health signals. The evidence can stay distributed by expertise while the workflow evaluates it as one change.
What happens after Deploy
A useful automation design should give the evidence path the same attention as the deployment path.
What should change? What must stay stable? Which network and application signals matter? What result should stop, investigate, or roll back the change? Will the evidence remain available afterward, or only in the memory of the people who attended?
Once those questions are answered, deployment becomes one step in a larger reconciliation loop. Without them, the automation may be excellent at changing the network and weak at telling the organization whether it should trust the result.
Application team validates is not necessarily wrong. It is just not finished enough to be the design.
References: