Energy & UtilitiesReadiness & Transformation Roadmap

Utilities AI transformation accelerators: what actually shortens the delivery clock

AI transformation accelerators are reusable assets and pre-cleared permissions that shorten the time between a utility approving an AI decision and that decision running in an operational system. In utilities the binding delay is rarely model build time. It is data access, security review, integration and assurance evidence — the segments most vendor accelerators never touch.

Energy & Utilities · Readiness & Transformation Roadmap

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 20 August 202655 min read

Key takeaways

An AI transformation accelerator is a reusable asset that removes elapsed time from a named segment of the delivery clock. If you cannot say which segment it compresses and by how many days, it is a demonstration, not an accelerator.
In a utility, model build is usually the shortest segment of the clock and the only one most vendor accelerators touch. Data access, security review, integration into the ADMS or OMS, and assurance evidence dominate the elapsed time and are where the reusable assets are rarest.
Accelerators are made, not bought: an asset only becomes an accelerator on its second use, when a team that did not build it inherits it without help. Anything used once is a project artefact.
Every accelerator decays. A standing security case, a served network model and an integration adapter all have half-lives measured in months to a couple of years, and an expired accelerator is more dangerous than a missing one because delivery plans still assume it.
The credible speed claim in utilities is a second and third delivery that costs a third of the first — not a first delivery that beats physics. Transformer and line lead times, per the IEA, have moved the other way.

Abbreviations used on this page

ADMS: Advanced distribution management system
SCADA: Supervisory control and data acquisition
EMS: Energy management system (transmission control)
OMS: Outage management system
DERMS: Distributed energy resource management system
AMI: Advanced metering infrastructure (smart meters)
GIS: Geographic information system — the network asset and connectivity record
CIS: Customer information system
OT: Operational technology — the control and protection estate
CIM: Common Information Model, the IEC network-model exchange standard
NERC CIP: North American Electric Reliability Corporation Critical Infrastructure Protection standards
RIIO: Ofgem's Revenue = Incentives + Innovation + Outputs price-control framework

What AI transformation accelerators are in a utility

A definition, the eight segments of the delivery clock, and the difference between the first delivery and the third one on a paved road.

AI transformation accelerators are reusable assets and pre-cleared permissions that remove elapsed time from a named segment of the delivery clock — the interval between a utility approving an AI-supported decision and that decision running against live data in an operational system. An accelerator is defined by what it removes, not by what it contains. If nobody can say which segment it compresses and roughly how many days it takes out, it is a demonstration, a template or a licence, but it is not an accelerator.

That definition is unusually strict for a reason particular to this industry. In a distribution or transmission business, the delivery clock is dominated by segments the delivery team does not own: getting data out of the OT estate, passing cyber-security review, obtaining an accurate network model, securing a change window on the ADMS or OMS, producing assurance evidence, and revising control-room procedure. Model build — the segment nearly every commercial accelerator addresses — is typically the shortest of the eight. Compressing it is real work with a small ceiling.

So the honest claim on this page is not that AI makes utility transformation fast. Physical lead times are moving the other way: the IEA reports (opens in a new tab) that building new transmission lines takes four to eight years in advanced economies, and that wait times for critical grid components such as transformers and cables have doubled in the past three years. The claim is narrower and more useful — that a utility's second and third AI deliveries can cost a third of the first, and that the difference is entirely in assets built deliberately during the first one.

Why accelerator value arrives late and then compounds

Elapsed time removed per delivery, plotted against deliveries completed. The first two deliveries return almost nothing, because everything is being built for the first time and reuse is by copy. The inflection is at stage 4, when permission segments start being inherited rather than repeated. This is why programmes measured on pilots completed rather than clock removed look busy and stay slow.

Elapsed clock removed per delivery by stage

Stage 1 · Heroic — 22% of operators. Every AI delivery is hand-built end to end, and speed depends on which individuals are assigned to it.
Stage 2 · Kitted — 34% of operators. Vendor accelerators and demonstration kits are in use, and they compress the segment that was never the constraint.
Stage 3 · Templated — 27% of operators. Internal templates and patterns exist and get copied, but a person still reassembles each delivery by hand.
Stage 4 · Paved — 13% of operators. A paved delivery route exists: data path, security case, network model, adapters and evidence are inherited rather than rebuilt.
Stage 5 · Compounding — 4% of operators. Accelerators are managed as products — versioned, measured, revalidated and retired — and delivery cycle time is a governed number.

Curve shape: logistic, plotted from the stage data above. Distribution: Shape consistent with the IEA's Energy and AI analysis of adoption barriers.

The same seven segments, unpaved and paved

The top lane is a first-of-kind delivery in a regulated utility: every segment is negotiated from scratch. The bottom lane is the third delivery once accelerators exist — six of the seven segments are inherited, and the one that barely changes is model build. The dashed arrows are the conversion work: turning a one-off artefact into something a second team can inherit.

Data & feeds
Where value leaks
AI / model
System-of-record action
Human in the loop

The process, in words

On a first-of-kind delivery, every segment is negotiated alone: an extract is hand-produced from the historian, a risk assessment is written from a blank page, connectivity is reconstructed from a GIS export, the ADMS or OMS integration is engineered specifically, the evidence pack is assembled from screenshots, and the benefit is argued after the fact because no holdout was designed.
On a third delivery over a paved road, six of the seven segments are inherited. The workload declares itself against an approved class instead of opening a new assessment; the network model is queried rather than rebuilt; the write-back is adapter configuration with a tested revert; the evidence pack falls out of the pipeline; and the benefit is measured against a holdout agreed before go-live.
The segment that does not shrink is model build. That is the argument of the whole page: the accelerators worth having are the ones that convert permission and integration work into inheritable assets, and the market sells almost exclusively into the segment that was never binding.
The dashed arrows are the only work that creates an accelerator. Each is a deliberate act during a delivery — generalising a data path so it covers a class of workloads, getting a security case approved as a class rather than a case, hardening an integration into an adapter with a revert, and making the pipeline emit the evidence a reviewer asks for.

Step-by-step insights

The hand-produced extract, and why it caps everything after it: A one-off extract from the historian or the AMI head-end feels like the pragmatic route to a first result, and it is — for a first result. It is also unrepeatable by construction: it carries no lineage, no refresh, no agreed scope and no security decision that a second workload can point at. Everything downstream inherits those absences. The delivery that follows cannot be fresher, better governed or faster to approve than the export habit underneath it, which is why the read-only data path is the first accelerator in almost every utility we look at, ahead of any modelling investment.
Blank-page security cases are the most repeated work in the estate: OT security teams are not slow; they are asked the same question repeatedly in slightly different words. Each AI workload arrives as a novel case with its own architecture diagram, its own data flows and its own claims about isolation, so each attracts a full assessment. The compression is available in classification rather than in speed: define a workload class — read-only, no control path, egress from a defined zone to a defined analytics zone — get that class assessed once with stated conditions, and let later workloads declare conformance. That converts a months-long segment into a days-long one without weakening a single control.
Network context is where correctness lives, not just speed: A recommendation computed against a stale connectivity model is not slow, it is wrong, and in a distribution business the model changes constantly through switching, reconfiguration and new connections. Serving the network model — a CIM-conformant representation with the asset register and current topology, queried rather than exported — removes a 30-to-50-day segment from every delivery and simultaneously removes a whole class of silent errors. Utilities routinely discover the second benefit was worth more than the first.
Model build is short, and honest programmes say so: For most utility decisions, once the data and context exist, the modelling work is weeks: load and constraint forecasting, asset-health scoring, vegetation risk, outage-restoration estimation. These are well-characterised problems with published literature and mature tooling. Saying so out loud is important, because it reframes the investment argument away from data-science capacity and towards the permission and integration segments where the elapsed time actually sits. It is also the claim that lets you interrogate a vendor accelerator honestly.
Evidence should be a by-product, never a project: Assurance packs assembled by hand cost weeks per delivery and are always slightly out of date, because the model they describe kept moving after the screenshots were taken. A pipeline that emits lineage, validation results, drift history and the decision log as artefacts turns the review into a read rather than a rebuild, and it maps cleanly onto the functions of a published framework such as the NIST AI Risk Management Framework or an ISO/IEC 42001 management system. Map it once and the mapping survives changes in who is asking, which is worth more than any single review it supports.
Where the compression is NOT available: Two segments resist acceleration and should be planned at full cost. Control-room change contains irreducible human time: procedures must be revised, operators briefed and competency signed off, and compressing that is how you get a model nobody trusts at three in the morning. Benefit attribution also has a floor, because a holdout needs enough operating time to say something. Programmes that squeeze these two are not accelerating; they are borrowing from the segments that determine whether the deployment survives its first bad night.

One boundary is worth setting early. How deeply a model is allowed to touch the network — read-only, advisory, or acting through an engineered scheme — is a separate question with its own ladder, covered in the grid roadmap for AI integration. This page assumes that decision has been made and asks a different one: given the integration depth you have chosen, what makes the next delivery of it faster than the last?

The five stages of accelerator maturity in detail

For each stage: what it looks like on the ground, the diagnostic signals a reviewer can check in an afternoon, the anti-pattern that traps utilities there, and what leaving costs.

The ladder below measures one thing: what a delivery inherits from the deliveries before it. Stage names describe the mechanism of reuse, not the sophistication of the models — a utility running advanced forecasting can sit at stage 1 if every delivery rebuilds its own data path, and a utility running modest models can sit at stage 4 if six of its seven segments are inherited.

Select a stage

Every stage's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Heroic

22% of operators sit here

Every AI delivery is hand-built end to end, and speed depends on which individuals are assigned to it.

Stage 1 is not slow because the people are slow. It is slow because nothing built in the last delivery is available to the next one in a form anybody else can pick up. Every project re-negotiates access to the historian, re-writes a risk assessment that closely resembles the last one, re-derives the connectivity model from a GIS export, and re-invents a way of getting an answer in front of a control engineer. The work is genuinely done well and it amortises nothing.

The tell is conversational rather than technical. Ask three people how long the last AI delivery took and you will get three sincere, different answers, because there is no agreed start event and no agreed finish event. Some measure from the funding approval, some from the kick-off, some from the first line of code. Without an agreed clock there is no way to notice that six of the eight segments were waiting rather than working.

Utilities stay at stage 1 longer than comparable industries for a structural reason: the segments that dominate the clock are owned by people outside the delivery team. Cyber security owns the review. Control-system engineering owns the ADMS change window. The network data team owns the model. A delivery team can be excellent and still have very little influence over 70% of its own elapsed time, which is exactly why the first accelerator is never a modelling tool.

In practice

The fourth data request

A distribution business had run three AI deliveries in two years: a vegetation-risk model, an LV transformer loading study and a fault-prediction trial. Each one raised its own request for historian and AMI data. Each one triggered a full risk assessment from the OT security team, because nothing about the previous approval had been written in a form that a new workload could inherit. By the fourth request the security team had, quite reasonably, started asking why a pattern had never been agreed.

What it looks like

Each delivery negotiates its own OT data extract from scratch
Nobody can state how long the last delivery took, by segment
The engineer who built the last model is the reason it exists
Reuse happens by copying files out of somebody's home directory

Diagnostic signals you can check this week

Ask for the elapsed days of the last delivery split into segments — at stage 1 nobody has the timestamps
Count the number of separate OT data extracts serving analytics today; more than three means each was negotiated alone
Ask whether any part of the last security submission was reused in the next one
Look for a delivery whose only route into production is one named engineer's laptop configuration

Anti-pattern · Buying a platform to fix a queue

The instinctive response to a slow first delivery is to procure a platform, on the theory that the tooling is the constraint. It rarely is. If 60% of the elapsed clock was spent waiting for a security decision, a network model and an ADMS change window, a new platform adds a migration to the same queue. Time one real delivery segment by segment first. The platform decision becomes obvious, and much smaller, once you know which two segments actually held the work.

What holds you here

There is no agreed clock, so the segments that actually consume the year are invisible and nothing can be prioritised for compression.

Highest-leverage next move

Reconstruct the elapsed clock of your last completed AI delivery from approval and change-record timestamps, split across the eight segments, and publish it.

Cost of leaving

Effort: 1 quarter
Team: One delivery lead and one OT security contact, part-time
Risk: Low — timing an existing delivery changes nothing in production
To next stage: 2–4 months

If this is you, the next step is

A two-week exercise against your change records; you keep the segment clock.

Time one delivery, segment by segment

Stage 2

Kitted

34% of operators sit here

Vendor accelerators and demonstration kits are in use, and they compress the segment that was never the constraint.

Stage 2 feels like acceleration and measures like a plateau. A vendor kit arrives with pre-built pipelines, a sample asset-health model and a slick interface, and it genuinely does compress model build from six weeks to two. The trouble is arithmetic: model build was 35 days of a 400-day clock. Halving it moves the programme by four per cent while the security review, the network model and the ADMS change window sit exactly where they were.

The second problem is ownership of the clearance. The demonstration usually runs in the vendor's environment or a cloud tenancy stood up under a temporary exception, on a copy of data that was exported once by hand. None of that survives the transition to production, and the exception frequently expires before the business case does. Utilities regularly discover that the fastest part of the programme produced the least reusable asset.

Stage 2 is worth passing through and dangerous to settle in. A kit is a good way to find out whether a decision is tractable at all. It becomes a trap when a second and third kit are bought to fix a velocity problem the first kit did not fix, because each new kit brings its own environment, its own data copy and its own exception — three more things to approve, not fewer.

In practice

The asset-health kit that never left the tenancy

A network operator licensed an asset-health accelerator that shipped with transformer dissolved-gas models and a ready-made dashboard. A working demonstration was standing in five weeks against a one-off extract. Fourteen months later it had still not run on live data: the tenancy sat outside the approved architecture, the extract had no repeatable path, and the security submission for a permanent path had never been written because the kit was presented as the thing that removed that work.

What it looks like

One or more vendor accelerator packs are licensed and in use
Proofs of concept reach a demonstration in weeks
The demonstration environment holds a copy of the data, not a path to it
Nothing from the demonstration is approved to run inside the OT estate

Diagnostic signals you can check this week

Ask whether the accelerator runs on your infrastructure under your credentials, or on someone else's
Check whether the demonstration data arrived by an approved path or a hand-made export
Ask what the kit removed from the security, integration and assurance segments — usually nothing
Look for an expiry date on the exception the demonstration environment runs under

Anti-pattern · Buying a second kit to fix the first kit

When the first accelerator does not shorten delivery, the natural read is that it was the wrong accelerator. Buying another one compounds the problem: every kit is another environment to approve, another data copy to justify and another set of credentials to manage. The clock gets longer, not shorter. Before the next procurement, insist on a single line in the business case naming the segment it compresses and the days it removes, then check that segment against your measured clock.

What holds you here

The kits compress model build, which is the shortest segment, and leave the permission and integration segments entirely untouched.

Highest-leverage next move

Convert one thing the kit needed — the data path — into a permanent, approved asset a second delivery can inherit without a new submission.

Cost of leaving

Effort: 1–2 quarters
Team: Delivery lead, OT security architect, a data platform engineer
Risk: Medium — the first permanent data path is a real security decision, not a tooling choice
To next stage: 2–3 quarters

If this is you, the next step is

We map each licensed kit to the segment it actually compresses; the map is yours.

Audit your accelerators against the clock

Stage 3

Templated

27% of operators sit here

Internal templates and patterns exist and get copied, but a person still reassembles each delivery by hand.

Stage 3 is real progress and it has a ceiling built into it. Templates lower the cost of starting: a new delivery clones a working repository, lifts the previous risk assessment, and reuses the shape of the last ADMS integration. Elapsed time falls, typically by a quarter to a third, and the delivery team can feel the difference. What does not happen is compounding, because each copy immediately becomes a fork.

The consequence shows up on the fourth or fifth delivery. Five slightly different copies of the ingestion pattern exist, three of them carrying a bug that was fixed once in one place. The security team now sees five workloads that resemble each other but differ in ways that matter to a risk assessment, so each still gets a full review. Copy-based reuse buys a one-off discount and then charges maintenance on every fork.

The distinguishing move out of stage 3 is not more templates. It is converting the two or three highest-value templates into services with a version, an owner and a consumer — a data path you request rather than rebuild, a network model you query rather than export, an evidence pack the pipeline emits rather than a document somebody writes. That is the difference between a pattern and a paved road.

In practice

Five forks of one ingestion pattern

An operator had a well-regarded internal template for pulling SCADA and AMI data into an analytics zone. Four teams had cloned it. When a change to the historian's tag naming landed, the platform team fixed their copy in a day; the four clones broke silently over the following fortnight and were repaired independently, twice with different assumptions about missing intervals. The template had removed the first day of work from four projects and added a permanent maintenance liability across five.

What it looks like

A repository of reference implementations exists and is used
Security submissions start from a previous one rather than a blank page
Reuse is by copy, so improvements do not propagate back
The second delivery is meaningfully faster; the fifth is not faster than the second

Diagnostic signals you can check this week

Search your repositories for the same ingestion or evaluation code in more than two places
Ask whether a fix to the reference implementation reaches the deliveries that copied it
Compare the segment clock for delivery two and delivery five; if they are the same, reuse has stopped compounding
Ask the security team whether recent submissions were reviewed as a class or individually

Anti-pattern · Standardising the template instead of serving it

The usual response to fork drift is governance: a standards document, a review board, a mandate that everyone use the approved template. It fails quietly, because copying remains the only mechanism available and a mandate does not change what a copy is. Pick the two templates with the most forks and turn them into something consumed rather than copied — an endpoint, a registered path, a generated artefact. One served asset removes more elapsed days than ten mandated documents.

What holds you here

Reuse happens by copying, so improvements do not propagate, forks multiply, and the discount stops growing after the second delivery.

Highest-leverage next move

Promote the two most-copied templates into versioned, owned services with a consumer list — starting with the OT data path and the network model.

Cost of leaving

Effort: 2–3 quarters
Team: A small platform team, control-system engineering, the assurance owner
Risk: Medium — the first served asset must be operated, monitored and supported like production
To next stage: 3–4 quarters

If this is you, the next step is

We pick the two with the most forks and design the served version with your platform team.

Turn your two best templates into services

Stage 4

Paved

13% of operators sit here

A paved delivery route exists: data path, security case, network model, adapters and evidence are inherited rather than rebuilt.

At stage 4 the clock changes shape. The permission segments — data access, security review, network context and assurance evidence — collapse from months to days, because each has a standing artefact behind it that a new delivery inherits by declaring itself in scope. Model build barely moves, which is the point: it was never the constraint. A delivery that took thirteen months now takes four or five, and almost none of the saving came from the modelling work.

The organisational signature is a different conversation in the delivery review. Teams stop discussing whether a decision is technically feasible and start discussing whether the operational change is worth making. Control-room capacity, procedure revision and operator competency become the visible limits, because they are the only segments that still contain irreducible human time. That is a healthy place for the constraint to sit and it is where it should stop.

Stage 4 introduces a liability that stage 3 did not have: dependency. Five deliveries now assume the standing security case is current, the served network model is accurate and the adapter matches the ADMS version in production. When one of those assumptions expires quietly, the failure is not local — it is a portfolio-wide stall that nobody predicted because the plans were built on inherited assets nobody was watching.

In practice

The fourth delivery that fitted inside a change window

A network operator with a standing read-only data path, a served CIM-conformant network model and a tested OMS adapter took an approved constraint-forecasting decision from funding to live in eighteen weeks. Nine of those weeks were control-room change: procedure revision, operator briefing and competency sign-off. The security review took four days, because the workload declared itself against an already-approved class rather than opening a new assessment.

What it looks like

A new workload inherits the OT data path by declaration, not by submission
The assurance pack is emitted by the pipeline rather than assembled by hand
Integration into the ADMS or OMS is adapter configuration, not bespoke engineering
The segment clock is published per delivery and visibly falling

Diagnostic signals you can check this week

Ask how a new workload gets OT data — if the answer is a form referencing an existing approval, you are here
Check whether the last assurance pack was generated or written
Compare the segment clocks of deliveries one and four; the permission segments should have collapsed, model build should not have
Ask which accelerators the next three deliveries depend on, and when each was last revalidated

Anti-pattern · Treating the paved road as finished infrastructure

Once the road exists it stops attracting attention, and the maintenance budget quietly goes to new deliveries. Standing approvals lapse, the served model drifts from the as-built network, the adapter falls behind an ADMS upgrade. Nothing breaks visibly, because each delivery still starts by assuming the road is there — right up to the day a security reviewer points out the approval covered a network architecture that changed eight months ago. Fund maintenance as a named line, not as spare capacity.

What holds you here

Multiple deliveries now depend on shared assets that nobody is funded to maintain, so an expiry becomes a portfolio stall rather than a local problem.

Highest-leverage next move

Put every accelerator in a registry with an owner, a version, a consumer list and a revalidation date, and make the delivery gate read it.

Cost of leaving

Effort: 3–5 quarters cumulative
Team: Platform team, OT security owner, control-system engineering, assurance owner
Risk: Higher — several deliveries now share single points of failure that are administrative, not technical
To next stage: 4+ quarters

If this is you, the next step is

We check every inherited asset your next three deliveries depend on, and its expiry.

Stress-test the road your plans assume

Stage 5

Compounding

4% of operators sit here

Accelerators are managed as products — versioned, measured, revalidated and retired — and delivery cycle time is a governed number.

Stage 5 is narrower than the name suggests. It does not mean AI everywhere; it means the supply of AI deliveries has stopped being the limiting factor, and the organisation has the instrumentation to know that. Cycle time per delivery, reuse rate, inheritance depth and the age of each standing approval are reported alongside capital delivery metrics, so a decaying accelerator is visible as a rising number rather than as a surprise in a review.

The discipline that defines the stage is retirement. Accelerators built for one architecture outlive their usefulness — a data path designed for an on-premises historian after a cloud migration, an adapter for an ADMS version two releases back, a security case written before a standards revision. Stage 5 organisations retire these on a plan, with a stated condition and a migration path, rather than leaving them in place until something fails.

The stage is also the easiest to lose. Reorganisations move accelerator owners; a price-control period ends and the maintenance line disappears with it; a merger doubles the estate the served network model is supposed to describe. Sustaining stage 5 is closer to asset management than to software engineering, which is convenient, because asset management is a discipline every utility already has and can borrow from directly.

In practice

The retirement that was planned two quarters ahead

An operator migrating its historian to a new platform announced the retirement of the existing read-only data path two quarters before the cut-over, listed the eleven consumers from the registry, and published the replacement path with an overlap window. Nine consumers migrated inside the window. The two that did not were dependencies of a programme that had never registered, which is precisely the exception the registry is designed to surface.

What it looks like

Every accelerator has an owner, a version, a consumer list and a revalidation date
Cycle time and reuse rate are reported to the same forum that reviews capital delivery
Accelerators are retired deliberately, with a migration path for consumers
The binding constraint has moved off delivery onto demand and operational change capacity

Diagnostic signals you can check this week

Ask to see the accelerator registry, then check whether the delivery gate actually reads it
Ask when an accelerator was last retired, and whether consumers were migrated or stranded
Check whether cycle time and reuse rate appear in the same pack as capital delivery performance
Ask who holds the maintenance budget for accelerators and whether it survives the current price-control period

Anti-pattern · Letting the registry become a catalogue

A registry that records what exists but does not gate anything becomes a catalogue: accurate, well-maintained and ignored. The value is in the coupling — a delivery cannot pass its design gate without naming the accelerators it inherits, and an accelerator past its revalidation date fails that gate automatically. Without the coupling, expiry dates are decoration and the first sign of decay is an incident.

What holds you here

Sustaining compounding is an asset-management problem: ownership, funding and revalidation survive reorganisations only if they are governed deliberately.

Highest-leverage next move

Couple the registry to the delivery gate so an expired or unowned accelerator blocks a design approval automatically.

Cost of leaving

Effort: Continuous
Team: Platform team, accelerator owners, a standing review with assurance and OT security
Risk: Concentrated — low frequency, portfolio-wide consequence, usually triggered by organisational change

If this is you, the next step is

Owners, versions, consumers, expiry — we run the portfolio review against a real delivery gate.

Review your accelerator portfolio

Where utilities actually sit on the accelerator ladder

The distribution across the five stages, and why the step from templated reuse to a paved road is the one most programmes never take.

Most utilities sit at stage 2 or 3 — kits bought, templates written, nothing yet inherited without help. The distribution below is illustrative rather than surveyed: it synthesises adoption patterns described in the research listed at the foot of this page, and the shape is the argument, not the decimals. What matters is that the mode sits where copy-based reuse has already delivered its one-off discount and stopped compounding.

Illustrative distribution of utilities across the five accelerator stages

Stages 2 and 3 hold roughly six operators in ten. The transition from stage 3 to stage 4 is the largest single loss on the ladder, because it requires assets to be operated and supported rather than copied — a funding decision, not an engineering one.

Share of utilities

22% — 1 · Heroic
34% — 2 · Kitted (the mode)
27% — 3 · Templated
13% — 4 · Paved
4% — 5 · Compounding

Source: Illustrative distribution, synthesised from IEA, Eurelectric and EPRI research on utility digitalisation

The reason the stage 3 to stage 4 step is rare is that it is not a technical decision. Serving a network model or operating a standing data path means running something with a support rota, a version and a consumer list — the same commitment as any other operational system, made on behalf of deliveries that have not been funded yet. In a business that plans capital in multi-year price-control periods, that is a governance conversation about how network investment is allowed for (opens in a new tab), not a sprint-planning one. It is also why the utilities that clear the step are usually the ones whose regulator or system operator has already made shared assets normal, as ENTSO-E has with the Common Information Model (opens in a new tab) and NESO with its data portal (opens in a new tab).

The pressure to clear that step is not internal. Load growth, connection queues and the grid build-out described in the IEA's Electricity Grids and Secure Energy Transitions (opens in a new tab) arrive on a schedule the delivery organisation does not control, and the underlying demand and capacity trends are visible in the published statistics — EIA electricity data (opens in a new tab) in the United States, IRENA's capacity reporting (opens in a new tab) globally. A programme whose tenth AI application costs what its first one did will not keep pace with any of it, whatever the quality of the models.

The delivery clock: where a utility AI year actually goes

Eight segments, who owns each one, what it waits on, and the accelerator that compresses it. This is the page's central instrument.

A first-of-kind AI delivery in a regulated utility takes roughly a year of elapsed time, and about a tenth of it is model building. The decomposition below splits that year into eight segments defined by who has to say yes. It is elapsed time, not effort: a segment can consume six weeks while consuming four days of work, because it is sitting in someone else's queue. That distinction is the whole reason accelerators exist, and the reason the ones that help are rarely the ones being sold.

Illustrative elapsed days per segment, first-of-kind delivery

An illustrative decomposition of roughly 400 elapsed days for a first-of-kind delivery in a distribution business. Segments overlap only slightly, because each waits on a different approver. Model build is highlighted because it is the segment nearly every commercial accelerator addresses and the shortest of the eight.

Elapsed days

45 days — Scope and funding
60 days — OT data access
55 days — Security review
40 days — Network context
35 days — Model build and validation (the segment vendor kits compress)
70 days — Integration into ADMS/OMS
50 days — Assurance evidence
45 days — Control-room change

Source: Illustrative decomposition; lead-time and permitting context from the IEA's Energy and AI report

Segment	Who has to say yes	What it waits on	The accelerator that compresses it	Failure mode if unpaved
Scope and funding	Investment committee, regulatory finance	The capital cycle and the benefit case	A standing benefit-case template with agreed measurement	The case is rewritten from scratch and lands after the funding window
OT data access	OT security, historian and AMI owners	A decision about egress from the control estate	A pre-cleared read-only data path with a defined scope	Every workload negotiates its own extract and none is repeatable
Security review	OT cyber security, CIP or equivalent compliance owner	Risk assessment of a workload treated as novel	A standing security case for an approved workload class	Reviewers answer the same question repeatedly in different words
Network context	Network data, GIS and asset-register owners	An accurate, current connectivity and asset model	A served, CIM-conformant network model queried on demand	Recommendations computed against a stale topology, silently wrong
Model build and validation	The delivery team	Data, context and a definition of good	A feature and measurement library, plus a shadow-run harness	Least of the eight; over-invested in because it is the visible one
Integration into ADMS/OMS	Control-system engineering, change advisory board	A change window on a control-room system	A tested integration adapter with a one-switch revert	Bespoke engineering sits in a change queue for two quarters
Assurance evidence	Model risk, assurance, sometimes the regulator	A pack describing what was built and how it behaves	An evidence pipeline emitting lineage, validation and decisions	Weeks of hand assembly per delivery, always slightly out of date
Control-room change	Control-room manager, training and competency	Procedure revision and operator readiness	A change kit: procedure diff, brief, alarm check, sign-off route	Deployment lands on operators who were told about it, not trained

The eight segments of a utility AI delivery clock. 'Waits on' names the queue the elapsed time is actually spent in; the accelerator column names the asset that converts a repeated negotiation into an inheritance.

Two things stand out when a real clock is reconstructed rather than estimated. The first is that the four permission segments — data access, security review, network context and assurance evidence — usually total more than half the year, and every one of them is repeated in full on the next delivery unless something is deliberately made inheritable. The second is that the longest single segment is normally integration, because it is the only one that requires a change window on a system the control room depends on.

Segment	First delivery	Third delivery, paved	What carried across
Scope and funding	45	30	A benefit-case template with an agreed measurement plan
OT data access	60	5	The standing read-only path, extended by declaration
Security review	55	10	Conformance to an approved workload class
Network context	40	5	The served network model, queried not exported
Model build and validation	35	30	Feature library and shadow harness — a small saving, honestly stated
Integration into ADMS/OMS	70	20	The adapter, its revert and an accepted change record
Assurance evidence	50	10	The evidence pipeline's generated pack
Control-room change	45	25	The change kit; the residue is irreducible operator time
Total elapsed	400	135	Six segments inherited, one unchanged, one partly reduced

The same eight segments on a third delivery once accelerators exist. Illustrative days, same delivery shape as the chart above. Total elapsed time falls by roughly two thirds; model build barely moves.

Read the two right-hand rows together and the strategic point is unavoidable. A vendor accelerator that halves model build takes 17 days out of 400. The four permission accelerators take 185 days out of the same 400, and none of them is a product — each is an agreement written down once and made inheritable. That is why the accelerator conversation in a utility is mostly a conversation with cyber security, network data and control-system engineering, and only incidentally a procurement exercise.

The accelerator catalogue: nine assets worth building

What each one is, what has to exist before it can be built, how long it stays valid, and who has to own it.

Nine accelerators cover almost every recoverable day in a utility AI programme, and they are ordered below by how early they pay. Each entry names a prerequisite, a half-life and an owner, because an accelerator without all three is an artefact: the prerequisite tells you whether you can build it yet, the half-life tells you when it stops being true, and the owner is the reason it will still work when a delivery team that has never met its author tries to inherit it.

Accelerator	Segment it compresses	What must exist first	Typical half-life	Who must own it
Pre-cleared OT data path	OT data access, security review	An agreed one-way route from the historian, SCADA and AMI estate into a defined analytics zone, documented against your zone-and-conduit model	2–3 years, or the next network-architecture change	OT security, jointly with the data platform team
Standing security case	Security review	One AI workload class assessed and approved with stated conditions, so later workloads declare conformance	12–18 months, or the next standards revision	OT cyber security and the CIP or equivalent compliance owner
Served network model	Network context	A CIM-conformant network model and asset register published as a queryable service rather than a nightly export	1–2 years, and continuously for topology	Network data and GIS owner
Feature and measurement library	Network context, model build	Agreed, versioned definitions for load, weather, outage, constraint and asset-health features, with named owners	2–3 years	Data platform team
Integration adapter	Integration into ADMS/OMS/GIS	A tested write-back and fallback pattern per system of record, with a change record already accepted	18 months, or the next control-system upgrade	Control-system engineering
Evidence pipeline	Assurance evidence	Lineage, validation results, drift history and decision logs emitted by delivery tooling and mapped to a named framework	2 years, or the next regulatory change	Model risk and assurance owner
Shadow-run harness	Model validation, control-room change	A standard way to run a model against live operations with no operator exposure, and a written definition of a passed shadow run	2–3 years	Delivery platform team
Control-room change kit	Control-room change	A procedure-diff template, operator brief, alarm-philosophy check and competency sign-off route	12 months, or the next procedure revision	Control-room manager
Attribution kit	Scope and funding, benefit realisation	A holdout design and measurement plan agreed with finance and, where relevant, the regulator before go-live	2 years	Finance and regulatory reporting

The nine accelerators, with prerequisites, typical half-life and required ownership. Half-life is the period after which the asset should be revalidated rather than assumed, and is driven by estate change — historian migrations, control-system upgrades, standards revisions — not by software rot.

Three of the nine carry most of the value, and they are the three least likely to be procured.

The pre-cleared OT data path
Not a pipeline — a decision, written down in a form a second workload can point at. The artefact is an architecture and a scope: which zones, which direction, which tag ranges, what monitoring, what happens if the analytics zone is compromised. Because it is a security decision rather than a technology, it is built with the OT security team as co-author rather than as reviewer, and it is the difference between a 60-day segment and a 5-day one on every subsequent delivery. It is also the accelerator most often skipped, because the first delivery can be finished without it.
The standing security case
The mechanism is classification, not exemption. A read-only workload with no control path, egressing from a defined zone into a defined analytics zone, with logging and a stated data scope, is a class — and a class can be assessed once, with conditions, revalidation dates and triggers that force a fresh review when an assumption changes. Nothing about the controls weakens. What changes is that reviewers stop answering the same question repeatedly, which is the actual complaint most OT security teams have about AI programmes.
The evidence pipeline
Assurance work is not avoidable and it is highly compressible. If the delivery tooling emits data lineage, validation results, drift history and a decision log as first-class artefacts, the assurance pack becomes an export. Mapping those artefacts once onto the functions of the NIST AI Risk Management Framework (opens in a new tab) — or an AI management system built to ISO/IEC 42001 — gives you a stable target that survives changes in who is asking. The work is unglamorous and it removes roughly 40 elapsed days per delivery once it exists.
The one nobody builds until it hurts: the attribution kit
Agreeing the holdout and the measurement plan before go-live costs a fortnight and is almost always deferred, because at that point the benefit feels obvious. It stops feeling obvious at the first funding review, when a benefit claimed against a moving baseline cannot be defended and the next delivery is funded against that memory. In a price-controlled business the attribution kit is what lets an AI-derived benefit appear in a regulatory submission at all.

None of this sits outside existing compliance frames — it sits inside them, which is the point. The zone-and-conduit reasoning behind a pre-cleared data path is the IEC 62443 model utilities already use for industrial control security. The standing security case is written against the NERC CIP standards (opens in a new tab) for operators in scope, and against the NIST Cybersecurity Framework (opens in a new tab) for those that are not. The evidence pipeline maps to ISO/IEC 42001 (opens in a new tab) if you have an AI management system, and to your existing model-risk policy if you do not. An accelerator that requires a compliance frame to be relaxed is not an accelerator; it is a deferred incident.

What is not an accelerator, and how to tell in one question

Two tests separate a real accelerator from an expensive demonstration: does it compress a binding segment, and does it survive inside your estate?

The single most useful question to ask of any proposed accelerator is which segment of your measured clock it removes days from, and the second is whether it still works when the people who built it leave the building. Almost everything sold as an accelerator answers the first question with 'model build' and the second with 'as long as the licence and the tenancy are live'. That combination is a demonstration kit: genuinely useful for deciding whether a decision is tractable, and structurally unable to shorten a utility's delivery clock.

Sorting accelerators from demonstrations

Plot any candidate on two axes. Only the top-right quadrant changes your clock on the next delivery; the other three describe things worth having for other reasons, or not at all.

Well-kept toolbox

Durable and owned, but aimed at the short segment
Worth keeping; will not move the programme
Fix: point the same discipline at data access or integration

Real accelerator

Removes days from a segment you have measured as long
A team that did not build it has used it unaided
Has an owner, a version and a revalidation date

Demonstration kit

Fast to a demo, no path into the estate
Legitimate for testing tractability, not for delivery
Fix: use it to decide, then budget the real clock separately

Someone else's clearance

Compresses the right segment, on borrowed permissions
Consultant environments, vendor tenancies, temporary exceptions
Fix: contract for the artefacts and the approval, not the demonstration

Does it survive inside your estate? — top: Owned, versioned, runs on your infrastructure, bottom: Needs its author or its vendor

Does it compress a binding segment? — left: Touches model build only, right: Touches permission or integration

A proof-of-concept factory is not an accelerator
A standing capability that turns ideas into demonstrations quickly increases the rate at which you produce things that cannot be deployed. It compresses the segment before the clock starts. Utilities with a healthy pipeline of proofs and a stalled deployment record almost always have this pattern, and the fix is counter-intuitive: run fewer proofs, and spend the released capacity paving the path for the ones already approved.
A centre of excellence is not an accelerator
It can produce accelerators, and frequently produces standards instead. The distinguishing test is consumption: does a delivery team get something they use, or something they must comply with? A served data path is consumed. A twenty-page pattern document is complied with, and complying with it takes the same elapsed days as writing it from scratch did.
A cloud landing zone is a prerequisite, not an accelerator
Necessary infrastructure that no delivery inherits time from unless the OT egress decision has been made and approved on top of it. Utilities that build the landing zone and stop are surprised to find the data-access segment unchanged, because the queue was never about where the compute was.
A model is almost never an accelerator
Pre-trained models for asset imagery, vegetation or load can genuinely save weeks in the shortest segment. Treated as accelerators they distort the programme, because a model arrives with a data requirement, a validation obligation and an assurance footprint — three demands on segments that were already binding. Buy them, use them, and do not count them as delivery-speed investments.

Building new transmission lines can take four to eight years in advanced economies and wait times for critical grid components such as transformers and cables have doubled in the past three years.
IEA, Energy and AI

That quotation is the discipline this whole page runs on. In a sector where the physical build clock is measured in years and lengthening, a credible acceleration claim is not that AI compresses the grid — it is that a utility can stop spending three quarters of every AI delivery re-obtaining permissions it already holds. The prize the IEA describes, including the 175 GW of capacity it estimates could be unlocked by sensing and AI-based management, depends on being able to deploy the tenth application as cheaply as the second.

What shared accelerators look like in public

Three publicly documented examples of assets built once and inherited many times — a standard, an operator's open data estate, and a regulator's dissemination condition.

The clearest public evidence for the accelerator thesis is not a vendor case study; it is the places where the sector has already built shared assets and can point at what happened next. Each example below is read against the ladder on this page. None is an Atomic Loops engagement, and each links to the organisation's own published material — verify any figure at the source before reusing it.

Three shared assets, read against the accelerator ladder

Outcomes as published by the organisations themselves. The images are generated industry scenes from our library, not photographs of these organisations, and imply no endorsement.

Generated scene: a transmission operations room with network and market displays — illustrative, not a photograph of ENTSO-E

ENTSO-EEuropean association of transmission system operators14

Challenge: European transmission system operators needed to exchange network models with each other continuously for common grid model, capacity calculation and adequacy processes. Bilateral, format-by-format exchange made every new participant and every new process a fresh integration problem.
Approach: ENTSO-E standardised network-model exchange on the Common Information Model, publishing the profiles, conformance rules and supporting data and standardisation material as shared assets rather than leaving each pair of operators to agree a format.
Reported outcome: ENTSO-E publishes the Common Information Model profiles and its data and standardisation programme as the basis on which European operators exchange grid models, so a new process or participant conforms to a published contract instead of negotiating a new one.; What it shows about the curveThis is the served network model at continental scale, and it shows the mechanism cleanly: the accelerator is not software, it is an agreement written down once in a form that later work can inherit. Utilities can reproduce it internally between their own GIS, ADMS and analytics estates.

ENTSO-E — Common Information Model (opens in a new tab)

Generated scene: a distribution control room with network schematics on a wall display — illustrative, not a photograph of UK Power Networks

UK Power NetworksGB distribution network operator · ~8m customers24

Challenge: Network, asset and connection data was requested repeatedly by internal teams, connections customers, flexibility providers and researchers, with each request handled as a one-off extract and each extract arriving with its own caveats.
Approach: UK Power Networks published its network data through an open data portal with a catalogue of datasets, published licensing and registration, so that internal and external consumers draw on the same published assets rather than commissioning individual extracts.
Reported outcome: The portal operates as a standing, catalogued source of network datasets that consumers access directly, with the organisation publishing its own terms of access and reuse alongside the data.; What it shows about the curvePublishing to the outside forces the discipline that makes an asset inheritable inside: a catalogue, a licence, a refresh and an owner. Several utilities have found the internal reuse benefit of an open data programme larger than the external one.

UK Power Networks — Open Data Portal (opens in a new tab)

Generated scene: a network operations centre overlooking wind and solar generation — illustrative, not a photograph of an Ofgem project

OfgemGB energy regulator · network innovation funding15

Challenge: Innovation funded inside individual network licensees tends to stay inside them, so the same problem is solved repeatedly across a sector whose operators are regional monopolies and therefore not natural competitors on method.
Approach: Ofgem funds network innovation through its innovation programmes, including the Strategic Innovation Fund, with the expectation that funded projects share their learning across the sector rather than retaining it within the licensee that ran them.
Reported outcome: Ofgem publishes its innovation programmes and the funded project landscape, making project learning a sector-level asset that other licensees can build on rather than rediscover.; What it shows about the curveThis is stage 5 governance imposed from outside: dissemination as a funding condition is exactly the coupling between a registry and a gate that internal accelerator programmes struggle to create for themselves. Where your regulator does this, it is free portfolio discipline — use it.

Ofgem — Innovation (opens in a new tab)

The common thread is unglamorous. In all three cases the accelerator is a published contract — a model profile, a dataset catalogue, a dissemination condition — and none of them is a piece of AI technology. ENTSO-E publishes the surrounding profiles and conformance material through its data and standardisation programme (opens in a new tab), which is what makes conformance checkable rather than aspirational. Collaborative research bodies work the same way: EPRI (opens in a new tab) exists partly so that member utilities do not each pay to answer the same question, which is the sector-scale version of the argument this page makes about your own second delivery. And where an operator is in scope for NERC (opens in a new tab) standards, the reliability regime itself supplies part of the vocabulary a standing security case is written in.

The paved road, layer by layer

What has to exist for each stage, which layer you can defer, and the layer that only starts to matter once several deliveries depend on it.

A paved delivery road in a utility has six layers, and the order in which you build them decides whether the programme compounds or plateaus. The architecture below is deliberately vendor-neutral: every layer is defined by what it must guarantee to a delivery team, not by the product that provides it, because the guarantee is what a later delivery inherits and the product is what changes.

Layers of the paved road, annotated by the stage that first requires them

Each layer is annotated with the stage that first requires it. A programme aiming at stage 4 without the evidence layer is building stage 3 with better tooling — the permission segments will not collapse.

Estate access
Stage 1+
- Historian and SCADA egressRead-only, scoped, one-way, monitored
- AMI and meter dataInterval data with a defined refresh and privacy scope
- Field and inspection mediaImagery, LiDAR and inspection records with asset keys
→
Shared context
Stage 2+
- Network model serviceCIM-conformant topology, current not nightly
- Asset registerOne identifier per asset across GIS, ADMS and works management
- External contextWeather, market and constraint data with agreed provenance
→
Delivery substrate
Stage 3+
- Feature and measurement libraryVersioned definitions with named owners
- Training and servingReproducible, with an environment a reviewer can inspect
- Shadow-run harnessLive inputs, no operator exposure, defined pass criteria
→
Integration adapters
Stage 3+
- ADMS / OMS / GIS write-backInto the field the engineer already reads
- Tested revertPrevious behaviour, one switch, exercised on a quiet shift
- Accepted change recordPre-agreed with the change advisory board
→
Evidence and assurance
Stage 4+
- Lineage and validation artefactsEmitted by the pipeline, not written afterwards
- Drift and decision logsReconstructable months later, per decision
- Framework mappingMapped once to AI RMF, ISO/IEC 42001 or model-risk policy
→
Accelerator management
Stage 5+
- RegistryOwner, version, consumers, revalidation date per asset
- Delivery gate couplingA design gate that reads the registry and fails on expiry
- Retirement planStated condition, migration path, overlap window

Pipeline described

Estate access (stage 1+) — Historian and SCADA egress: Read-only, scoped, one-way, monitored; AMI and meter data: Interval data with a defined refresh and privacy scope; Field and inspection media: Imagery, LiDAR and inspection records with asset keys
Shared context (stage 2+) — Network model service: CIM-conformant topology, current not nightly; Asset register: One identifier per asset across GIS, ADMS and works management; External context: Weather, market and constraint data with agreed provenance
Delivery substrate (stage 3+) — Feature and measurement library: Versioned definitions with named owners; Training and serving: Reproducible, with an environment a reviewer can inspect; Shadow-run harness: Live inputs, no operator exposure, defined pass criteria
Integration adapters (stage 3+) — ADMS / OMS / GIS write-back: Into the field the engineer already reads; Tested revert: Previous behaviour, one switch, exercised on a quiet shift; Accepted change record: Pre-agreed with the change advisory board
Evidence and assurance (stage 4+) — Lineage and validation artefacts: Emitted by the pipeline, not written afterwards; Drift and decision logs: Reconstructable months later, per decision; Framework mapping: Mapped once to AI RMF, ISO/IEC 42001 or model-risk policy
Accelerator management (stage 5+) — Registry: Owner, version, consumers, revalidation date per asset; Delivery gate coupling: A design gate that reads the registry and fails on expiry; Retirement plan: Stated condition, migration path, overlap window

Step-by-step insights

Estate access — the layer that is a security artefact, not a data one: Everything above this layer is capped by it, and its real content is a decision rather than a technology: which zones, which direction, which tag and meter scope, what monitoring, and what happens if the analytics zone is compromised. Build it with OT security as co-author and it becomes a class that later workloads inherit. Build it as a data-engineering project and you will get a working pipeline that still needs a full risk assessment every time a second workload wants to use it, which is the most expensive possible outcome.
Shared context — the layer where correctness and speed are the same investment: A served network model removes 30 to 50 elapsed days from each delivery, and that is the smaller half of the benefit. The larger half is that recommendations stop being computed against yesterday's topology. In a distribution business, switching, reconfiguration and new connections change the model constantly, so an export-based context is not merely slow, it is periodically wrong in ways that are invisible until an engineer queries a strange recommendation. One identifier per asset across GIS, ADMS and works management is the unglamorous prerequisite most utilities discover late.
Delivery substrate — reproducibility is an assurance feature: Training and serving are commodity concerns by stage 3; what earns its place here is reproducibility a reviewer can inspect. When an assurance owner asks which data, which code and which parameters produced a deployed model, an answer that takes an afternoon to assemble costs the same afternoon every time it is asked. The shadow-run harness belongs in the same layer for the same reason: a written definition of what passed shadow means turns a subjective judgement into an artefact the control-room manager can accept.
Integration adapters — engineer the revert first: The component that unlocks an ADMS or OMS write-back is the tested revert, not the write. Control-system engineering will accept a new decision source they can instantly and provably undo, and will queue one they cannot. Building the revert first, exercising it deliberately on a quiet shift, and getting the change record accepted as a pattern turns integration from the longest segment on the clock into the second-shortest. Skipping it is the most common reason a technically finished delivery spends two quarters in a change queue.
Evidence and assurance — cheap to build early, expensive to retrofit: At stage 3 the evidence layer feels like overhead, because one delivery can assemble a pack by hand. By stage 4 it is the difference between a four-day and a forty-day segment, and by the time a regulator or a board asks for a portfolio view it is not retrofittable — you cannot generate lineage for decisions that were never logged. Map the artefacts once onto a named framework and the mapping survives changes in who is asking, which is worth more than any single review it supports.
Accelerator management — the layer that exists because the others succeeded: This layer has no purpose until several deliveries depend on shared assets, and then it becomes the difference between a portfolio and a set of assumptions. Its whole value is the coupling: a design gate that reads the registry and fails when an accelerator is unowned or past its revalidation date. Without the coupling, a registry is a catalogue, expiry dates are decoration, and the first sign of decay is a delivery discovering mid-flight that the approval it was relying on no longer covers the architecture in production.

The layer most often skipped is evidence, and it is the one that decides whether the permission segments actually collapse. A programme with a standing data path and a served network model but a hand-assembled assurance pack has removed 100 days from its clock and left 40 on the table — and those 40 are the days that reappear, without warning, whenever the assurance owner changes or the regulator asks a new question.

A 90-day plan: paving the OT data path for transformer overload risk

One accelerator, one anchor decision, one quarter. Distribution transformer thermal overload risk from AMI, SCADA and GIS — and no new model.

Building your first accelerator takes about 90 days when it is scoped to one asset and proved against one decision, and indefinitely when it is scoped as a platform programme. The plan below runs the stage 2 to stage 3 transition on a specific, near-universal distribution problem: identifying which secondary transformers are at risk of thermal overload as electric vehicle and heat pump load grows, using AMI interval data, SCADA measurements and the GIS connectivity model. Almost every utility already has a model or a study for this; the quarter contains no model development at all, because the accelerator being built is the data path.

Paving the read-only OT data path in one quarter

One anchor decision, one data path, one owner. If a phase needs more than its window, narrow the scope — fewer tag ranges, one region, one transformer class — rather than extending the plan.

Days 1–15
Time the last delivery, segment by segment
Reconstruct the elapsed clock of your most recently completed AI delivery from funding approval, security submission dates, change records and repository history, split across the eight segments. Publish it to the delivery forum. Pick the anchor decision — transformer overload risk — and name a single accountable owner for the data path, in OT security or the data platform team, not in the delivery team.
A measured segment clock and a named accelerator owner
Days 16–45
Design the path and get it approved once
Specify the read-only route from the historian, SCADA estate and AMI head-end into a defined analytics zone: direction, zone boundaries, tag and meter scope, retention, monitoring and incident behaviour, documented against your zone-and-conduit model and your CIP or equivalent obligations. Get it assessed as a workload class with stated conditions and a revalidation date — not as a project exception.
A standing, conditioned approval a second workload can declare against
Days 46–70
Prove it on the anchor decision, with the model you already have
Run the existing overload-risk analysis on data arriving through the new path rather than through an extract. Resolve the differences it exposes — missing intervals, asset identifier mismatches between AMI, GIS and the asset register, timestamp conventions. These are the real cost of the path and they are cheaper to find now than during a second delivery under time pressure.
The anchor decision running on inherited data, with the joins fixed
Days 71–90
Make it inheritable, then measure the inheritance
Register the path: owner, version, scope, conditions, revalidation date, consumer list. Write the half-page a second team needs to declare against it. Then start a second, unrelated workload through the same route and time its data-access segment against the baseline from days 1 to 15. That measured delta, not the anchor decision, is the deliverable.
A measured reuse — the first honest acceleration number you own

Three rules that keep the quarter honest

Measure before you pave
The segment clock from days 1 to 15 is what makes everything after it defensible. Without a baseline, the second delivery being faster is a claim; with one, it is a number in days that a funding committee can use. Reconstructing the clock costs a fortnight and is the single highest-return activity in the plan.
Pave the segment that is long, not the segment that is interesting
Modelling work is more enjoyable than negotiating an egress architecture, and the temptation to improve the overload analysis during this quarter is strong. Resist it: an improved model on an unrepeatable extract leaves the clock exactly where it was, and the improvement can be made any time after the path exists.
An asset becomes an accelerator on its second use
Nothing built in days 16 to 70 counts until days 71 to 90 prove a team that did not build it can inherit it. If the second workload cannot get through the path without its author, you have built a project artefact with good documentation — which is worth having, but should not be reported as an accelerator.

Two variations are common and both work. Utilities with an acute assurance bottleneck should substitute the evidence pipeline as the anchor accelerator, using the same shape: measure, build once, prove on an existing model, then time the second pack. Utilities whose longest measured segment is integration should pave one adapter into the OMS or ADMS instead — with the revert engineered and exercised first, because that is the part that clears the change queue.

Keeping accelerators alive: metrics, checklist and decay

What to measure so compression is proven rather than claimed, an eight-point test for any candidate asset, and the four ways a paved road quietly stops being one.

An accelerator programme is verified by nine numbers, all readable from records you already keep. The metrics below split into three families: the clock itself, which proves compression happened; reuse, which proves it was inheritance rather than heroics; and decay, which is the family unique to a paved road and the one that catches programmes out. Every metric names a source and a cadence, because a metric without a source system is an opinion with a decimal point.

Metric	How it is read	Source	Cadence	Honest from
Delivery clock	Elapsed days from funding approval to running in the system of record	Investment records and change tickets	Per delivery	Stage 1
Segment clock	The same elapsed days split across the eight segments	Approval, submission and change timestamps	Per delivery	Stage 2
Reuse rate	Deliveries that inherited at least one registered accelerator ÷ all deliveries	Accelerator registry	Quarterly	Stage 3
Inheritance depth	Mean number of accelerators inherited per delivery	Accelerator registry	Quarterly	Stage 4
First-time-right on security review	Submissions approved without rework ÷ submissions made	OT security review queue	Per submission	Stage 3
Evidence assembly effort	Person-hours to produce one assurance pack	Assurance owner's records	Per delivery	Stage 4
Accelerator age	Days since the asset was last revalidated against the estate	Registry	Monthly	Stage 4
Adoption of current version	Consumers on the current version ÷ registered consumers	Registry	Quarterly	Stage 5
Retirement rate	Accelerators retired ÷ accelerators registered, trailing twelve months	Registry	Annual	Stage 5

Instrumentation sheet for a utility accelerator programme. 'Honest from' is the stage at which the metric first measures something real — reuse rate means nothing before a second delivery has inherited anything.

Two of these deserve a comment. First-time-right on security review is the leading indicator nobody watches: when it falls, the standing case has drifted from what workloads are actually doing, and the segment is about to expand again. Accelerator age is the equivalent for everything else — an asset whose revalidation date has passed is not neutral, because delivery plans are still being written on the assumption that it holds.

Is it an accelerator, or a well-documented project artefact?

Eight tests. If you cannot tick all eight, the asset may still be valuable — but it will not compress your next delivery without its author. Tick as you go; this list works without JavaScript.

It compresses a segment you have actually measured as longNamed segment, measured days — not a general claim about productivity.
It runs on your infrastructure, under your credentialsNot in a vendor tenancy or a consultant's environment.
Someone who did not build it has used it unaidedThe single strongest test, and the one most assets fail.
It has a named owner with a maintenance budget
It is versioned, and the version in use is recorded per deliveryOtherwise you cannot tell which deliveries a defect affects.
Its security or assurance approval is standing, not per-projectA class with conditions, rather than an exception with an expiry.
It has a stated revalidation date in the registry
There is a written condition under which it will be retiredRetirement planned in advance is cheap; retirement discovered is an incident.

0 of 8 ticked

Nothing ticked — which is where most programmes honestly start

Zero ticks is not a failure, it is a stage-1 or stage-2 reading. Do not start by building assets; start by measuring one delivery segment by segment. Two weeks of timestamp archaeology will tell you which of the eight segments to pave first, and every later decision gets easier.

Scope a delivery-clock review

Likelihood: highImpact: high

The accelerator only its author can run

The asset works, is used on every delivery, and quietly requires a five-minute conversation with the person who built it each time. That conversation is invisible in the clock and disappears entirely when they change role, at which point three deliveries discover simultaneously that the road was a person.

PreventionAn asset is not registered until a second engineer has used it unaided, with the author unavailable.

Likelihood: mediumImpact: high

The standing approval that quietly expired

A security case approved against one network architecture, one data scope and one standards revision stops being valid when any of the three moves. Nothing breaks, because deliveries keep declaring against it — until a reviewer notices, and the segment that had fallen to four days reopens at fifty-five for everyone at once.

PreventionRevalidation dates live in the registry and are read by the design gate, so expiry blocks an approval rather than surfacing in a review.

Likelihood: highImpact: medium

Paving before there is a second traveller

A platform built ahead of demand encodes guesses as architecture: the wrong data scope, the wrong context granularity, adapters for the system nobody ends up integrating with. The cost is not the build, it is that the first real delivery must work around a road pointed in the wrong direction.

PreventionAn asset is promoted to an accelerator on its second use, never its first; before that it is a delivery artefact.

Likelihood: mediumImpact: high

The vendor kit that took the clearance home

The demonstration ran in the supplier's tenancy under a temporary exception, and when the engagement ended the environment, the credentials and the approval went with it. What remains is a slide deck and a data extract nobody can refresh, and the next delivery starts the security segment from a blank page.

PreventionContract for the artefacts and the approval — architecture, conditions, evidence — not for the demonstration.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

Delivery clock: The elapsed time between a utility approving an AI-supported decision and that decision running against live data in an operational system. Measured in calendar days, not effort, because most of it is spent waiting on approvals rather than working.
Segment: One of the eight parts of the delivery clock, each defined by who has to say yes: scope and funding, OT data access, security review, network context, model build, integration, assurance evidence and control-room change.
Accelerator: A reusable asset or pre-cleared permission that removes elapsed days from a named segment for deliveries that did not build it. An asset becomes an accelerator on its second use, not its first.
Paved road: A delivery route on which the permission and integration segments are inherited rather than repeated — standing data path, approved workload class, served network model, tested adapter and generated evidence.
Accelerator half-life: The period after which an accelerator should be revalidated rather than assumed. Driven by estate change — historian migrations, control-system upgrades, standards revisions — rather than by software ageing.
Pre-cleared data path: An approved, scoped, read-only route from the OT estate into an analytics zone that a new workload can join by declaration instead of by a fresh risk assessment. Usually the first accelerator worth building.
Standing security case: A risk assessment written for a class of AI workload rather than an individual project, carrying conditions, revalidation dates and triggers that force a fresh review when an assumption changes.
Served network model: A CIM-conformant representation of network topology and assets, published as a queryable service rather than a periodic export, so every delivery computes against current connectivity.
Integration adapter: A tested write-back pattern into a system of record such as an ADMS, OMS or GIS, shipping with a one-switch revert and a change record the change advisory board has already accepted.
Evidence pipeline: Delivery tooling that emits lineage, validation results, drift history and decision logs as first-class artefacts, so an assurance pack is exported rather than assembled by hand.
Shadow run: Running a model against live operational inputs with no exposure to operators or control actions, against a written definition of what passing means. The cheapest way to convert a subjective readiness judgement into an artefact.
Reuse rate: The share of deliveries that inherited at least one registered accelerator. The metric that distinguishes genuine compounding from a run of individually well-executed projects.

Frequently asked questions

The questions utility delivery leads, OT security architects and transformation directors ask most often about accelerating AI delivery.

What are AI transformation accelerators in a utility?

They are reusable assets and pre-cleared permissions that remove elapsed days from a named segment of the delivery clock — the time between approving an AI-supported decision and running it against live data. In practice that means a standing read-only OT data path, an approved workload class for security review, a served network model, tested integration adapters and an evidence pipeline. The defining test is inheritance: a team that did not build the asset must be able to use it without help.

Are vendor AI accelerators worth buying?

They are worth buying for what they actually do, which is compressing model build and helping you decide quickly whether a decision is tractable. They are not worth buying as delivery-speed investments, because model build is typically the shortest of the eight segments in a utility. Before any purchase, ask which segment of your measured clock it removes days from and whether it runs on your infrastructure under your credentials. If the answers are model build and no, treat it as a demonstration kit.

How long should an AI delivery take in a utility?

A first-of-kind delivery in a regulated network business realistically takes about a year of elapsed time, of which roughly a tenth is model building. On a paved road — standing data path, approved workload class, served network model, tested adapter and generated evidence — the same shape of delivery lands in four to five months. Anyone promising a first-of-kind production deployment in weeks is either excluding the permission segments or working outside the OT estate.

Which segment of the delivery clock is usually longest?

Integration into a control-room system such as an ADMS or OMS is normally the single longest segment, because it needs a change window on a system operations depends on. OT data access and security review are close behind, and together the four permission segments — data access, security review, network context and assurance evidence — usually exceed half the total. Model build is typically the shortest, which is why it is the wrong place to invest in speed.

What is the first accelerator we should build?

In most utilities, the pre-cleared read-only OT data path, because it compresses two segments at once and everything else depends on it. It is a security artefact rather than a data-engineering project: the deliverable is an approved architecture with a defined scope, monitoring, conditions and a revalidation date that a second workload can declare against. Build it with the OT security team as co-author, prove it on a decision you already have a model for, then measure a second workload's data-access segment against your baseline.

How do you get an AI workload through OT security review faster?

By changing the unit of assessment from the project to the workload class. A read-only workload with no control path, egressing from a defined zone into a defined analytics zone with logging and a stated data scope, can be assessed once with conditions, revalidation dates and triggers that force re-review when an assumption changes. Later workloads declare conformance instead of opening a new assessment. No control weakens; what disappears is the repetition that makes security teams the involuntary bottleneck.

Do accelerators conflict with NERC CIP or IEC 62443?

No — the good ones are built inside those frames rather than around them. The zone-and-conduit reasoning behind a pre-cleared data path is the IEC 62443 model already used for industrial control security, and a standing security case is written against NERC CIP obligations for operators in scope or the NIST Cybersecurity Framework for those that are not. Anything that requires a control to be relaxed or an exception to be extended is not an accelerator; it is a deferred incident with a delivery date attached.

How do you know an accelerator is decaying?

Three signals, in the order they usually appear. First-time-right on security review falls, which means the standing case has drifted from what workloads actually do. Accelerator age passes the revalidation date in the registry while deliveries keep depending on it. Then adoption of the current version falls, because consumers have started forking rather than upgrading. Any one of these is a fortnight of maintenance; all three together is a portfolio stall that will surface as an incident.

Should we build a platform before the first use case?

No. A platform built ahead of demand encodes guesses as architecture — the wrong data scope, the wrong context granularity, adapters for a system nobody integrates with — and the first real delivery then works around it. Deliver one decision end to end, deliberately generalising the data path and the security case as you go, then promote the two most-copied artefacts into served assets at the second or third delivery. That sequence produces the same platform, correctly shaped, roughly a year earlier.

How do accelerators fit a price-control funding cycle?

Awkwardly, unless they are named. Accelerators are shared assets built during one delivery for the benefit of deliveries that are not yet funded, which makes them easy to lose in a business planning capital in multi-year periods. Two things help: a benefit case that quotes cycle time and reuse rate rather than a single project's return, and an attribution kit that lets an AI-derived operational benefit appear in a regulatory submission at all. Where a regulator funds innovation with a dissemination condition, that mechanism does some of this work for you.

Who should own accelerators — IT, OT or the AI team?

It depends on the segment, and getting it wrong is the most common ownership mistake. The data path and the security case belong to OT security jointly with the data platform team, because they are security decisions. The served network model belongs to network data and GIS. Integration adapters belong to control-system engineering. The AI team should own only the delivery substrate and the shadow harness. An accelerator owned by the team that consumes it will not survive that team's next reorganisation.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for energy, utilities and heavy industry — load and constraint forecasting, asset-health and inspection models, and operator decision support running against live network data and integrated into the ADMS, OMS and GIS layer rather than delivered as dashboards.

· Delivery inside regulated OT estates, under existing change control
· Read-only OT data paths designed with utility cyber-security teams
· Assurance evidence generated by the pipeline, not assembled for the audit
· 19 cited sources on this page

Sources

Energy and Utilities industry practiceProduction AI systems Atomic Loops has built for network operators, generators and retailers.AI readiness and transformation roadmap for utilitiesThe blueprint, the integration ladder, the talent gap and the readiness framework — the rest of the sequencing decisions this page assumes.AI adoption and maturity curve in energy and utilitiesHow adoption maturity is measured across a utility estate, and what each stage can honestly claim.

Find out where your delivery clock actually goes

We reconstruct the elapsed clock of one completed delivery from your own records, split it across the eight segments, and leave you with the two accelerators that would remove the most days — costed, owned and sequenced. You keep the analysis whether or not we build anything.

Book a delivery-clock review See our energy and utilities work

Published 20 August 2026 · Last updated 20 August 2026

Key takeaways

Abbreviations used on this page

Score your delivery clock

What AI transformation accelerators are in a utility

The five stages of accelerator maturity in detail

Heroic

Kitted

Templated

Paved

Compounding

Where utilities actually sit on the accelerator ladder

The delivery clock: where a utility AI year actually goes

The accelerator catalogue: nine assets worth building

What is not an accelerator, and how to tell in one question

What shared accelerators look like in public

The paved road, layer by layer

Estate access

Shared context

Delivery substrate

Integration adapters

Evidence and assurance

Accelerator management

A 90-day plan: paving the OT data path for transformer overload risk

Three rules that keep the quarter honest

Keeping accelerators alive: metrics, checklist and decay

The accelerator only its author can run

The standing approval that quietly expired

Paving before there is a second traveller

The vendor kit that took the clearance home

Glossary

Frequently asked questions

What are AI transformation accelerators in a utility?

Are vendor AI accelerators worth buying?

How long should an AI delivery take in a utility?

Which segment of the delivery clock is usually longest?

What is the first accelerator we should build?

How do you get an AI workload through OT security review faster?

Do accelerators conflict with NERC CIP or IEC 62443?

How do you know an accelerator is decaying?

Should we build a platform before the first use case?

How do accelerators fit a price-control funding cycle?

Who should own accelerators — IT, OT or the AI team?

About the author

Sources

Related reading

Find out where your delivery clock actually goes