Utility Wildfire Mitigation and PSPS: Why Proving Why You De-Energized Is Harder Than Deciding To

Why the de-energization decision is judged twice, and the second time is harder

Three in the afternoon, one day out. The forecast shows a wind event with gusts over the threshold across a set of circuits in an extreme fire threat area. Fuel moisture is low. Operations, meteorology, vegetation and the incident commander are on a call. Somebody shares a screen with a model output. Somebody else has a spreadsheet of circuit segments and customer counts. A decision gets made, and it is usually a defensible one, because the people in that room are good at this.

Then the second judgment starts. If you de-energize, you have taken power from thousands of customers, some on medical equipment, and you will explain that to a regulator, to those customers and possibly to a legislature. If you do not de-energize and a fire starts, you will explain that to a court. In both cases the question is the same: what did you know at the time, what did your own criteria say, and can you show it. The answer at most utilities is a folder of screenshots, a call recording, a notification vendor's export and the memory of the people on the call.

The vendor landscape is genuinely strong on inputs. Technosylva models fire behavior and consequence at a level no utility should attempt to rebuild. Pano AI detects ignitions from camera networks. AiDash and Overstory score vegetation risk from remote sensing. Each of these is a feed. None of them is the decision record, the notification obligation, the patrol evidence chain or the re-energization gate, and none of them can be, because those are shaped by your filed mitigation plan and your regulator's rules.

Problem 1: the decision inputs are ephemeral and the decision is reconstructed

A PSPS decision draws on a dozen data sets that all change hourly: gridded wind forecasts, gust probabilities at specific weather stations, fuel moisture from sampling and models, red flag warnings, your own fire potential index, asset condition on the circuits in question, recent inspection findings, outstanding vegetation work, and fire consequence modeling if the ignition were to occur. Every one of those is a moving target. The decision is made against a specific snapshot and the snapshot evaporates.

Six months later, when the post-event review or the litigation discovery arrives, the utility has to reconstruct what the 3pm forecast said. If the reconstruction comes from a vendor's current API, it is the wrong data. If it comes from a screenshot, it is partial and undated in any provable way. This is the single largest documentation weakness in wildfire programs we have looked at, and it is entirely solvable.

What a custom build does: capture the inputs, not links to the inputs. Every feed that informs a decision is stored as a versioned snapshot at the moment of ingestion, with provenance. The decision record then references those snapshots plus the criteria in effect at that time, the participants, the dissent if any, and the resulting scope. Reproducing the state of knowledge at 3pm on a given day becomes a query. The engineering here is unremarkable and the value is disproportionate, because it converts a defensible judgement into a documented one.

Problem 2: scope is a switching decision, and customer impact is a model query nobody fully trusts

De-energizing a circuit is not a checkbox. It is a set of sectionalizing device operations that determine exactly which segments go dark, and the customer list that falls out depends on your connectivity model being correct. If your as-built backlog is months deep, the customer list is wrong at the edges, and the edges are where the medical baseline customer you failed to notify lives.

Utilities work around this by scoping conservatively, which means de-energizing more customers than necessary, which drives the political cost of every event. Better segmentation is a capital program, but better use of the segmentation you already have is a software problem, and most utilities are not solving it in the two hours available.

What a custom build does: compute scope from the live connectivity model with the device set explicit, so the operational plan and the customer list are the same artifact rather than two artifacts produced by two groups. Model alternative scopes side by side, so the room can see that opening a different device saves 4,000 customers at a defined additional risk. Flag customers whose service point data is stale or whose premise attributes are unverified, because knowing you are unsure about 300 customers is far better than being wrongly confident about all of them.

Problem 3: notification is a legal obligation with the most vulnerable customers attached

Regulators require tiered advance notification ahead of de-energization and notice at restoration, with additional care for medical baseline customers and for customers with access and functional needs. Contact data is imperfect, language preferences vary, some customers have no working number on file, and some notifications must escalate to direct contact when automated attempts fail.

The usual architecture is a notification vendor driven from a customer list exported by someone under time pressure. What that architecture cannot do is close the loop: which customers received nothing, which numbers failed, which medical baseline customers require a knock on the door, who performed that knock and when. After the event, the utility reports what was sent. The regulator increasingly wants to know what was received and what happened when it was not.

What a custom build does: treat notification as a per-customer obligation with a state machine, not as a broadcast. Each customer in scope has a required notice set derived from their segment, attempts logged with channel and result, automatic escalation to the next channel and then to a field welfare check task for medical baseline customers where contact failed, all with timestamps. The post-event report is generated from those records rather than assembled. This also produces something operationally useful during the event: a live list of unreached vulnerable customers, ranked, which is exactly what the incident commander needs and rarely has.

Problem 4: re-energization is gated by patrol, and patrol is the long pole nobody planned

Restoring after a PSPS event requires patrolling the de-energized circuits before re-energizing, because the wind that justified the shutoff may have put branches on conductors. Patrol is done by ground crews and increasingly by aircraft, it takes daylight, and it is the reason customers stay out for a day after the wind drops. It is also the least systematized part of the event.

The typical setup is a patrol assignment spreadsheet, radio traffic, and a sign-off that a section is clear. When a section is missed, or when a finding is reported and lost, re-energization either stalls or proceeds on incomplete information, and the second option is the one that ends careers.

What a custom build does: make the patrol a span and section level task set derived from the same de-energization scope, assigned to crews on devices, with findings captured in the field including photographs, and re-energization blocked at the device until every section downstream is cleared or explicitly waived by a named person with a recorded reason. Daylight and crew availability then become a schedulable constraint rather than a surprise, so the restoration estimate given to customers has something behind it.

Problem 5: your filed mitigation plan commits you to metrics no product ships

A wildfire mitigation plan filed with a regulator, whether with California's Office of Energy Infrastructure Safety or under another state's or country's framework, commits the utility to specific initiatives with specific targets: miles of covered conductor, structures hardened, inspections completed, fast trip or enhanced protection settings enabled by risk tier, vegetation work in specific tiers. Those metrics are yours, negotiated in your plan, and they change with each revision.

Because they are bespoke, they are tracked in spreadsheets assembled quarterly from six departments. The result is that the utility knows its plan progress a quarter in arrears, which is exactly when it is too late to correct.

What a custom build does: define the plan metrics as configurable measures over the operational data you already generate, so progress is continuous and drillable to the underlying work records. When the plan is revised, the measures are reconfigured rather than rebuilt. The value is not the dashboard. It is that when the regulator asks how a target is tracking, the answer comes with the individual work records attached rather than as a number somebody typed.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the decision record with versioned input snapshots, scope computation from the connectivity model, and notification execution with per-customer obligation tracking runs $100,000 to $220,000 and ships in 14 to 20 weeks. A full platform adding patrol assignment and re-energization gating, medical baseline escalation to field welfare checks, mitigation plan metric tracking and regulator-format post-event reporting runs $250,000 to $600,000 phased over 9 to 15 months.

What drives it up: the number of external feeds you consume and must snapshot, since each vendor and each weather source is its own integration with its own reliability profile. Operating in more than one state or country, because each regulator's notification and reporting rules differ. Depth of OMS and SCADA integration, which is necessary for scope and device state but is never a quick connection. And the maturity of your criteria: if your de-energization thresholds are currently expert judgement rather than written rules, part of this project is helping you write them down, which is valuable and takes time.

What keeps it down: build the decision record and the notification loop first. Those two carry most of the regulatory exposure and neither requires the full operational integration to be useful.

Build versus buy, and where buying is obviously right

Buy the science. Technosylva for fire behavior and consequence modeling, camera detection networks such as Pano AI, and remote sensing vegetation risk from AiDash or Overstory are all doing work that would be irresponsible to attempt in-house. Your build consumes them, snapshots them and records how they informed a decision.

Do not build if you have no circuits in an elevated or extreme fire threat designation and no filed plan commitments. Some utilities in low risk geographies are being pushed toward wildfire tooling by vendors and by board anxiety, and the honest advice is to spend on inspection and vegetation instead.

Build when two or more of these are true. You have filed a wildfire mitigation plan with commitments you currently track in spreadsheets. You have executed a PSPS event and the post-event report took weeks to assemble. Your notification loop cannot tell you which medical baseline customers were never reached. Your re-energization is gated by patrols coordinated over radio and paper. Or your legal group has asked whether you can reconstruct the state of knowledge behind a past decision and did not like the answer.

Our position: the decision quality at most utilities is already good, and vendors selling better inputs are addressing the part that is least broken. What is broken is the record, the notification loop and the restoration gate. Those are unglamorous, they are yours, and no product will ship them for you.

How to choose a developer for wildfire and PSPS systems

Ask how they store a weather forecast used in a decision. If the answer involves calling the vendor API again later, they do not understand that the value is the snapshot, not the data.

Ask how notification obligations are modeled. Per-customer state machine with escalation is the answer you want. A campaign sent to a list is the answer that fails the first time a regulator asks who was not reached.

Ask what blocks re-energization in their design. If nothing does, they have built a reporting tool and your operators will keep using radios and paper for the part that actually matters.

Ask who owns the code and get it in writing before kickoff, including export of every decision record and notification log in an open format. At Digital Heroes the client owns the code from the first commit. Then hand a candidate developer the post-event report from your last event and ask which parts their system would have generated automatically. The gap between their answer and the whole document is the size of the project.