Use case
Use case4 min readBy The Data Workers Team

Outage and reliability analytics, run by agents

Outage events leave the OMS with missing restoration times, estimated customer counts and cause codes that changed after the fact, and the reliability report has to tie to them. The numbers get argued over just before they go to the regulator. Here is how Data Workers runs it instead.

Key takeaways

  • •The problem today. SAIDI, SAIFI and CAIDI are built from outage management system (OMS) events that are edited after the fact and carry estimated customer counts. They are reconciled by hand in the weeks before the report goes to the regulator.
  • •What changes. Agents check every outage event as it closes, tie it to customer and meter records, and recompute the indices whenever an event is corrected.
  • •What stays with your people. Every major event day exclusion and every correction to a filed number is a proposal the reliability lead approves.
  • •The result. A reliability report where each number traces to its events, and a difference from last quarter that is already explained.

The problem today

IEEE 1366 defines the indices most regulators ask for: SAIDI for minutes without power per customer, SAIFI for how often, CAIDI for how long each interruption lasts. The inputs are the hard part.

An OMS event is opened by a call or a SCADA alarm and closed by a crew. The restoration time is typed in, or left blank. Customers interrupted is an estimate from the OMS circuit model and can differ from the customer records. A storm makes hundreds of events, then someone re-codes them. Major event days come out of the headline numbers, so the list of excluded days has to be right and explained. Engineers reconcile spreadsheets to the prior filing under a deadline, which is why the week for utility data teams goes to firefighting.

What changes with Data Workers

Agents work alongside your OMS, which stays the system of record for events. They read closed events from the lakehouse as they land and check each one before it reaches a reliability number: restoration time present and after the start, customers interrupted consistent with the customer and meter records, no duplicate events, sustained and momentary interruptions separated as your standard requires.

One governed definition of each index sits in the catalog, with its customer denominator and exclusion rules, so the dashboard, the regulator report and the planning model compute the same SAIDI. When an event is corrected, the indices are recomputed and the change is explained. This is one practice in the field guide for utility data teams, for the operations and supply chain data teams that share one dataset between grid and bill. The energy and utilities platform view covers the stack.

The workflow: Quality Monitoring agent (run_quality_check) → Data Context & Catalog agent (resolve_metric) → Incident Debugging agent (get_root_cause) → Data Access & Governance agent (request_governance_review).
Fig. 1:The workflow: Quality Monitoring agent (run_quality_check) → Data Context & Catalog agent (resolve_metric) → Incident Debugging agent (get_root_cause) → Data Access & Governance agent (request_governance_review).

The workflow, step by step

  1. 1.The Quality Monitoring agent calls run_quality_check and tests each closed event for a missing or impossible restoration time, a customer count that disagrees with the records, and duplicates.
  2. 2.The Data Context & Catalog agent calls resolve_metric and computes SAIDI, SAIFI and CAIDI from the governed definition, listing the major event days the standard's test identifies and the events behind each.
  3. 3.The [Incident Debugging agent](/blog/incident-debugging-agent/) calls get_root_cause and traces any difference from the last filing to the events, edits or customer-count changes that caused it.
  4. 4.The Data Access & Governance agent calls request_governance_review and puts the exclusion list and any correction to a filed number in front of the reliability lead, with a preview and how to undo it.

The impact metrics we move

  • •Outage events checked for restoration and duplicate errors: from about 2 days to 20-30 min
  • •Customers interrupted tied to customer records: from about 3 days to 1-2 h
  • •Major event days identified and documented: from about 1 day to 30-45 min
  • •Indices recomputed after a corrected event: from about 1 day to 10-15 min
  • •Change from last filing explained: from about 4 days to 2-3 h
Time to complete, current practice (black) vs. with Data Workers (green). Illustrative.
Fig. 2:Time to complete, current practice (black) vs. with Data Workers (green). Illustrative.

What goes on autopilot

  • •Every outage event is checked when it closes, so a blank restoration time is chased the day it happens, not at quarter end.
  • •The indices are recomputed after every correction, with old and new values side by side.
  • •Event, circuit and customer records stay documented in the catalog, with an owner on each.

Where your people stay in charge

Excluding a day, and correcting a number that has been filed, change what the regulator sees. Each one goes to a named approver, the reliability lead, with regulatory compliance seeing the same proposal: original value, proposed value, the events behind it and the reason. Approval is recorded in a tamper-evident audit trail, with a signed record of what ran and how to undo it, the evidence a regulator's data request asks for later (how approvals work). Your regulator's exclusion rules, cause-code policy and the decision to refile stay with your team. Everything starts at L1, observing only; autonomy rises only on evidence.

The pilot

  • •Scope. Event checks and index reconciliation for one operating region over the last reporting year, with exclusions held at L2.
  • •First week. Agents run at L1, observing only, and show what they would have flagged, with receipts.
  • •By week two. Event checks and recomputation run on their own; every exclusion and correction goes to the reliability lead.
  • •At day 30. We review the impact metrics against your baseline:
  • •Indices recomputed after a corrected event: from about 1 day to 10-15 min
  • •Change from last filing explained: from about 4 days to 2-3 h
  • •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

Related Posts

Team playbook

How utility data teams go fully agentic and autonomous

If you are a Head of Grid Data, this is your playbook. It covers what your team ships, where its week goes today, the use cases agents take over first, the autonomy you can safely grant in each domain, and what to show leadership after the first quarter.

Use case

Meter data management, run by agents

Interval reads reach billing through validation, estimation and editing, and the exceptions pile up faster than the meter data team can clear them. Gaps, meter swaps and stuck registers get found at bill run instead of before it. Here is how Data Workers runs it instead.

Use case

Customer energy usage data, run by agents

Green Button downloads, the customer portal and third-party feeds all draw on the same usage tables, and the team that owns them answers for both accuracy and consent. A wrong interval or a release outside what the customer agreed to is found by the customer. Here is how Data Workers runs it instead.

Use case

Rate cases and regulatory reporting, run by agents

A rate case rests on test-year numbers that start in the general ledger and pass through workbooks before they reach an exhibit. Then FERC Form 1 and the commission's data requests ask how each one was built, on a clock. Here is how Data Workers runs it instead.