Recorded lab demonstration
Explore a completed investigation.
Two real investigations from SafeCadence’s 50-device lab network, step by step, with the exact commands, results and times from SafeAI’s records. One ends with a verified fix. The other ends with SafeAI escalating to people, because there was nothing it could safely fix.
Case 1 · 1 November 2026 · incident INC-1793491759245 · fix FIX-6eb5e5cc0823
A port shut by a change: found, undone with two approvals, verified.
Alert → evidence → proposed recovery → two-person approval → verification. Total: 86 seconds from the alert, including the time people took to approve.
- −5 s00:09:14
A change shuts the port
Someone shuts interface eth3 (the Dallas warehouse LAN) on router DAL-SDW. The router logs it; SafeAI records it as change CHG-DAL-SDW-1793491760, with no matching approval.
- 0 s00:09:19
1 · Alert
The monitoring tool sends its alert: Interface eth3 on DAL-SDW went down. SafeAI opens incident INC-1793491759245 by itself. Nobody has opened a ticket.
- +2.6 s00:09:21
2 · Evidence: the router is read again
SafeAI reads DAL-SDW’s configuration again and lists the possible causes from the timeline: two recent changes, unusual sign-ins, and the interface itself.
- +2.8 s00:09:22
Evidence: the fault is proven proven: port down
A read-only live check, from SafeAI’s allow-list, proves the port is down. The change that shut it is identified from the device log and the configuration difference. At this point that change is a strong lead, not yet proof that it caused the outage.
Commandvtysh -c 'show interface eth3'ResultInterface eth3 is down - +30.2 s00:09:49
Evidence: the AI explains, and SafeAI checks it
A local model (qwen2.5:14b, on the lab’s own GPU) writes five statements, each citing evidence. SafeAI checks each statement against the evidence it cites: three are supported; two are withheld (see below).
- +30.2 s00:09:49
3 · Proposed recovery: the undo is checked
SafeAI builds the undo of CHG-DAL-SDW-1793491760 and checks five conditions: a clear outcome, no risk to access, an approved scope, a tested rollback and a way to check the service. All five hold, so the undo is offered.
Commandinterface eth3
no shutdown
exitResultRollback, if the service isn’t back: interface eth3 / shutdown / exit - +54 s00:10:13
An engineer proposes the undo
Engineer A (a lab test account) reviews the exact plan and proposes it. The plan is fixed by its fingerprint, 9de467c6…; changing a single line would need a new approval.
- +71 s00:10:30
4 · Two-person approval
Engineer B, a different person, approves the exact plan. SafeCadence Hold Point records the decision (approval 93a4a405…, receipt ca5a1231…) and opens a short change window. Engineer A could not have approved it.
- +81 s00:10:40
5 · Verification service back
SafeAI applies the undo, reads the router again and re-tests the original problem. The port is up and the configuration matches its state before the change. Now the change is proven as the cause: undoing it restored the service.
Commandvtysh -c 'show interface eth3'ResultInterface eth3 is up, line protocol is up - +86 s00:10:45
Fix closed
SafeAI closes the fix as verified, 15 seconds after the second approval. Every step above is in the incident’s signed record.
What the AI said, and what SafeAI let through
The model’s answer is treated as a draft. A statement is shown only if the evidence it cites supports it. When this was recorded, SafeAI 2.9.8 only checked that each citation existed, and showed the answer as “5 of 5 statements cite evidence”. Checked with SafeAI 2.9.9’s rules, two of those statements are withheld:
3 supported
At 2026-11-01T00:09:19Z, the interface eth3 on DAL-SDW went down.
Cites E1 · the incidentSafeAI proved that the interface eth3 on DAL-SDW is down.
Cites E6 · SafeAI’s live checkChanges CHG-DAL-SDW-1793491760, …1388, …1131 and …3268 were made outside normal working hours and are considered unusual.
Cites E19, E22, E25, E26 · unusual activity2 withheld
Change CHG-DAL-SDW-1793491760, made at 2026-11-01T00:09:14Z, introduced the problem that eth3 has an address but is down.
Change CHG-DAL-SDW-1793491467, made between 00:04:19Z and 00:04:26Z, reversed the lines introduced by CHG-DAL-SDW-1793491760.
Case 2 · 28 October 2026 · incident INC-1793149973749
A server that wouldn’t answer: no change to blame, so no fix offered.
SafeAI only offers to undo a change it can tie to the problem. Here every network cause it could test was ruled out, so it stopped and handed over to people.
- 0 s01:12:40
1 · Problem reported
An engineer reports that branch 4 can’t reach its local server, 10.4.0.10, and opens an incident. SafeAI lists three possible causes: no route, the interface toward the server is down, or the server itself doesn’t answer.
- +24 s01:13:04
2 · Evidence: is there a route? ruled out
Ruled out: the branch router has a route to the server’s network.
Commandshow ip route 10.4.0.10ResultRouting entry for 10.4.0.0/24 - +40 s01:13:20
Evidence: does the server answer? proven: no reply
Proven: the router can’t reach the server. This confirms the problem but doesn’t explain it.
Commandping 10.4.0.10ResultSuccess rate is 0 percent (0/5) - +46 s01:13:26
Evidence: is the interface up? ruled out
Ruled out: the interface toward the server is up.
Commandshow interfaces GigabitEthernet0/0ResultGigabitEthernet0/0 is up, line protocol is up 3 · No fix offered: SafeAI escalates escalated to people
No change on the router explains the problem, so there is nothing SafeAI can safely undo, and it offers no fix. The incident shows what was proven and what was ruled out, and the handoff note for the next team points them to the server and the LAN behind GigabitEthernet0/0.
- +72 s01:13:52
Afterwards
A later ping got an answer: the server came back on its own. SafeAI recorded that result but did not claim a cause or a fix. The cause was never established.
See it for yourself
Try the live demo. No sign-up.
It’s our 50-device test network, refreshed every night. Or talk to us about yours.