How AI Works in Ellume BRIDGE — Built to Survive an Audit
Every number in a GADS filing is arithmetic. Every label is a judgment. Knowing which is which is the whole design. Ellume BRIDGE keeps AI out of the calculation path entirely: outage hours, MWh loss and availability are deterministic arithmetic over telemetry. AI does the analytical work instead — assembling context for every detected event, proposing classifications with reasoning, and naming what it cannot resolve. A reviewer always decides, and the record of that decision is permanent.
The question that shaped the design
Fourteen months after you file, an auditor asks why a particular outage was classified the way it was. “The AI said so” is not an answer. Neither is “the model was 87% confident.” The only answer that survives an audit names evidence and a person: the reviewer confirmed the inverter reported a DC bus fault, the weather record shows no grid disturbance that hour, and the same fault had hit the same feeder twice that quarter. That single constraint determined where AI sits inside Ellume BRIDGE — and, just as importantly, where it doesn't.
Every number is arithmetic. Every label is a judgment.
A GADS filing — the quarterly performance and event report every plant above 20 MW owes NERC — contains two very different kinds of claim. The first is a number: forced outage hours, MWh loss, availability. These are arithmetic over telemetry — count the intervals each inverter was out, multiply, sum. There is exactly one correct answer, and anyone with the same data can check it. The second is a label: event type, cause code, contributing condition, the written description of what happened. These are judgments about what your equipment's own error reporting means once translated into NERC's fixed vocabulary. Language models are unreliable at the first and genuinely useful at the second. So BRIDGE draws the line exactly there. Nothing in the calculation path calls a model — not as a policy we plan to relax, but as a structural property of the system. Ask a language model to add up a month of intervals and you will get an answer that is usually close and occasionally wrong, with no way to tell which. That is not a property you can carry into a regulatory filing.
What the AI actually does
Detection is deterministic by design. BRIDGE identifies outages from inverter state and fault codes — repeatable, and immune to the kind of variation you cannot explain to an auditor. From there, the AI does the analytical work that used to consume a senior engineer's quarter. Three things happen.
- •It assembles the context. Which fault codes were raised and how often. The weather at that exact hour, and either side of it. Whether the same fault hit the same feeder in the last ninety days. Whether other events were running at the same moment. All of this is gathered before the model is asked anything at all — it isn't the AI's job to decide what to look up.
- •It builds a case, not a conclusion. What appears to have happened. Whether weather plausibly explains it. Ranked cause code candidates, each with the reasoning behind it. An explicit list of what remains ambiguous. A draft description for the record.
- •It asks the questions it cannot answer. For many events, the honest position is that the telemetry cannot settle it. Whether lightning actually struck needs utility strike data or a site log. Whether an outage was planned maintenance needs the operations calendar. Neither lives in inverter data. A system that guesses here produces confident fiction — so BRIDGE asks instead. The reviewer answers, the analysis is refined with those answers folded in, and that is where it stops.
One event, end to end
On a clear September morning, all 240 inverters at a 30 MW plant dropped into fault at the same fifteen-minute reading. The same code on every one of them: 302, “No AC Connection.” Forty-five minutes later they were generating again. Total loss, 23 MWh. None of that needed AI. The inverters reported their own state, the arithmetic over those intervals produced 100 inverter-hours of forced outage, and the irradiance record — clear sky, 637 W/m² — ruled out weather without anyone having to form an opinion about it. Then the AI prepared the review, and this is the part worth dwelling on. It offered two cause codes, not one:
- •24020, AC Electrical Cables — the standard mapping for “No AC Connection,” an open circuit in the AC wiring. This was its highest-confidence answer.
- •23610, Circuit Breaker or Switchgear — scored lower, but supported by something it found in the plant's own history: an event two months earlier, same fault code, that had been classified as maintenance.
It also stated plainly what it could not settle. Was this a cable failure, or a breaker somebody opened on purpose? The telemetry looks identical either way. So it declined to classify the event and sent it up with both candidates and the reasoning for each. The reviewer knew the answer. The breaker trip was deliberate — the same known maintenance action as July. They confirmed 23610 and changed the event type from Forced to Maintenance. That correction moved roughly a hundred inverter-hours out of forced outage and into maintenance in the filed record. Two very different compliance stories, from identical telemetry.
And it's worth being blunt about what this example shows: the AI's highest-confidence answer was the wrong one. A system that files its top-scoring candidate would have submitted 24020 as a forced outage, and it would have looked entirely reasonable on the way out the door. What protected the filing wasn't the model being right. It was the model being obliged to show its second candidate, give its reasoning, admit the ambiguity, and hand the decision to somebody who held context it never had. That's the whole design, in one event.
Why not an agent
The fashionable way to build this in 2026 is an agent: hand a model some tools, let it decide what to query, loop until it's satisfied. We evaluated that and chose not to, for three reasons.
- •Nothing needs discovering. Everything an agent would go hunting for is data we can fetch up front. The model doesn't need to decide what to look up; it needs to reason well about what's already in front of it.
- •The task is single-shot. Analysing an outage isn't a multi-step investigation. A capable model given full context in one pass beats a weaker one spending six turns assembling that same context.
- •Reproducibility. An agent's path varies between runs — different tool order, different intermediate results, variance compounding at each step. For a record you may defend years later, “the agent got there through a sequence of steps that may differ on replay” is not a defensible answer.
If maintenance calendars, utility lightning data or SCADA alarm feeds ever become reliably queryable inside the system, tool use for gathering information — still not for deciding — starts to earn its place. Until then, it adds risk without adding insight.
Three guardrails
AI never produces a number that gets filed. Hours, MWh loss, availability, Appendix L factors — all arithmetic, recorded alongside the version of the engine that produced them. AI never closes a record. Once a reviewer approves or overrides a classification, that record is locked. No later run may alter it — not a recomputation, not a re-analysis, not a correction elsewhere in the month. Human judgment is the ceiling of the system, not something it can overwrite next time it runs. When AI fails, it says so. The tempting failure mode is to return a plausible-looking default so the pipeline doesn't stall. BRIDGE refuses: a failed analysis surfaces as an error rather than a stored guess. A visible gap gets fixed. A stored fake gets filed.
Every decision leaves a record
Locking a reviewed record only means something if you can see how it came to be that way. So BRIDGE keeps the full review history alongside the filing, and it is visible to you — not sitting in a log on our side of the fence. For every event, the record shows who reviewed it and when, whether they accepted the classification or overrode it, the note they left explaining why, and the answers they gave to the questions the analysis raised. Every version of the analysis is kept as well, each one stamped with the reviewer's answers as they stood at that moment — so you can see not just the conclusion, but how it was reached and what changed along the way. The effect on the numbers sits in the same place. For the September event above, the history entry shows forced outage hours falling from 105.25 to 5.25 and maintenance hours rising from zero to 149.75, tied to the specific event and the specific decision that moved them. When an auditor asks who classified an event and on what basis, nobody has to reconstruct it from memory. It's a row.
| The AI proposes | The reviewer decides |
|---|---|
| Ranked cause code candidates, with reasoning | Which cause code is submitted |
| Whether weather plausibly explains the event | Whether lightning actually struck |
| That an event looks like planned work | Whether it was planned, from the operations calendar |
| A draft event description | The wording that gets filed |
| The questions worth asking | The answers — and whether the record is defensible |
The point isn't fewer people in the loop. It's a better-prepared loop. A reviewer opens an event and finds the context already assembled, candidates ranked with reasons, ambiguities named rather than buried, and the two or three questions that actually matter. The judgment stays theirs. The filed record carries both halves — what the system worked out, what the person decided, and the evidence each rested on. That's what matters when the audit letter arrives.
Frequently Asked Questions
- Does AI calculate any part of our GADS numbers?
- No. Outage hours, MWh loss, availability and Appendix L factors are computed deterministically. The same inputs always produce the same outputs, and the engine version behind any filed figure is recorded with it.
- What if the AI suggests the wrong cause code?
- It gets caught in review, because the AI never submits. Every classification reaches a reviewer as a candidate with its reasoning, and the reviewer's decision is what gets filed.
- Can we override it?
- Always, and permanently. Once you approve or override a classification, that record is locked and no later run can touch it.
- Can we see who reviewed each event and why they decided what they did?
- Yes — the review history is part of the record and available to you. It carries the reviewer's identity and timestamp, whether they accepted or overrode the classification, the note explaining why, their answers to the questions the analysis raised, and every version of the analysis itself. The before-and-after effect on your filed hours is recorded with it.
- How is this different from a monitoring platform's AI alerts?
- Different job. Monitoring AI tries to decide whether something is wrong. BRIDGE starts after an event has already been detected deterministically, and works on the regulatory question: what NERC vocabulary correctly describes it, and what evidence would defend that choice.
