Change Assurance
Most changes are marked successful because nobody complained. REAP assesses a change before execution and compares configuration and state before and after it, for changes made anywhere, and records the evidence in the change ticket. Automated verdicts and silent-failure detection are In development; in a pilot, one real change window is verified with your team.
The buyer’s question
The most dangerous moment in a network change is when everyone thinks it worked. Failures to follow established procedures remain the leading driver of human-error outages (Uptime Institute (opens in a new tab), 2026). In our discovery conversations, change was the most common explanation for a P1, and change failures often surfaced the next morning, when customers could not connect. Start before your next migration wave, upgrade cycle or audit.
Before the window: a snapshot of configuration and state (routing, MAC and ACL tables), forward and reverse path traces for the paths the change touches, and the proposed change assessed against current topology, reachability, security policy and known CVEs. After the window: the configuration diff against that snapshot, the same path traces re-run and the posture checks re-run, including active/standby sync. The outcome and the evidence go into your change ticket.
Pre/post state captured automatically for every change window, silent-failure detection and an outcome written to the change record. Built with design partners; see product status.
For teams with a high change volume and a named change owner: early access and a say in the verification contract, in exchange for one change window a month and structured feedback.
Ask for a seatWhat you get
Verified, Degraded, Rolled back or Inconclusive, with the diff and the evidence, in ServiceNow (opens in a new tab) or Jira (opens in a new tab).
A proposed change that would collapse redundancy or open a policy path is flagged with reasons before approval.
Which incident classes in a year of your tickets followed a change, how often, and how long each took to resolve.
Intent, pre-state, diff, evidence and approver recorded for each verified window.
Evidence shown
In week 4 of a pilot, one real change window executed by your own team is verified before and after; the outcome and the evidence go into your change ticket.
Intent and rollback trigger
Upgrade nyc2-core-1/2 from 17.9.5 to 17.12.4, one core at a time; no loss of HSRP redundancy beyond one planned flip per core; no configuration change other than the release. Roll back if probes fall below 46/48 or both cores sit in Standby for more than 30 s.
What actually changed
Both cores upgraded. On core-2 only, ip helper-address 10.9.0.20 is missing under Vlan220 (present on core-1); the device archive log attributes the removal to the upgrade account at 03:12:44.
Outcome
Degraded The upgrade completed and reachability held, but one unintended regression remains: DHCP relay for guest VLAN 220 would fail on the next core-1 failover. Rollback trigger not met; remediation pending.
Next best action
Restore the helper address on core-2 (runbook RB-12, awaiting approval); re-verify; run the delayed post-check at T+30 min; close CHG-2041 with the evidence attached.
Evidence
How a pilot measures it
| Measure | Default target (agreed per pilot) | Source |
|---|---|---|
| Automation & change verification | 1 real change verified pre/post with a recorded outcome · 2–3 runbooks live under approval · 0 unapproved actions | Automation & Change Report |
| Prevention | Change-caused incident classes identified from a year of tickets | Findings Report |
| Human effort | Change pre-check and verification minutes before vs. with REAP | Baseline vs. pilot log |
Related
Find where redundancy will not hold.
Learn moreRaja Tadimeti, August 2026.
Learn moreWeek-by-week plan and the eight measures.
Learn moreOne production domain, your baseline in week 0, a decision in week 6.