A day with REAP
Observe · Reason · Act · Prove, hour by hour
One illustrative day on a fictional network, across the NOC analyst, the network engineer, the change manager and the network leader. Each moment carries its status in the September 2026 release: what runs today, what a pilot delivers and what is not built yet.
The loop
One loop, 4 roles
REAP runs one loop on top of the tools you already own: Observe the network read-only, Reason over live evidence, Act under your governance and Prove the outcome before and after, with governance across all four. The loop is the same at every size; who touches it, and when, is what changes.
The day
A composite day on a 3-plant network
Illustrative, on a fictional network. Times show when people act, not measured performance.
- 07:45
Observe · Posture findings reviewed
The engineer opens the posture findings for the plant domain. The standby unit of the Plant A VPN firewall pair has not synchronized with the active unit since Tuesday; 2 access switches at Plant C show running-versus-startup drift; one CVE (opens in a new tab) applies to the edge routers because of a feature they run. Each finding carries severity, evidence and the vendor-specific fix.
- 09:30
Reason · A question to the topology-aware assistant
“What changed on the path from Plant B’s MES VLAN to the ERP servers since yesterday?” The assistant traces the path forward and in reverse, now and at 09:30 yesterday, and answers from configuration history: an OSPF cost raised on plant-b-dist-1 at 18:40 moved return traffic to dist-2. The diff and the trace outputs sit under the answer.
- 11:00
Reason · Impact analysis for tonight’s change
CHG-2107 moves the Plant B guest VLAN to a new subnet at 22:00. Before the CAB meets, the proposed configuration is assessed against topology, reachability, security policy and known CVEs. One new firewall rule would let the guest subnet reach the management network, and the path trace shows how. The engineer narrows the rule, the reassessment is clean, and the CAB approves.
- 14:10
Observe · A qualified incident with a first analysis
A deterministic condition on REAP-collected telemetry fires: the OSPF adjacency between plant-c-core-1 and plant-c-dist-1 left FULL at 14:02 and has not re-formed. REAP raises a qualified incident with a first analysis attached, and a summary reaches the analyst in Microsoft Teams (opens in a new tab). Alerts from other monitoring tools are not correlated by REAP yet (In development); their incidents arrive through ServiceNow (opens in a new tab) or Jira (opens in a new tab).
- 14:25
Reason · The Investigation Window
What changed: at 14:02, storage change CHG-2110 raised the MTU on plant-c-core-1 Te1/1/1 from 1500 to 9198 and bounced the interface; dist-1 still runs 1500. Why it broke: the neighbors re-formed with mismatched MTUs and stall in EXSTART. Impact: Plant C reaches the core only through dist-2, so traffic flows but redundancy is gone. Next best action: restore 1500 with runbook RB-14 and re-plan CHG-2110. Each answer is one click from its evidence.
- 14:40
Act · An approval-gated remediation runbook
The engineer approves RB-14. It runs behind a confirmation, the execution record logs the device output, and the adjacency is FULL again at 14:41. The incident stays open until the storage team re-plans CHG-2110: restored is not the same as fixed. Automatic rollback is In development.
- 16:00
Act · A diagnostic runbook at tier 1
A user at the Dayton branch reports slow file transfers. The analyst runs the branch WAN health runbook, compiled from the team’s own procedure: read-only checks of interface errors, BGP state and QoS drops on both WAN edges. The execution record shows drops in the bulk class during a backup job, so the ticket goes to the backup owner, not a senior engineer.
- 22:00
Prove · The change window, compared before and after
Before CHG-2107 starts, a snapshot of configuration and state is taken, with path traces for the paths it touches. After the window, the configuration is compared with the snapshot, and the traces and posture checks, including active/standby sync, run again. Outcome: Verified, recorded with the evidence in the change ticket. In a pilot today, one real change window is verified this way with your team; automated state packs, verdicts and silent-failure detection are In development.
- Friday
Prove · Findings reviewed with the architect
The network leader and the architect go through the week’s findings: the Plant A pair, resynchronized and checked again; the drift, saved; the CVE (opens in a new tab), scheduled for next month’s window; the MTU incident, closed with its cause. Backup-path capacity is In development; in a pilot it is delivered as a finding where interface telemetry is available.
Not in this day. Correlation and prioritization of third-party alert streams, automated verdicts on every change and continuous failover-readiness proof are In development. Autonomous execution without approval is Not offered: the only write REAP made in this day ran inside an approved runbook, behind a confirmation.
At your size
The same day, 3 ways
- Enterprises run this day business unit by business unit, with the change advisory board and the auditors reading the same evidence.
- Mid-sized companies run it with 3 to 10 engineers and no 24x7 NOC; the analyst and the engineer may be the same person.
- MSPs run it across customer estates from one console, and the smaller businesses they serve get an explanation with the evidence, not just “resolved”.
See this day on a network like yours.
A 20-minute walk-through on our lab network, then a proof of value scoped to one domain of yours.