The grid runs on judgment
that nobody wrote down.
Investor-owned utilities, municipal and co-op providers, and the engineering firms that serve them. Outage response, vegetation management, rate-case preparation, and field-work planning all run on institutional knowledge held by people who are retiring. We build the systems that catch it before it walks out the door.
The specific things utilities & energy teams tell us they wish were already fixed.
The workforce cliff is the real story
A large share of the trades and engineering bench is at or near retirement, and what they know about your specific system is not in any manual. The fix is not a chatbot. It is capturing decisions as they get made, in the words of the person making them, before the seat turns over.
Outage response is a coordination problem
The models for predicting damage are the easy part. The hard part is the hour after the storm, when dispatch, damage assessment, mutual aid, and customer communications each hold a different picture of the same event. That is a systems problem before it is an AI problem.
Rate cases are assembled by hand
Every filing pulls the same categories of evidence from the same systems, and a team rebuilds it under deadline. The assembly is mechanical and repeatable. The testimony is not, and it stays with the people who have to defend it.
Vegetation and asset programs run on stale data
Inspection cycles, LiDAR passes, and work orders live in separate systems with separate refresh rates, so crews get dispatched against a picture of the circuit that is months old. Reconciling those feeds is unglamorous and it is where the money is.
Which of our solutions move your number first.
We've already worked inside your tools.
Utility work happens inside a small set of systems of record, and the integration patterns matter more than the model. These are the platforms utility engagements keep landing in.
In most industries a wrong answer costs money. Here it can de-energize a hospital.
Utilities get sold the same AI pitch as everybody else, and it fits worse here than almost anywhere. The consequence profile is asymmetric: the upside of automating a decision is some hours saved, and the downside is a safety event, a reportable outage, or a commission proceeding. That asymmetry should change what you automate, and it usually does not.
So the honest version of this work looks conservative from the outside. The highest-value systems we build for utilities are not the ones making operational calls. They are the ones doing assembly, retrieval, and reconciliation — the work that eats a planner’s week and carries no consequence if it is a little wrong, because a human reads it before anything happens.
The decisions that actually move risk stay with your operators. That is not caution for its own sake. It is that a system nobody can answer for is a system a commission will eventually ask you to answer for.
Custom software, built for your workflow.
Utilities are not a vertical where you install a product and walk away. The regulatory boundary and the systems of record differ enough between a municipal provider and an IOU that the build is always specific. These are the shapes it usually takes.
Knowledge capture before the seat turns over
Structured capture of how your senior people actually make calls — switching decisions, damage assessment judgment, load-transfer reasoning — recorded against real events and reviewed by the person who made the call, while they are still here to correct it.
Storm-response coordination layer
One picture of an event assembled from dispatch, damage assessment, mutual aid, and customer comms, so the hour after the storm is not spent reconciling four versions of the truth.
Rate-case evidence assembly
The mechanical half of a filing — pulling, formatting, and cross-referencing the same evidence categories every cycle — leaving the testimony and the strategy with the people who have to defend them.
Field-work planning against current data
Vegetation, inspection, and asset feeds reconciled into one current view of the circuit, so crews are dispatched against what is true this week.
Built knowing what your compliance team will ask.
Anything touching bulk electric system cyber assets stays inside the boundary. In practice that means private inference, scoped tool access, and no training data leaving your environment — decided in week one, not discovered at audit.
If a system contributes to a filing, its outputs have to be explainable to a commission and a hostile intervenor. We build for the deposition, which rules out anything you cannot show your work on.
Critical Energy Infrastructure Information and customer usage data carry separate handling rules. They get separate treatment rather than one blanket policy that satisfies neither.
Things utilities & energy teams ask first.
Can you work inside a NERC CIP boundary?
Yes, and the boundary gets decided in week one rather than discovered at audit. In practice it means private inference, scoped tool access, no training data leaving your environment, and a written record of what touches bulk electric system cyber assets and what deliberately does not.
Do you work with municipal utilities and co-ops, or only IOUs?
All three. The regulatory surface differs — a municipal provider answers to a city council and an IOU answers to a state commission — but the operational problems are nearly identical, and the smaller providers usually move faster because the approval chain is shorter.
Will this replace our field crews or operators?
No, and if that is the goal we are the wrong firm. The work we do in utilities is assembly, retrieval, and reconciliation — the desk work around the decision. The decisions that move risk stay with the people who can be asked to defend them.
How do you handle explainability for a commission?
By ruling out anything you cannot show your work on. If a system contributes to a filing, every output needs a traceable path back to source data. That constraint eliminates some techniques entirely, which is a reasonable price for not being surprised in a proceeding.
We have a data warehouse project that has been running for two years. Do we need to finish it first?
Usually not. Waiting for the warehouse is the most common reason utility AI work never starts. Most of what we build reads from the systems of record directly, and the useful work tends to clarify what the warehouse should actually contain.