Skip to content
Hominis Agentic OS · early access program now openJoin the waitlist
RealAI
InsightsEnergy

Utilities Went Real-Time Last

RealAIMar 27, 20238 min read
EnergyUtilitiesData ReadinessData QualityMLOpsSmart Metering

A utilities capability pack sits on my reference shelf, and one sentence in it has outlived everything else on the page. Sectors such as finance and communications, it says, have adapted their businesses to the real-time environment. Utilities are just starting to face the consequences of doing business in real time, through smart meters connected to a smart grid.

Just starting. Not leading, not catching up. Starting.

The document is not ours. It is another firm's internal capability pack, assembled so its own consultants could open wider conversations with utility clients. In collateral like that, the polished claims tell you what the seller thinks the buyer wants to hear, and the unguarded lines tell you what the sector looked like from inside a delivery team. That sentence is an unguarded line.

Last is the strongest word the document supports. It does not date the lag, and I will not invent an interval it never measured. What it records is an ordering: one group of sectors had already rebuilt around a continuous clock, and the sector that generates and distributes energy was starting the same move. The ordering is the finding, and the ordering is enough.

The event was the cadence, not the meter

Almost everything written about smart metering was written about the meter. The meter is the least interesting object in the story. What changed was the clock.

A meter used to be read by a person walking a route, a handful of times a year, with estimates filling the gaps between visits. Interval metering replaced that with a stream. The pack's own description of the resulting estate is a rich data set of near-real-time metered consumption data together with other real-time and reference sources.

The multiple between those two cadences is obviously large. The document does not quantify it and I will not put a figure on it either, because the number is not what carries the argument. A change of that size is not a faster version of the old measurement. It is a different measurement wearing the old one's name, and every system downstream was built for the old one. Billing engines expected a handful of rows a year and got a stream. Field operations expected a customer phone call and got a signal that might, or might not, be an outage.

Finance and communications had been through this already, with card authorisation and call detail records. Both rebuilt around continuous measurement and both paid in definitional work first. Utilities arrived at the same door later, with the same misconception: that the constraint would be storage and analytics rather than meaning.

The first use of a faster clock is always the old job, done better

The pack is candid about where the value was expected to land. Smart meters, it says, will undoubtedly result in more accurate billing and improved customer service, but to realise the full potential of the data, suppliers must look beyond the meter readings.

Accurate billing is the old job, and estimated bills were the defect the old cadence produced. Removing them is the smallest thing continuous measurement can do.

So the advice to look beyond the readings is right, and it is the hardest sentence in the pack to act on, because it requires knowing which decision you want the reading to change. Nothing in a metering programme forces anyone to answer that.

The most useful line in the pack is a use that was ruled out

Buried in a card on distribution automation is the passage I would put in front of any executive about to fund a data programme. The team assessed whether automated meter reading data could feed the outage management system, so outages could be captured before a customer picked up the phone. It was ruled out of the initial implementation because of quality limitations. What went live was narrower: the meter was pinged to detect whether service had been restored, saving a truck roll on individual outages where a customer's own breaker had tripped.

That pair is the lesson. Continuous arrival is not fitness. The data showed up on time, in volume, from every point on the network, and it still could not be trusted to say that a customer had lost power. Latency was solved. Coverage was solved. Trustworthiness for the specific decision that mattered was not, and no amount of additional volume was going to fix it.

Look at what separates the two uses. Confirming restoration verifies an event already known to exist and already owned, and if the meter is wrong a person is standing there to notice. Detecting an outage generates the event itself, with no witness. It has to be right when nobody is looking, and a false positive dispatches a crew. The same stream is adequate for one and inadequate for the other. The difference is entirely in the consequence hanging off it.

That is the judgment MLOps vocabulary was invented to support and is routinely used to avoid. A feature store records where a value came from and what it means; a lineage graph records what happened on the way. Neither tells you whether a value is good enough for the decision about to be attached to it. That is answered per decision, not per pipeline.

The sector had already run this play once

The same pack contains a card on geographic information systems, and the diagnosis there is almost word for word the one it gives for metering. Many utilities that had implemented GIS, it says, struggled to realise the full potential the technology has to offer, and determining the real tangible business value, communicating it to executives and delivering on it continued to be a challenge.

The pattern predates the meter.

Across the pack's cards on smart grid, smart meters, distribution automation and mapping, not one return figure appears. The card that does carry them is workforce automation, which cites utility organisations reporting a 23% increase in service level agreement compliance and a 10% to 20% improvement in field force productivity from adopting mobile workforce technology. Those are industry figures quoted in a sales document, not measurements we made or verified, and I would not build a case on them. The direction still holds: the quantified gains sit where work was reorganised around the new data, the unquantified ones where the data was collected and admired.

Measurement is cheap. Rearranging the work in response is not.

Latency was solved. Coverage was solved. Trustworthiness for the specific decision that mattered was not, and no amount of additional volume was going to fix it.

The sectors that set the clock were not asked permission

A customer card in the pack completes the argument. Customers, it notes, are being conditioned by very large system-driven service providers to expect self service, because for those firms contact is a cost line and information has to reach the customer at the lowest marginal cost available. Its counter-case: a utility cannot afford to explain a high bill through a twenty-two minute phone call.

That is how a sector loses control of its own timetable. Retail set the expectation. Finance and communications made the operational move. The customer then arrived at the utility already trained, and the utility's cadence was the one thing it had not thought to change.

Elsewhere the pack notes that a home energy display developed in one of its programmes was moving into a wide-scale rollout with a European energy retailer. The device shows the household its own consumption in real time. So the retailer handed the customer a continuous view of the thing it had only just learned to see continuously itself. Both parties were new to the cadence at the same moment.

What I would do differently, in order

Name the decision before the data. Not the use case, the decision: the thing currently decided by a person, on a schedule, with a known failure mode. Outage dispatch qualifies. Analytics does not.

Then ask what the decision needs the data to be right about, and whether anyone would notice if it were wrong. That question separates the confirmation uses that ship from the detection uses that get ruled out, and it is cheap to ask before the integration is built.

Then fix the definitional layer: what an interval is, what a gap means, which estimate is authoritative when a reading is missing, and who owns the answer. None of that needs a data scientist and all of it has to land before one is worth hiring. Straight-through processing has the same dependency, since no routing decision can be automated on a field whose owner is undefined.

Then, and only then, model. The modelling end has never been cheaper: pipelines are assembly work, deployment is close to solved, and the first language model pilots crossing my desk stand up in days. That is exactly why the measurement layer deserves more scrutiny than it used to get, not less.

This ordering is what our Consult team argues about in the first week, and why RealAI's Platform engagements open on definitions rather than dashboards. The sectors that went real time early did not do it better than utilities. They did it earlier, and absorbed the definitional cost while their volumes were still small.

Source material is a utilities sector capability pack produced by another consulting firm for its own consultants, several of its cards still carrying unfinished editorial notes. Nothing in it is work we delivered, and its quantified figures are industry claims or that firm's account of its own engagements, not outcomes we produced or verified. Client and firm identities are withheld. The reading of the cadence change as the event, and of the ruled-out outage detection as the honest test of readiness, is ours.

Continuous arrival is not fitness. The data showed up on time, in volume, from every point on the network, and it still could not be trusted to say that a customer had lost power.

Get in touch

Put RealAI’s applied-AI team on your hardest data problem.

We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.

Next step

Ready to make AI real?