It is 2:47 a.m. on a February morning, and 83,000 customers have lost power after an ice storm clips your distribution system. The OMS is logging calls faster than dispatchers can read them, field crews are texting radio codes from six different geographic sectors, and your storm manager needs a single verified incident summary for the emergency operations center in twenty minutes. This lesson teaches you how to use AI to compress that chaos into a defensible, auditable report without letting the model invent a restoration estimate your crews cannot keep.

The OMS Data Problem: Why Raw Data Is Not a Summary

An Outage Management System (OMS) is the digital nerve center for distribution storm response. Every customer call, every automated fault indicator, every crew check-in flows into the OMS as a timestamped event record. During a major storm event, that stream can generate thousands of records per hour, spanning multiple circuits, multiple feeders, and multiple crew zones.

The problem is not a lack of data. The problem is that nobody can read three thousand event records in twenty minutes and produce a coherent incident summary. The traditional approach is to have an experienced dispatcher manually triage the OMS view, call a few crew foremen, and write a summary from memory and gut feel. That approach works when your most experienced dispatcher is on shift. It fails at 2:47 a.m. when the dispatcher on duty graduated eighteen months ago and your veteran just retired.

This is the Great Crew Change in action. With 25 percent or more of utility workers approaching retirement eligibility, the institutional knowledge that once turned OMS chaos into a crisp incident summary is walking out the door. AI does not replace that knowledge. It organizes the raw data so a less-experienced dispatcher can apply judgment to a structured picture instead of a flood of unfiltered records.

The OMS summarization workflow has three stages. First, you extract the structured data: customer counts by circuit, outage cause codes, estimated restoration times (ETRs) attached to each outage record, crew assignments, and restoration status flags. Second, you feed that structured extract, along with any available field reports, into an AI prompt designed to produce a draft incident summary. Third, you verify every number, every ETR, and every cause attribution before the summary leaves your hands.

A draft is a starting point. It becomes an incident summary only after a human with grid knowledge reads every number and confirms it against the source records.

Structuring the Prompt for OMS Data

The quality of an AI-generated incident summary depends almost entirely on how well you structure the input. A model that receives a narrative description of an outage will produce a narrative summary. A model that receives clean, structured OMS data will produce a structured, verifiable summary. The difference matters for two reasons: auditability and error detection.

Start by exporting a structured extract from your OMS. Most modern OMS platforms, whether ADMS-integrated systems from vendors in the Schneider EcoStruxure or GE Vernova GridOS category or standalone distribution management tools, can export a summary table in CSV or structured text. At minimum, your extract should include: outage ID, circuit ID, number of customers affected, reported outage cause, crew assigned, ETR, and current restoration status.

Your prompt structure should look like this pattern. First, establish the role and context: "You are a utility storm operations analyst. The following is a structured OMS extract from a storm event. Summarize this data into a verified incident briefing." Second, paste the structured data block directly into the prompt, formatted so each field is clearly labeled. Third, specify the output format: "Produce a summary with the following sections: (1) Total customers affected, (2) Top three affected circuits by customer count, (3) Primary cause codes and their frequency, (4) Crew deployment status, (5) Earliest and latest ETRs on record, (6) Any records with missing or implausible data." Fourth, add the verification instruction: "For every number in your summary, cite the specific record or field from the input data that supports it. Do not estimate or infer any number that is not present in the data."

That final instruction is load-bearing. Without it, a language model will fill data gaps with plausible-sounding estimates. In an OMS context, a plausible-sounding ETR that is three hours later than the actual crew commitment can cascade into a public communications failure, a mutual-aid commitment error, or a regulatory reporting problem.

What the Model Does Well

Language models excel at three specific tasks in OMS summarization. They aggregate counts accurately when counts are explicit in the input data. They organize information into a structured format faster than a human typist. And they surface inconsistencies: if outage record 4417 shows a cause code of "vehicle contact" but the circuit it appears on is a transmission-level feeder where vehicle contact is physically implausible, a well-prompted model will flag that inconsistency rather than summarize it silently.

That inconsistency-detection capability has real value during a storm event. When data is flowing fast from multiple sources, cause codes get misapplied, circuit IDs get transposed, and ETRs from different crews end up attached to the wrong outage records. The model does not know your system topology, but it can recognize when a number does not fit the pattern of the surrounding data and call it out for human review.

Where the Model Fails

Models fail in OMS summarization in two predictable ways. First, they extrapolate. If the data shows six circuits with outages and the model's training data suggests that ice storms in similar regions typically affect eight to twelve circuits, the model may insert that context into the summary as if it were a fact derived from your data. The fix is the citation instruction: force the model to justify every number from the input.

Second, models confabulate ETRs. Estimated restoration time is the number that matters most to customers, to regulators, and to mutual-aid coordinators. If an ETR is missing from a record, the model will often generate a plausible one based on typical restoration times for the apparent cause code. That generated ETR has no grounding in your actual crew availability, your current transmission constraints, or your specific system topology. It is a hallucination dressed as a forecast. Your verification step must explicitly check that every ETR in the summary is traceable to a specific crew commitment in the OMS.

Compiling Storm Reports from Field Crew Reports

Field crew reports are the second major input to a storm incident summary. These arrive as radio transmissions transcribed by dispatchers, as text messages from mobile crew apps, as photos attached to trouble tickets, or as voice memos left on dispatch recordings. They are unstructured, inconsistent in format, and often written in utility shorthand that no outsider can parse.

An experienced storm manager can read a crew report that says "CTX-7 down, possible tree contact, feeder 441 open at recloser 12A, est 3 hrs crew time" and instantly translate that into a structured update: Circuit CTX-7, likely cause vegetation, estimated restoration in 3 hours contingent on recloser clearance. A new supervisor staring at forty such messages during a storm event cannot do that translation at speed.

AI can. You feed the raw crew reports into a prompt that instructs the model to extract structured fields from each message: circuit ID, cause code, estimated crew time, any equipment clearance needed, and any safety flags mentioned. The model translates utility shorthand reliably because it has been trained on enough technical language to recognize that "feeder 441 open at recloser 12A" means a protective device has operated and needs to be investigated before restoration.

The critical verification step here is equipment identity. Field reports often contain equipment IDs that have been verbally transmitted, transcribed by a dispatcher under pressure, or abbreviated in ways that are ambiguous. A model that reads "sub 4 trans B" might correctly identify Substation 4 Transformer B on your system, or it might confidently resolve that abbreviation to a different asset. Before any field-report-derived summary goes to your emergency operations center, every equipment ID in the AI output must be cross-checked against your GIS asset register or your ADMS topology model.

Equipment IDs are where AI hallucinations in storm reports hurt the most. One wrong transformer ID sends a crew to the wrong location and extends restoration time by hours.

Verifying Restoration Estimates: The ETR Discipline

The estimated restoration time is the most sensitive number in any outage communication. Customers plan their lives around it. Regulators track it for major-event reporting. Emergency management agencies use it for shelter-in-place decisions. Getting it wrong has financial consequences from customer bill credits, regulatory consequences from major-event performance metrics, and human consequences from vulnerable customers who make dangerous decisions based on a wrong ETR.

AI cannot generate a valid ETR. That statement needs to be understood in full. An ETR is a function of crew travel time, the specific repair scope needed for the specific damage at the specific location, parts availability, any transmission-level switching needed before distribution restoration can proceed, safety clearance requirements, and weather conditions affecting crew work rates. No language model has access to most of those inputs in real time.

What AI can do is compile and organize the ETRs that your crews have already committed to in the OMS, flag any that are suspiciously far from the mode of similar-cause outages in the current event, and highlight any circuits where an ETR is missing entirely so a human can follow up.

Your verification workflow for ETRs should follow this sequence. Step one: confirm that every ETR in the AI summary has a traceable source in the OMS record. Step two: for any ETR that looks implausible (either much shorter or much longer than peer outages in the event), call or radio the responsible crew foreman directly to confirm. Step three: for circuits with no ETR on record, escalate to a crew supervisor for a committed estimate before allowing the AI summary to include anything resembling a time. Step four: document the verification. A line in the incident log that reads "ETR for Circuit 441 confirmed with Foreman Martinez at 03:15" is your audit trail.

The reason this discipline matters beyond the immediate event is regulatory reporting. Most state public utility commissions have major-event reporting requirements triggered when restoration times exceed a threshold, typically 24 or 48 hours. The ETRs in your incident summary become part of the official record. If an AI-generated ETR is used without verification and later proves wrong, the discrepancy will appear in post-storm analysis, and the explanation "the model said so" does not satisfy a commission investigator.

Drafting Public and Regulatory Communications

Once you have a verified incident summary, the next task is translating it into public-facing communications and internal regulatory notifications. This is where AI earns a second layer of value: drafting. A verified incident summary that lives only inside the emergency operations center is not serving the 83,000 customers who want to know when their power is coming back.

The public communications workflow follows the same pattern as the summarization workflow, with one important addition: tone calibration. An incident summary written for your emergency operations center uses technical language appropriate for grid professionals. A public notification sent to customers needs plain language, clear ETRs, and actionable safety information. An AI model can rewrite the technical summary in plain language in seconds, but you must verify that the rewrite preserved the correct numbers and did not add context or estimates that were not in the verified summary.

Prompt the model explicitly: "Rewrite the following verified incident summary as a plain-language customer notification. Use only the facts in the summary below. Do not add estimates, additional context, or safety advice that is not in the summary. Every number in the customer notification must match a number in the summary exactly."

For regulatory notifications, the discipline is even stricter. Most state PUC rules specify both the triggering threshold and the reporting timeline for major outage events. A common structure: a utility must notify the commission within two hours of declaring a major event (often defined as an event affecting 10 percent or more of customers, or exceeding a defined customer-hours threshold), and must file a preliminary written report within 24 hours, with a final post-event report within 10 to 30 days. NERC EOP-004 adds a parallel federal obligation: reportable disturbances must be filed with NERC's Event Analysis system within specific timeframes depending on the event category, ranging from immediate notification for loss of control center capability to 24 hours for certain protection system failures. An AI output for a regulatory notification must be reviewed against the specific rule text before it is filed, because the triggering thresholds and filing deadlines vary by jurisdiction and by event category. The model's recollection of those thresholds is not a reliable source. This is the same principle that appears throughout this program: AI drafts, a human with access to the authoritative source verifies, and a named human signs off.

Worked Example: Ice Storm Summary from Raw OMS Data

Here is a concrete walkthrough showing where AI helps and where it fails. Imagine you have exported the following simplified OMS extract: sixteen outage records, covering eight circuits, with customer counts ranging from 400 to 12,000, cause codes including vegetation (nine records), equipment failure (four records), and unknown (three records). ETRs are present on thirteen records, missing on three. Crew assignments show fourteen records with assigned crews and two with no crew assigned yet.

You feed this into a well-structured prompt and receive an AI draft summary. The draft correctly aggregates: 83,400 customers affected, vegetation as the leading cause at 56 percent, crew coverage at 88 percent of outage records. The draft flags the three missing ETRs and the two unassigned records as items requiring human follow-up. So far, so good.

Now examine the draft carefully. One entry in the draft reads: "Circuit CTX-12 (3,200 customers): ETR 05:30, cause code vegetation, crew assigned." You go back to the raw data. The OMS record for CTX-12 shows an ETR of 05:30 and a crew assignment. But the cause code in the OMS record is "unknown," not vegetation. The model inferred vegetation from the surrounding records and silently applied that inference to a record where the cause had not been determined. That is a hallucination of the quiet, plausible variety. If you filed a regulatory notification with "vegetation" as the cause code for CTX-12 and the actual cause later turned out to be equipment failure, you have a reporting problem.

The fix is the citation instruction. Had you required the model to cite the specific field from the input data for every attribution in the summary, it would have been forced to either cite "unknown" for CTX-12 or flag that the cause code was not verified. The worked example teaches the single most important habit in AI-assisted storm reporting: every attribution in the AI output must trace back to a specific field in the input data, not to the model's pattern-completion instinct.

Key Takeaways

• AI-assisted OMS summarization compresses thousands of event records into a structured draft, freeing experienced staff to apply judgment rather than manually triage raw data during a time-critical storm response.
• The input structure determines the output quality. Export clean, labeled OMS data rather than narrative descriptions, and the model's summaries will be more accurate and more auditable.
• Always require the model to cite the specific source record for every number in the summary. This single instruction catches the largest category of AI errors in storm reporting: plausible-sounding inferences that have no grounding in the actual data.
• AI cannot generate a valid ETR. It can organize and flag ETRs that your crews have already committed to, but every ETR in a public or regulatory communication must be traced to a specific, human-confirmed crew commitment.
• Equipment IDs from field crew reports require cross-check against GIS or ADMS before they appear in any incident summary. A transposed or hallucinated asset ID sends crews to the wrong location.
• The verification trail is not bureaucracy. It is the difference between a defensible incident report and a liability in a post-storm regulatory review. Document every number you verified and who confirmed it.
• AI earns compounding value in the Great Crew Change era: it allows a less-experienced dispatcher to produce a structured, verify-able draft that an experienced supervisor can confirm in minutes rather than composing from scratch under pressure.