What changed, and why did it break?
An incident is understood when its cause is traced to the change or condition behind it, with the affected devices and paths, not when service comes back.
Incident ReasoningCategory guide
What is network assurance?
A guide to the category: the 3 questions it answers, why it matters now, how it works with monitoring, observability, AIOps and automation, a 5-stage maturity model and how to start.
Definition
Network assurance, in one sentence
Network assurance is the practice of proving, with evidence, that a network’s incidents are understood, that its changes worked and that its failover will work.
It is the assurance layer above monitoring, observability, AIOps and network automation. It works with all of them and replaces none. Monitoring says something is wrong. Automation makes a change the same way every time. Network assurance answers the question that follows each: do we know why, and can we prove it?
Evidence means something specific here: the command output, log line, configuration diff, path trace or ticket text a conclusion rests on, with a timestamp, one click from the conclusion. A confident sentence is not evidence. Neither is a green dashboard.
In this guide, “assurance” means proof about 3 things: incidents, changes and redundancy. The practice rests on 3 sentences:
- Restored is not the same as fixed. An incident closed without a verified root cause will recur.
- Completed is not the same as verified. A change marked successful because nobody complained is a risk that has not surfaced yet.
- Configured is not the same as compliant. A device that matches its intended configuration can still violate the policy it is meant to enforce, and redundancy that has never been tested is not redundancy.
Restored ≠ Fixed: REAP in 90 seconds
Read the video as text
0:00–0:08 21:14. A change goes in. Closed “successful.” CHG-1234 edits object group OG-ERP on plant-a-core-2. Closed at 21:20. No post-check.
0:08–0:16 21:16. The ERP path fails. Nothing alarms. ACL-ERP-IN matched OG-ERP. ERP return traffic now hits the final deny. Link and OSPF stay up.
0:16–0:24 02:07. P1. Plant A can’t enter orders. The night-shift help desk opens INC0451. Undetected for 4 h 51 min.
0:24–0:33 Every incident starts from zero. Six tools. Three teams. The answer is in there, spread across all of them. Engineers spend 37% of their time addressing disruptions.
0:33–0:42 REAP observes. Read-only. Config history, ACL counters, routing and the change ticket, gathered into one investigation.
0:42–0:52 It reasons with evidence, one step at a time. What changed, why it broke, what is affected. Each line traces to its source.
0:52–1:00 It recommends an approved runbook. A person decides. Restore OG-ERP to its 21:13 members with RB-07. Awaiting approval. Approval-gated runbooks: pilot deliverable today.
1:00–1:10 Before and after. A verdict, in the ticket. ERP path re-tested after RB-07: Verified. CHG-1234 recorded as Rolled back, with evidence. Before-and-after verification: pilot deliverable today · automated verdicts: in development.
1:10–1:18 Start through one door. Incident Reasoning. Change Assurance. Resilience Assurance. Expand only when you pull.
1:18–1:24 Restored ≠ Fixed. Completed is not the same as verified. Configured is not the same as compliant.
End card, 1:24–1:30 REAP · Observe · Reason · Act · Prove Agentic Network Assurance. Grounded in Evidence. Bring us your last P1 · reapnet.ai
Illustrative, on a fictional network. · Source: New Relic (opens in a new tab), 2026 Observability Forecast (opens in a new tab)
The 3 questions
What network assurance answers
Every network team is asked these questions, usually after something has gone wrong. Network assurance answers them before and after, with the evidence attached.
Did the change work?
A change is verified when state before and after has been compared against its intent and one outcome is recorded: Verified, Degraded, Rolled back, Inconclusive or Blocked.
Change AssuranceWill failover work?
Redundancy is proven when the standby is in sync, its configuration has not drifted and the backup path can carry the load, before the failure that tests it.
Resilience AssuranceWhy now
4 pressures that make assumption expensive
Monitoring, AIOps and automation made restoration faster: alarms are correlated, on-call is paged in seconds, failover and reboots are scripted. Explanation was left to people. That gap is getting expensive, for 4 reasons.
More change. Firmware and security updates, cloud network constructs, migrations and acquisitions all arrive as changes, and any change can fail silently: the link stays up, nothing alarms, and the symptom appears hours later in a ticket nobody connects to it. In REAP’s discovery conversations, a change was the most common explanation for a P1.
More vendors. When an estate spans several network vendors, cloud network constructs and wireless controllers, the evidence for one incident is spread across all of them, and each vendor’s tools see only their own devices.
Lean teams. Engineers spend 37% of their time addressing disruptions, and a high-impact outage takes an average of 41 minutes to detect and 54 minutes to resolve (New Relic (opens in a new tab), 2026 Observability Forecast (opens in a new tab)). The same survey puts the mean cost of a high-impact outage at $1.85M per hour, or $30,833 per minute. In Uptime Institute (opens in a new tab)’s Annual Outage Analysis 2026 (opens in a new tab), 57% said their most recent major outage cost more than $100,000; one in five, more than $1 million. A lean team pays twice: in the outage, and in the senior-engineer days it takes to explain it afterward.
AI agents entering operations. Automation, AI assistants and agents already change networks: your vendors’, attackers’ and your own. Governance built for human change velocity does not scale to hundreds of automated identities. The 2026 autonomous-agent incidents, summarized with their primary sources in Incidents nobody planned for, ran through network paths: server-side request forgery, edited hosts files, spoofed hostnames and reused credentials. The question for every network team is how fast an unauthorized change is noticed, explained and reversed.
How it differs
Network assurance and the tools around it
Each category does a real job. None of them, on its own, proves what changed, whether a change worked or whether failover will work. The comparison is by category; individual products vary.
| Category | What it answers | What it needs | Where it stops |
|---|---|---|---|
| Monitoring | Is it up? Did a metric cross a threshold? | Polling, traps, probes and the thresholds someone configured | At the alarm. It reports a symptom; a change that breaks a path while every link stays up may raise nothing. |
| Observability | What is the system doing, and where is it slow or failing? | Rich telemetry (metrics, logs, traces or flows) and a place to query it | At the description. Relating behavior to a specific configuration change, topology path and change record is usually left to an engineer. |
| AIOps | Which events belong together, and which matter most? | Event streams from many tools, and history to learn patterns from | At correlation and recommendation. An investigation that decides what evidence to gather next is typically left to a person. |
| Network automation | How do we make this change the same way every time? | Templates, playbooks, a source of truth and write credentials | At execution. It reports that the steps ran, not that the network is healthy afterward, and it handles only the cases it was written for. |
| Vendor AI assistants | What is happening on this vendor’s devices? | That vendor’s controller or management plane | At the vendor boundary. An incident that crosses vendors, or follows a change made in another tool, is outside its view. |
| Network assurance | What changed? Did it work? Will failover work? With evidence. | Read access to all of the above: configurations, state, topology, telemetry, tickets and change records, plus the team’s runbooks and conventions | At governance. It explains, verifies and recommends; any action runs under the operator’s approval, and it replaces none of the tools above. |
Works with, replaces none
Where network assurance fits
Network assurance sits above the tools a team already runs. It reads from them and writes evidence back.
- Monitoring and observability raise the incident and hold the telemetry. Network assurance explains the incident with evidence and writes the explanation back to the ticket.
- AIOps groups and ranks events. Its output becomes one input to an investigation that decides what to examine next.
- Network automation executes the change. Network assurance assesses the change before it runs and compares state after it lands, for changes made anywhere: through automation, by hand, by a vendor or in an emergency.
- ITSM tracks the work. Incident, problem and change records stay the system of record, with the evidence attached.
In REAP today, incidents your monitoring raises reach REAP through ServiceNow (opens in a new tab) or Jira (opens in a new tab), and REAP writes its findings and evidence links back to the ticket. Direct correlation and prioritization of third-party alert streams is In development.
Building blocks
5 building blocks of network assurance
Use them to test any approach, including ours. Each one notes where REAP stands in the September 2026 release.
Context
Read-only access to the places that explain a network: configurations and state, topology, telemetry, tickets, change history, runbooks and design documents, across every vendor in scope. Without context, every answer is a guess. In REAP: the topology-aware assistant and path trace forward, in reverse and at a past point in time are Available.
Reasoning with evidence
An investigation that forms a hypothesis, gathers the next piece of evidence, tests it and changes course, with every conclusion linked to what it rests on. When the evidence is thin, it says so and names the next diagnostic step. In REAP: the Investigation Window and qualified incidents from REAP-collected telemetry are Available.
Verification
Changes assessed before they run and compared after they land, each with one recorded outcome; redundancy checked for readiness rather than assumed. In REAP: change impact analysis and posture findings (active/standby sync, running/startup drift, contextual CVE (opens in a new tab) exposure) are Available; before-and-after verification is a Pilot deliverable; continuous failover-readiness proof is In development.
Governance
Read-only by default, least-privilege credentials, approval before any write, an execution record for every action, and autonomy expanded per workflow only as it is earned. In REAP: approval-gated remediation runbooks are a Pilot deliverable, and autonomous execution without approval is Not offered.
Measurement
A baseline first, then time to answer as P50 and P95, diagnosis quality, human effort and prevention, measured on your network. In REAP: every proof of value measures 8 categories against your baseline, and REAP’s performance figures are design targets from REAP’s reference architecture until your pilot measures them.
Maturity model
5 stages of network assurance
Place your team by the evidence it can show today, not by the tools it owns.
| Stage | What it looks like | Evidence you can show | Next move |
|---|---|---|---|
| 1 · Reactive | Service is restored by heroics. Root causes are rarely written down, changes close as “completed” when nobody complains, and failover is assumed. | A ticket that says “resolved”. | Measure a baseline: time to detect, time to an evidence-backed root cause, repeat rate. Explain one past incident with evidence. |
| 2 · Managed | Processes exist: RCA for P1s, often weeks later; checklists and spot checks for changes; failover tested at commissioning or once a year. Evidence is gathered by hand. | RCA documents, change checklists and test reports that age. | Take the door that costs the most and run it, measured, on one domain for 45 days. |
| 3 · Assured | For the critical estate, incidents are explained with evidence and changes are verified before and after. Standby sync and drift are checked. | Root cause with evidence in the incident record for P1s and P2s; before-and-after evidence in the change record for major changes. | Prove resilience and posture on a cadence, not only after an incident, and extend verification beyond the critical estate. |
| 4 · Proven | Resilience and control are demonstrated with evidence on demand. Time to answer is tracked as P50 and P95, and repeat incidents are falling. | Evidence an auditor, an insurer or a board can read without a scramble of screenshots. | Make it continuous across the estate, and let agents earn bounded autonomy one workflow at a time. |
| 5 · Continuous | Assurance runs all the time, not per event. Every change closes with an outcome, every redundant pair and backup path is proven again as the network changes, and each workflow runs at the autonomy it has earned, with approval gates where the team keeps them. | The current state of every change, pair and path, with its evidence, at any moment. | Keep measuring. Autonomy is reviewed per workflow, never granted once. |
Find your stage in 10 minutes. The Network Assurance Self-Assessment places a team in stages 1 to 4 from 20 rubric-scored questions across Observe, Reason, Act and Govern & Prove: Reactive (under 35%), Managed (35–59%), Assured (60–79%) or Proven (80% and above), with your 3 largest gaps and a recommended first door. Stage 5 is not scored. Parts of it depend on capabilities REAP is still building: automated verdicts on every change, continuous failover-readiness proof and evidence packages for audit scope are In development, and autonomous execution without approval is Not offered.
How to evaluate
Test it on your network, not on a demo
An agent that is wrong can escalate the wrong team, close the wrong ticket or, if it is allowed to act, change a production device. A fluent explanation of the wrong root cause is worse than none, because it is believed. So evaluate network assurance on your own incidents, against your own baseline, and treat governance as a feature rather than paperwork.
Use 2 vendor-neutral tools, whether or not you buy REAP:
- The buyer’s evaluation guide: 10 questions every vendor should answer, 26 criteria with a 45-day test for each, how to read the economics honestly and the red flags.
- The RFP template and evaluation kit: a Word template and an Excel requirements matrix with 120 requirements, weights, must-have gates and a 45-day test plan.
The tests that separate proof from presentation are simple. Trace a conclusion to its evidence, live. Verify a change the platform did not execute. Ask for time to answer as P50 and P95, measured on pilots; a single demo timing is a red flag.
How to start
One domain, one door, 45 days
Start where the cost is, prove it on your own network and decide on a date you set.
Pick one domain
One production domain: a plant group, a region, a campus or one customer network, typically 50–250 devices on 2 or 3 vendors from REAP’s supported list, with the ITSM, one telemetry source and configuration access.
Pick one door
Incidents that take too long to explain, changes that “worked” but did not, or redundancy you cannot prove. The self-assessment recommends a first door from your lowest-scoring area.
Measure a baseline
Week 0: baseline worksheet, success scorecard, security packet and week-0 data request. Without a baseline, every claim, yours and the vendor’s, is an opinion.
Gather the evidence
Weeks 1–4: connect and discover; replay 5–10 incidents whose root cause you know and REAP doesn’t; review findings in week 3; compare one real change window before and after; put runbooks under approval. Week 5: before and after on 8 measures.
Decide
Week 6: a business review that ends in BUY, EXTEND or STOP. A paid proof of value is credited in full against the first annual subscription when the order is signed within 30 days of the business review.
Questions
Network assurance: straight answers
Is network assurance the same as network monitoring?
No. Monitoring tells you that something went down or crossed a threshold. Network assurance proves why it happened, whether a change did what it was meant to do and whether redundancy will hold. It depends on monitoring and replaces none of it.
How is network assurance different from AIOps?
AIOps groups and ranks events across tools. Network assurance runs the investigation that follows: it decides what evidence to gather next, links each conclusion to that evidence and checks changes before and after. AIOps output can be one of its inputs.
Does network assurance require AI?
The discipline does not. Pre-state, intent, diff, outcome and ticket can be checked by hand, and careful engineers already do it for risky changes. REAP does use AI: it is built on a commercial large language model (the provider and the model-endpoint options are named in the security packet) and it runs the loop at any hour, with the evidence recorded. In REAP today, the Investigation Window is Available and before-and-after verification is a Pilot deliverable; REAP is read-only by default and acts only under your governance.
What counts as evidence?
Command output, log lines, configuration diffs, path traces and ticket text, each with a timestamp and linked from the conclusion it supports. A confidence score with no link to its sources does not count. When the evidence is insufficient, the right answer says so and names the next diagnostic step.
What outcome should a verified change have?
One of 5: Verified, Degraded, Rolled back, Inconclusive (baseline or post-change evidence missing, with what would close the gap) or Blocked. “Completed” is a workflow state, not an outcome. In REAP today, one real change window is verified before and after in every pilot (Pilot deliverable); automated verdicts are In development.
Is network assurance only for large enterprises?
No, but how you start depends on who runs the network. Enterprises run it across business units, change control and audit. Mid-sized companies run it with 3 to 10 network engineers and no 24x7 NOC. Smaller businesses rarely run their own networks, so REAP reaches them through the MSPs that do.
How do we start?
Start small. Bring us your last P1: describe an incident you already solved, keep the root cause to yourself, and in a 30-minute session we walk through how REAP would have investigated it, evidence first; the replay on your own network happens inside the proof of value. Or scope a 45-day proof of value on one production domain, measured against your baseline.
Glossary
Related terms in the glossary
Restored ≠ FixedCompleted ≠ VerifiedWhat changedEvidence traceabilityInvestigation WindowPre-execution impact analysisPost-change verificationChange verdictStandby healthFailover readinessConfiguration driftContextual CVE exposureAutonomy modesApproval gateP50 / P95Repeat incidentAIOpsNetwork automationMaturity stageProof of value (PoV)
Sources
- New Relic, 2026 Observability Forecast, press release of September 22, 2026: mean cost of a high-impact outage $1.85M per hour ($30,833 per minute); average 41 minutes to detect and 54 minutes to resolve a high-impact outage; engineers spend 37% of their time addressing disruptions. https://secure.businesswire.com/news/home/20260922268747/en/New-Relic-Report-Finds-High-Impact-IT-Outages-Drain-$74-Million-Annually-from-Businesses (opens in a new tab)
- Uptime Institute, Annual Outage Analysis 2026: 57% said their most recent major outage cost more than $100,000; one in five, more than $1 million. https://uptimeinstitute.com/resources/research-and-reports/annual-outages-analysis-2026 (opens in a new tab)
Find your stage. Then prove the next one.
The self-assessment takes 10 minutes and returns a stage, your 3 largest gaps and a first door. A 45-day proof of value shows the next stage on your own network.