Outage post-event review that finds the delays behind your outage minutes, and checks the fix held
Post-event reports in hours, actions tracked to closure.
See one case, screen by screen ↓When a feeder locks out, a substation trips or a near miss happens, someone has to explain it: what happened, in what order, why restoration took as long as it did, and what will stop it happening again. The evidence sits in seven places, each with its own clock: the SCADA sequence of events at millisecond GPS time, the relay records, the outage system's calls, prediction and dispatches, smart-meter last gasps, crew van GPS, the control-room log typed during the event, and the care-team call log. Before anyone can think about causes, an operations engineer spends days lining up timestamps in a spreadsheet.
The delays that cost the most customer minutes hide in the gaps between those systems. No single system shows the 23 minutes between the first customer call and the crew dispatch: the call is in the outage system, the hold is in the control-room log, the van is in the GPS feed. And when the report is done, its actions go into another spreadsheet, closed when the work is done rather than when it is shown to work — so the same delay returns on the next event.
Estimated split of an operations engineer's working hours on one significant event, by hand and with the solution. In the working solution the timeline was built in 36 minutes and the cited draft was ready 4 h 10 min after assembly started.
Six agents merge every source onto one timeline, find the delays and draft the cited report; the review lead confirms the causes and signs.
On Friday 9 October 2026 at 18:41:52, a cable joint fails on feeder F12 out of Corran Vale primary, a 33/11 kV substation of the fictional Lumina Utilities. 6,412 customers lose power, among them 3 life-support customers, Holmewood care home and Lumina's own Tamsin Hill water booster station. Here is the review, screen by screen, in the working solution.
The event passed a trigger — more than 1,000 customers off — so PER-2026-0219 opened in the register on its own, for 6,412 customers and 273 minutes. Mara, a senior operations engineer, sees it beside the other open reviews and their clocks: PER-2026-0207 with its report due Oct 21 and two sections unsigned, Storm Ilse at sign-off with Ruth Abernathy, and her own report due Nov 8.
“41 reviews in 2026 · opened automatically when an event passes a trigger · 4 open”
The event assembler reads 11,479 records for the event window: 1,284 SCADA events, 4 relay records, 416 outage-system records, 7,921 smart-meter events, 1,744 crew GPS pings, 96 control-room log lines and 14 care-team calls, plus 9 crew job notes. It aligns every clock to SCADA GPS time: the outage system was 2 s out, the care-team log 1 min 12 s, and the control-room log, typed to the minute, is anchored to SCADA on 11 lines.
“The event assembler reads this source and never writes to it. The correction is shown on every item it moved.”
Against Lumina operating standards v7, the delay finder marks 5 decision points and measures D1, dispatch at 23 min 04 s, and D3, the life-support call-back at 37 min. The protection reviewer reads CB-12's settings against the feeder as built — reclose on, feeder 82 % cable — and flags a possible misoperation (D2). The lessons matcher finds D1 in three earlier reviews.
Lessons matcher: “D1 matches PER-2026-0088, 0131, 0177 · ACT-2026-0061 not checked”
Five lanes on one time axis: protection and SCADA, the control-room log, customer calls and meters, dispatch and crew GPS, priority customers and sites. At 18:58:40, 16 min 48 s after the trip, the rail shows the event as the control room saw it: 6,412 customers off, 189 calls, 9 alarms open, and no crew sent — van LV-214 is still on a streetlight job in Brindle, 9.4 km away. The D1 bar fills as the playhead crosses it.
Not known yet at 18:58:40: “Where on the feeder the fault is · Which crew is going, and when · Whether the 3 life-support customers are safe”
The outage system predicted the outage at CB-12 at 18:49 from 27 calls and 1,980 last gasps, but a dispatcher must confirm before a crew is raised. At 18:58 the log reads “Handover in progress, F12 dispatch with incoming shift”, and the incoming shift sent LV-214 at 19:06:14. Against the 10-minute standard, the 13 extra minutes cost 83,356 customer minutes, 13.4 % of the event.
Decision point 3: “Decision held for the incoming shift with 9 alarms open.” The delay finder names the decision, never the person.
Each delay on the timeline carries its evidence from every lane: the first call at Kellmere Road, the prediction, the log line, the dispatch. Mara adds D1 to the report. It lands in section 4, Delays and decision points, numbered with its timestamps, and the draft goes from 46 to 50 citations.
“D1 added to the report · section 4, with 4 citations”
The barrier analysis lists what should have limited the event. Failed: no auto-reclose on cable feeders (D2), crew dispatched within 10 minutes (D1), life-support call-back within 30 minutes (D3). Held: fault passage indicators found the section 13 minutes after arrival, back-feed from F9 restored 1,203 customers at 20:31, and the booster's standby generator took load in 2 min 28 s, with no water supply lost. The protection review of CB-12 goes to Dev Ramaswamy, due Feb 6, 2027, with 14 similar feeders listed.
D1 root cause, proposed at 91 %: “Dispatch depends on a manual confirm, and the handover does not carry open dispatch decisions”
Dispatch held over a shift handover also happened at Saltmarsh Way F7 in April (19 min over the 07:00 handover), Fenwick Close F2 in June (16 min) and Orrin Lane F4 in August (21 min). ACT-2026-0061, a handover checklist change, was closed in May and never checked; ACT-2026-0102, dispatcher cover at 19:00, was closed in August and failed. Mara reopens ACT-2026-0061 with an effectiveness check on the next 5 handovers with an open fault.
“Two actions were closed without a check against a later event; the delay came back after each.”
The report writer drafted the post-event report in Lumina's template — summary, network and customers, sequence of events, delays and decision points, causes, what worked, customer and safety impact, actions — with a citation on every sentence that jumps back to its moment on the timeline. Mara signs as review lead. It goes to Dev Ramaswamy for the protection section, then Callum Achebe for safety and life support, then Ruth Abernathy for the Commission.
The report writer's limit: no sentence without a citation, and the report stays draft until the review lead signs.
ACT-2026-0144: raise the dispatch automatically when the outage system predicts a lockout — Sasha Morrow, Nov 20. ACT-2026-0145: no dispatch decision carried across a handover — Ade Okonjo, Oct 30. ACT-2026-0146: auto-reclose off on F12 and the 14 feeders over 70 % cable reviewed — Dev Ramaswamy. ACT-2026-0147: life-support call-backs start on the lockout — Ines Barlow. ACT-2026-0148: joint failure analysis — Lena Varga. Each carries the check that proves it: the next 5 lockouts, the next 5 handovers with an open fault, a settings audit of the 14 feeders, the next 5 events with life-support customers, the lab report.
“Every action from every review, with its owner and the check that proves it worked”
The same lockout, seen by the five people who own its review — what the work looked like, and what it looks like now.
Six agents merge every source onto one timeline, find the delays and draft the cited report; the review lead confirms the causes and signs.
Pulls every source for the event window — trip minus 15 minutes to normal running — and puts it on one timeline: SCADA sequence of events, relay records, outage-system calls, predictions and dispatches, smart-meter events, crew GPS and notes, the control-room log and the care-team log, every clock aligned to SCADA GPS time.
Walks the merged timeline, marks every decision point, automatic or human, and measures each interval that has a Lumina standard — dispatch, call-back, switching, restoration time posted. For each breach it says what was waiting and for what, and prices the excess in customer minutes.
Reads the relay event records for every operation in the event, compares the active settings with the feeder as built — cable share, length, load — flags any operation that may be a misoperation and drafts the protection review for the engineer.
Searches all past reviews for the same delay or cause, lists the matches with their actions and whether those actions were checked, and flags any lesson that did not hold.
Drafts the post-event report in Lumina's template — summary, the network and customers, sequence of events, delays and decision points, causes, what worked, customer and safety impact, actions — every sentence cited to a moment on the timeline. Exports to Word and PDF.
Turns each confirmed cause into an action with an owner, a due date and an effectiveness check, reminds owners 5 days before the due date, and after closure watches the next events of the same kind to report whether the delay came back.
Confirms causes and signs. The agents propose; a named person decides.
Ask about a moment, a delay or an action, or say what to change. Every answer points back to the timeline.
Why did the crew take 23 minutes to be sent?
The dispatch waited for a person, then for the handover. The first call came at 18:43:10. The outage system predicted the lockout at 18:49, but dispatch needs a dispatcher to confirm. At 18:58 the log says “F12 dispatch with incoming shift”, and LV-214 was sent at 19:06:14. Against the 10-minute standard that is 13 extra minutes for 6,412 customers: 83,356 customer minutes, 13.4 % of the event.
Which other feeders still auto-reclose on mostly cable?
14 feeders over 70 % cable still have auto-reclose on. The four with the most cable: Saltmarsh Way F7 (91 %), Kellmere F3 (88 %), Corran Vale F12 (82 %) and Orrin Lane F6 (79 %). F12 changed in the 2024 Kellmere Road cable project; the setting was never reviewed. ACT-2026-0146 asks Dev Ramaswamy to review all 14 by Dec 18.
Was any life-support customer left too long?
Yes, all three. The lockout was at 18:41:52; the care team's list only reached them at 18:51 because it starts on the first customer call; the first life-support call was at 19:19, 37 minutes against Lumina's 30. All three had backup and were fine. ACT-2026-0147 moves the start to the lockout.
Draft the summary for Ruth
On 9 Oct at 18:41 a cable joint failed on Corran Vale F12; 6,412 customers lost power for up to 273 minutes, 623,014 customer minutes in all. Two things made it worse: the breaker reclosed onto the fault, and the dispatch waited 23 minutes. Five actions are with their owners. It is in the report, marked draft.
13 screens from the working solution, on its sample data. Pick one to see it large.
When a review opens, the standards the timeline is measured against, the clocks and who signs are settings, saved as a new version that applies to reviews opened from then on.
| Setting | Default | Choose from |
|---|---|---|
| A review opens when | Any one of six triggers · all six on | Each On · Off: more than 1,000 customers off (counted at the peak), any interruption over 60 minutes, a protection operation that may be a misoperation, a safety near miss, a priority site off supply, a major event day by the 2.5 beta method |
| Crew dispatched | 10 min | Minutes from the lockout or the first call, whichever is first |
| Life-support call-back | 30 min | Minutes from the outage |
| Switching instruction · restoration time posted | 15 min · 20 min | From the fault being located · from the outage |
| Report to the Commission | 30 days | Days, set by the Lumina licence condition |
| Protection review | 120 days | Days until the misoperation is decided |
| Default action due · effectiveness check | 30 days · 5 events | Days from the cause being confirmed · later events of the same kind |
| Who signs, in this order | Review lead → protection engineer → HSE advisor → Head of Network Operations | Review leads Mara Lindqvist, Hal Brennick, Nadia Fenwright (water); protection and HSE sign when their kind of delay is found |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample event (there, 13.4 % = 13 excess minutes × 6,412 customers, of 623,014 customer minutes) · “target” = the design goal, measured in the live solution · “estimated” = our estimate (the hours split) · “typical” = published figures: EIA, Electric Power Annual 2024 (about 11 hours without power per US customer); WECC 2024 Misoperations Report (41 % from incorrect settings); LBNL, LaCommare et al., Energy, 2018 (about $44B a year). Regulatory context: NERC PRC-004-5(i) (120 days to identify a misoperation, 60 days for the corrective action plan). Lumina Utilities, its network and the people named on this page are fictional — characters and sample data in the working solution.
It is the review a network operator owes after a significant interruption, a protection operation or a near miss: what happened in what order, why restoration took as long as it did, the causes, and the actions that will stop it happening again. Outage Post-Event Review builds the sequence of events from every source, finds and prices the delays, drafts the cited report and tracks the actions.
The event assembler puts SCADA, relay, outage-system, smart-meter, crew GPS and log records onto one timeline at SCADA GPS time. The delay finder measures each interval against your standards and marks the decision points; the protection reviewer checks relay operations against the feeder as built. A barrier analysis shows which barriers failed and which held, with a why chain for each delay that the review lead confirms.
By finding the delays that add customer minutes and making sure the fix works. In the sample event one held dispatch cost 83,356 customer minutes, 13.4 % of the event; the lessons matcher found the same delay three times before, after two actions closed without a check. The design target is 10–15 % fewer outage minutes on events like it.
Yes. The protection reviewer reads every relay operation in the event against the active settings and the feeder as built, flags a possible misoperation and drafts the protection review. In the sample case CB-12 reclosed onto a cable fault on a feeder that had become 82 % cable, against a policy of no auto-reclose above 70 %. The protection engineer decides, and the agent never changes a setting.
Every review carries its clocks — in the sample, 30 days to the Commission under Lumina's licence condition and 120 days for a protection review — and the register shows each one's days left. The sample draft was ready with 26 days to go. The clocks are settings, so they can follow your own regulator's rules.
No. The delay finder describes the decision and the system, never the person: “dispatch was carried into the handover”, with the cause found in a manual confirm step and a handover checklist that does not list open dispatch decisions.
Yes. The agents are read-only on SCADA, relay, outage, meter and field systems; they propose causes and draft, and the report stays draft until the review lead signs. The protection engineer, the HSE advisor and the Head of Network Operations sign their parts in order, and an action closes only with evidence.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your operating standards, protection policy, report template and the records of a few past events — and it goes live once every quality gate has passed. We will walk you through it on one of your own recent outages first.
We'll run Outage Post-Event Review on the records of one of your own recent events.