It is a companion to the outage work order verification guide, which covers what to inventory before a platform migration.
The case: one lateral, two failures (Illustrative)
Written for this page; it does not describe any real utility, crew or customer. A 410-person electric distribution cooperative is working a storm evening. The outage platform groups 38 trouble calls into one event and predicts a blown fuse on a lateral serving 52 customers. A crew replaces the fuse, and the work order closes.
The exception is a local restoration that leaves a related dependency unresolved. The crew fixed the device it was sent to. A second blown fuse, on a transformer further down the same lateral, stayed hidden behind the first, so six customers were never restored by the first job.
Seven moments, the person who decided, and the record left behind
Each step below names who acted and where the decision was written. The record column is the part a partner asks about.
- 19:40, grouping. The outage platform's prediction engine groups 38 calls into one event, predicted device the lateral fuse, 52 customers affected. Decided by: the system, accepted by the dispatcher. Record: event with predicted device and customer count.
- 20:05, dispatch. The dispatcher assigns a crew and opens a work order to replace the lateral fuse. Decided by: dispatcher. Record: crew assignment on the event, work order in the asset system.
- 21:15, first closure. The crew replaces the fuse and reports restoration. The work order closes and the event is marked restored for 52 customers. Decided by: crew foreman. Record: work order completion time, event restored time.
- 21:40, restoration check. The control room runs callbacks and reads meter events for the affected premises. 46 customers confirm power; 6, all on one transformer, do not. Decided by: control room operator. Record: callback log and meter event data, if the company keeps them.
- 22:05, nested event. New calls arrive from the same six customers. The operator creates a child event under the original rather than a fresh outage. Decided by: control room operator. Record: parent-child link on the outage platform.
- 23:30, second crew action. A second crew replaces the transformer fuse. Decided by: dispatcher and second crew. Record: second work order against a different asset.
- 23:45, verified closure. Callbacks confirm all six are back, and both events close. Decided by: control room operator. Record: second restoration check and final event closure.
Steps 1 to 3 are what nearly every utility keeps. Steps 4 and 5 are the contradiction and the correction, and they are the reason the case is worth describing.
The customer-minutes the first closure got wrong
Taking the 21:15 closure at face value understates the outage. The verified record changes the number a reliability report would use.
| Version of events | Customers and duration | Customer-minutes |
|---|---|---|
| First closure taken as final | 52 customers out for 95 minutes | 4,940 |
| Verified record, restored group | 46 customers out for 95 minutes | 4,370 |
| Verified record, transformer group | 6 customers out for 245 minutes | 1,470 |
| Verified record, total | 46 at 95 minutes plus 6 at 245 minutes | 5,840 |
The gap is 900 customer-minutes, about 18% more than the first closure implied. Duration indices reported to federal statistics are built from exactly these minutes: the federal electricity survey collects average interruption duration per customer in minutes, and treats an interruption as sustained once it passes 5 minutes, so both groups here count. A utility whose records keep the child event can defend the 5,840; one that kept only the first closure cannot.
Why this sequence is worth more than the closure
An AI system learning restoration work needs the whole pattern: prediction, action, closure, contradiction, second action, verified closure. Clean jobs teach the first three. Only cases like this one show what a careful operator does when the field says "done" and the meters disagree.
Outage platforms can hold that structure. Oracle's Network Management System user guide, for example, has procedures for copying event details to related partial restoration events, updating several events together and completing an event. Whether a given company used those features, and whether the relationships survived past migrations, is exactly what the operations director can tell you. The cross-system map shows which identifiers have to survive for steps 4 and 5 to stay readable.
OracleThe same verified-correction pattern appears outside utilities: accounts payable exception handling and documented logistics exceptions both turn on whether the reversal was recorded, and computer-use agents need exactly this kind of before-and-after trail. A job whose priority changed mid-stream is a different workflow, covered in emergency work order prioritization.
Spotting clients with cases like this
Listen for these in conversation with an operations or asset consultant's client:
- "We call back before we close." A restoration check policy means step 4 may be stored, not only acted on.
- Nested or related events. If the outage platform supports parent-child events and dispatchers use them, step 5 survives.
- Meter event data tied to outages. Advanced metering that reports power-off and power-on events gives an independent check.
- Storm reviews. Utilities that review major event days may already have reconstructed sequences like this one.
- A platform change ahead. A replacement outage system puts closed events and their links at risk, which is the main guide's subject.
Partners write down which of these apply, how many years, and which systems; never event exports, network maps or customer lists.
What a partner records, and qualification
Record the operations director's answers at metadata level: whether nested events and restoration checks are stored, years covered, the systems involved and who owns each. Whose yes starts a licensing conversation is covered in who can license outage work order verification records.
The company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. What stays unknown until SourceX reviews it: SourceX's current data needs for this record type, the rights review result, which customer-linked fields must be removed and whether any offer follows. Partners sign the Channel Partner Agreement before submitting; attribution goes to the first valid introduction within the 90-day window, credited when the company submits a verified application.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a client's records keep the callback that contradicted a closed work order and the event that fixed it, register as a partner, check the utility on who qualifies and read the program terms before you introduce the operations director.