Field, grid, and back office —
engineered together.
OT systems modernization, regulatory-reporting platforms, AI for field operations, and the data consolidation that lets the grid side and the customer side actually speak. Built for the reliability envelope an outage hour costs.
What utility and energy software looks like in practice.
Utilities and energy operators run two worlds at once. The OT side: SCADA, EMS, ADMS, OMS, the GIS that knows where everything is, the meter data infrastructure, the historian behind it all. The IT side: customer information systems, work and asset management, billing, the regulatory-reporting stack. The two sides used to be allowed to stay separate. They are no longer.
The pressure right now is to make the field, the grid, and the back office work as a single operation. Outage response that pulls from AMI, ADMS, and CIS at the same time. Asset health programs that read historian data and route to work-management. Field crews carrying tools that actually know which transformer they are looking at. AI is starting to land here in real ways, but it has to land inside the reliability envelope the OT side requires.
Apollo builds the integration, data, and AI work between the OT side and the IT side. Reliability-aware by construction, regulator-aware for the parts that get reported, and field-aware for the parts crews actually use.
NERC CIP for the bulk electric system, FERC orders for the wholesale market, state public-utility commissions for the retail side, and EPA reporting for the generation fleet. Add cybersecurity executive orders and the TSA pipeline directives where they apply. The reporting cadence is constant.
The OT and IT networks that were supposed to stay separate but now have eight integrations between them, none of them documented. The GIS that disagrees with the OMS about which feeder serves which customer. The SCADA historian whose tag names made sense in 2003. The outage-restoration spreadsheet a dispatcher keeps on a second monitor.
Outage prediction and crew-routing assistance. Asset-health models on the data the historian already has. Field-crew copilots that read work orders, GIS, and the asset record at the same time. Regulatory-narrative drafting where every output has its source data attached and a human signs before submission.
Four engagement patterns in energy and utilities.
Most engagements with utility and energy operators land in one of these shapes. Each gets built inside the reliability posture the OT side requires, with the audit trail the regulator on the other side will eventually ask for.
OT Systems Modernization
The applications and integrations that sit alongside SCADA, ADMS, OMS, and the historian, modernized in place. Field-operations tooling that crews can use on a tablet in the rain. Work-management workflows that finally pull from GIS and the asset record at the same time. Existing OT systems stay. The aging surrounds get rebuilt.
Regulatory Reporting Platforms
The pipelines that feed NERC compliance reports, FERC filings, state-PUC dockets, EPA emissions reporting, and the reliability metrics that get scrutinized after every event. Data lineage is a first-class concern. Every number on a filed report traces back to the source system it came from.
Field-Operations AI Assistants
AI applications for dispatchers, planners, and field crews. Outage-restoration assistance that reads OMS, ADMS, and GIS together. Work-order copilots that pull the asset history before the truck rolls. Every recommendation is attributable, every action loggable, every override traceable.
Grid & Asset Data Consolidation
Historian, AMI, SCADA, GIS, OMS, and CIS data unified into a single query-able layer. Tag mapping, identity resolution, and the lineage required for reliability analytics and regulatory submissions. The reporting layer and the analytics layer finally see the same numbers.
Where our work sits.
Utility and energy operators run a small set of OT systems with years of integrations to the IT side. Apollo builds the modernization, data, and AI work between the two. The map below is simplified, but representative of what we walk into.
Compliance, designed in.
The frameworks that shape what we build, and what we ship.
Energy and utility operators live under a stack of regulators that overlap, contradict on the margins, and rarely move at the same pace. The right set for any engagement depends on whether bulk electric assets are in scope, whether the work touches the wholesale market, what the state PUC has issued lately, and which generation assets the EPA cares about.
Apollo treats these as design inputs, not as a checklist applied at the end. Access boundaries, audit trails, OT/IT segmentation, data lineage, and reporting hooks get specified before the first line of code and reviewed against the relevant frameworks at every iteration.
The panel on the right is the working set we encounter most often. Any given project picks a subset, and the proposal will be explicit about which ones apply and what we will and won't certify directly.
Federal & reliability
State & ratepayer
Cybersecurity & controls
Four phases. Built around the reliability envelope.
Apollo's standard methodology, applied to energy and utilities. OT/IT segmentation, reliability posture, and lineage requirements get specified before the build starts, so the IT-side analytics keep working when the OT-side network goes intermittent.
Map the systems. Map the regulators.
The OT stack (SCADA, ADMS, OMS, historian, GIS), the IT stack (CIS, WAM, billing), the integrations between them, and the volumes. The reliability metrics and reporting cadences in scope. Where AI helps, where rules suffice, and where a dispatcher still has to confirm.
Architecture, reliability plan, lineage plan.
OT/IT bridge architecture and segmentation design. Reliability posture for the field-side links: store-and-forward, idempotency, intermittent-network tolerance. Lineage design for regulatory-reportable data. Field-UI wireframes for the crews who'll actually use it.
Bridge. Platform. Field UIs.
OT/IT bridge deployed inside the security boundary, historian and AMI integrations connected, AI assistants wired up with attribution, field UIs functional. Two-week iterations. Each shipped capability arrives with its tests, its monitoring, and the lineage fields the regulator will ask for.
Measure. Tune. Expand.
Reliability metrics, model accuracy, dispatcher-adoption rates, and OT-link availability in production dashboards. Threshold tuning based on what the data shows. Gradual rollout to adjacent feeders, districts, or service territories once the first one is steady. Knowledge transfer to your team along the way.
Tell us what you're trying to build.
Send a paragraph about the project: the OT and IT systems involved, the service territory, the reliability metrics or reporting frameworks in scope, and the parts that aren't working today. We'll reply within one business day, either with a 30-minute call or with an honest "this is not the right fit; here's who you should call instead."