Energy & UtilitiesReadiness & Transformation Roadmap
The AI transformation timeline for utilities: five phases, five years, and the gates between them
An AI transformation timeline for a utility is the multi-year sequence in which capability, funding and evidence are built — typically five phases over about five years. Its pace is set not by technology but by the regulatory calendar: the price control, rate case or IRP filing that decides what can be funded, and when.
Key takeaways
- An AI transformation at a utility is a five-phase programme over roughly five years, and the phases are gated by evidence rather than by calendar. Each phase has an entry condition and an exit artefact; skipping a gate does not remove the failure, it moves it to a more expensive place.
- The binding constraint is the regulatory calendar, not the technology. A GB network funds against a RIIO price control — RIIO-T3 and RIIO-GD3 run from 2026 to 2031, RIIO-ED2 ends in 2028 and RIIO-ED3 runs 2028 to 2033 — and a US utility against rate cases and IRP filings. Work that misses its submission window waits for the next one.
- Only the first three phases reliably fit inside one five-year control period. Embed and Optimise almost always span two, so the exit artefacts of phase three have to be written as the business case for phase four in the next submission.
- Opex-funded pilots and capex-funded platform builds sequence differently. Innovation allowances buy discovery cheaply and quickly, but nothing an innovation allowance funds may become a business-as-usual dependency until it sits in a totex or rate-base allowance — which is why so many successful utility pilots are switched off.
- Hiring is the slowest line on the plan. A control-room-adjacent data engineer who can be trusted near SCADA is a six-to-nine-month hire once security clearance and OT familiarisation are counted, so recruitment starts in phase one or phase two slips by the length of the hire.
Abbreviations used on this page
- RIIO
- Revenue = Incentives + Innovation + Outputs — the GB network price-control framework
- totex
- Total expenditure — the combined capex and opex allowance a RIIO price control sets
- NIA
- Network Innovation Allowance — each licensee's own innovation budget inside the price control
- SIF
- Strategic Innovation Fund — Ofgem's competitive innovation fund, run with Innovate UK
- IRP
- Integrated resource plan — the multi-year US utility planning filing
- PUC
- Public utilities commission — the US state regulator that approves a rate case
- DSO
- Distribution system operator (the actively managed successor to a DNO)
- ADMS
- Advanced distribution management system
- EMS
- Energy management system (transmission control room)
- SCADA
- Supervisory control and data acquisition
- AMI
- Advanced metering infrastructure (smart meters and the head-end system)
- DER
- Distributed energy resources — rooftop solar, batteries, EV chargers, flexible load
Free · 8 questions · ~3 minutes
Score your programme against the timeline
Eight questions, one at a time, about three minutes. Answer them and we build your personalised timeline report — which phase your programme is actually in, your score on each of the four dimensions, and the specific gate standing between you and the next phase — and send it to your inbox. Your result also tells you which submission window you are currently running against.
0 of 8 answered
Pick an option to continue
Report ready
Your personalised timeline report is ready
Tell us where to send it. Your phase appears on screen straight away, and the full report — dimension scores, the gate that is holding you, the submission window your current phase has to clear, and a 90-day plan for your weakest dimension — arrives in your inbox.
Your result
Your full report is on its way to your inbox.
Stage 1 · Foundations
Foundations is the phase that makes operational data legible and the AI ambition fundable — no models in operations, one named sponsor, and a place secured in the next regulatory submission.
Your next moveMeasure the joins between historian, GIS and the asset register, publish the number, and write the phase-two ask into the next regulatory submission.
Stage 2 · Proof
Proof is the phase where one or two use cases demonstrate value on real operational data under innovation funding, with output still advisory and no business-as-usual dependency permitted.
Your next moveConvert the proof's baseline, decision log and benefit statement into the phase-three ask in the next price-control, rate-case or IRP submission.
Stage 3 · Scale
Scale is the phase where a proven use case is re-engineered as a funded, supported service inside the control room's own systems, with an owner, an availability commitment and a tested rollback.
Your next moveExtract the shared feed, serving and evidence layer from the first funded capability so the second is configuration, and put that platform line into the next submission.
Stage 4 · Embed
Embed is the phase where AI stops being a programme and becomes a platform line in the operating model: shared data and serving, several live decisions, and benefits appearing in the annual regulatory reporting pack.
Your next moveMake an agreed baseline and a regulatory reporting treatment part of the definition of done for every decision the platform serves.
Stage 5 · Optimise
Optimise is the steady state: the marginal cost of the next decision is low, the constraint is governance and evidence rather than engineering, and the next five years are argued for in the submission rather than defended after it.
Your next movePut the operating envelope and the baseline set on a review calendar, and retain raw logs for at least the length of a control period.
0 / 24
Sequencing discipline
— / 6
Regulatory alignment
— / 6
Capability build rate
— / 6
Benefit realisation
— / 6
Your score maps to a phase on the timeline. The dimension breakdown matters more than the total: the lowest dimension is the gate you will actually fail at, and in utilities it is far more often regulatory alignment than capability. Your lowest-scoring dimension is —, and that is where the next investment belongs.
Your score maps to a phase on the timeline. The dimension breakdown matters more than the total: the lowest dimension is the gate you will actually fail at, and in utilities it is far more often regulatory alignment than capability.Your four dimensions score evenly, so there is no single weak link to attack — follow the stage’s next move above rather than picking a dimension.
Want the timeline mapped onto your actual submission calendar?
We take your price-control, rate-case or IRP dates, place the five phases against them, and mark every gate that has to be cleared before a window closes. You leave with a dated plan and a list of what must be evidenced by when. No obligation, and you keep the plan either way.
How the score maps to a stage
- 0–4 — Stage 1, Foundations. Foundations is the phase that makes operational data legible and the AI ambition fundable — no models in operations, one named sponsor, and a place secured in the next regulatory submission.
- 5–9 — Stage 2, Proof. Proof is the phase where one or two use cases demonstrate value on real operational data under innovation funding, with output still advisory and no business-as-usual dependency permitted.
- 10–14 — Stage 3, Scale. Scale is the phase where a proven use case is re-engineered as a funded, supported service inside the control room's own systems, with an owner, an availability commitment and a tested rollback.
- 15–19 — Stage 4, Embed. Embed is the phase where AI stops being a programme and becomes a platform line in the operating model: shared data and serving, several live decisions, and benefits appearing in the annual regulatory reporting pack.
- 20–24 — Stage 5, Optimise. Optimise is the steady state: the marginal cost of the next decision is low, the constraint is governance and evidence rather than engineering, and the next five years are argued for in the submission rather than defended after it.
What an AI transformation timeline for a utility actually is
A definition, the five phases with their entry and exit gates, and the funding path that decides how fast any of it can move.
An AI transformation timeline for a utility is the ordered, dated sequence in which capability, funding and evidence are built — five phases across roughly five years, each with an entry condition that must be true before it starts and an exit artefact that proves it finished. It is not a list of use cases with target dates. It is a plan whose unit of progress is a gate cleared, and whose calendar is set by something outside the programme entirely.
That something is the regulatory cycle. A network business in Great Britain funds against a RIIO price control, and Ofgem's own framing (opens in a new tab) puts the standard control period at five years: RIIO-T3 and RIIO-GD3 run 2026 to 2031, RIIO-ED2 runs 2023 to 2028, and RIIO-ED3 will run 2028 to 2033. A US investor-owned utility funds against rate cases before its state commission and plans against an integrated resource plan. In both systems, the calendar is public, the windows are fixed, and a piece of work that misses one waits for the next. That is why a utility AI plan is a timeline problem before it is a technology problem.
The consequence is unfamiliar to anyone arriving from a less regulated sector. In most industries a programme that runs three months late costs three months. In a regulated utility, a programme that runs three months late can cost three years, because the evidence it was producing was destined for a filing that has now closed. Sequencing discipline in this industry is not project-management hygiene; it is the difference between a funded five-year horizon and another cycle of innovation-funded proofs.
The five-phase timeline, with its entry and exit gates
Windows are typical elapsed time for a mid-sized network business starting from a standing data estate. The phases overlap deliberately — Proof begins before Foundations formally closes — but the gates do not: a phase cannot be entered until the prior gate's artefact exists. Where a window collides with a submission date, the submission wins.
Months 0–12
1 · Foundations
Enter with: an executive sponsor and one candidate decision. Work: measure the joins between historian, GIS and the asset register; stand up one governed feed; write the phase-two ask into the next regulatory submission. Nothing runs in operations.
Exit artefact: a measured data-quality baseline and a drafted submission line
Months 9–24
2 · Proof
Enter with: a governed feed and innovation funding secured. Work: one or two use cases on live operational data, advisory only, with an agreed operational baseline and a decision log from day one. No business-as-usual dependency is permitted.
Exit artefact: a published benefit against an agreed baseline, in the regulator's units
Months 18–42
3 · Scale
Enter with: an approved allowance line. Work: re-engineer one proven capability as a supported service inside the ADMS, EMS or work-management system, with an owner, an availability commitment, a cyber assessment and a drilled rollback.
Exit artefact: one live, funded, supported capability with a reported benefit
Months 36–60 (usually spans two control periods)
4 · Embed
Enter with: one capability live and a second funded. Work: extract the shared feed, serving, monitoring and evidence layer so the next decision is configuration; argue the platform line in the next submission using phase-three reported benefits.
Exit artefact: a funded platform line and more than three decisions served from it
Year 5 onward, re-argued each control period
5 · Optimise
Enter with: a funded platform and a working reporting treatment. Work: keep operating envelopes and baselines current on a review calendar, retain raw logs across period boundaries, and draft each submission's ask from live evidence rather than strategy.
Exit artefact: a benefits claim that survives a change of reporting framework
How an AI initiative reaches the control room — and what pays for it at each hop
Two funding lanes and an evidence lane. The top lane is where most utility AI still sits: innovation-funded, advisory, and structurally forbidden from becoming something operations depends on. The middle lane is the only path to business as usual, and it runs through a submission window. The bottom lane is what makes the benefit claimable when the year ends.
- Data & feeds
- AI / model
- Where value leaks
- Human in the loop
- System-of-record action
The process, in words
- In the innovation-funded lane, a one-off extract from SCADA, AMI and GIS feeds a time-boxed discovery or alpha model paid for by a Network Innovation Allowance or a competitive innovation fund. Its output is advisory by design — a screen beside the control room — and the project closes with a learning report. The capability is switched off, because innovation funding is not permitted to create something business as usual depends on.
- In the allowance-funded lane, a phase gate produces evidence, that evidence goes into a price-control, rate-case or IRP submission, and an approved allowance funds a governed feed, a supported service and a write-back into the field the control engineer already reads. This is the only lane that ends inside the control room, and every step in it is dated by the filing calendar rather than by the sprint board.
- The evidence lane runs underneath both. A baseline is agreed with operations before the build, not after it; the decision log records every recommendation, accept and override; and at year end the benefit is claimable precisely because those two artefacts existed while the work was happening. An evidence lane assembled retrospectively produces a number that a reviewer can discount.
Step-by-step insights
- The one-off extract — why the fastest start is also the shortest ceiling
- Nearly every utility AI project begins with an extract: a CSV of interval data from the AMI head-end, a point export from the historian, a shapefile from GIS. It is quick, it needs no change approval, and it is the reason the project cannot be kept. An extract carries no lineage, no refresh, no owner and no security classification, so nothing built on it can be assured for control-room adjacency later. The extract is fine for a discovery phase and fatal as a foundation, which is why Foundations exists as a separate phase with its own gate rather than as the first sprint of a modelling project.
- Innovation funding — a good instrument used as a substitute for a plan
- Ofgem's Strategic Innovation Fund deliberately runs projects through discovery, alpha and beta stages so that risk is retired in increments, and each licensee's Network Innovation Allowance exists to pay for work that could not yet pass a cost-benefit test. Used properly, this machinery is the cheapest evidence a utility can buy. Used as the programme itself, it produces a decade of proofs, because the instrument's own rules prevent the output from becoming a dependency. The test is simple: if you cannot name the filing your current innovation project is feeding, it is not feeding one.
- The advisory screen — the artefact that looks like adoption and is not
- An advisory screen next to the control-room desk is the most common phase-two exit state, and it reliably impresses visitors. It also reliably fails in storm conditions, which is when the model is worth most. A control engineer managing a widespread outage does not have attention to spare for a second application, so consultation rates collapse exactly when value peaks. Nothing about this is a modelling failure. It is a placement failure, and it is only fixable in the lane that has an allowance behind it.
- The submission window — the single date the whole plan is cut against
- A price-control or rate-case submission is a fixed, published deadline with a long preparation tail: the business case, the benefits statement, the cost-benefit analysis and the stakeholder engagement all have internal deadlines months before the external one. Programme managers who first meet this calendar underestimate it by roughly two quarters. Draw the timeline backwards from the filing date, mark the internal deadlines as gates, and treat everything after the last internal deadline as belonging to the next period, because it does.
- The write-back — where the cyber assessment lives
- Writing a value into an ADMS or EMS puts a component inside the operational-technology boundary, which brings a formal assurance path: in North America the NERC Critical Infrastructure Protection standards govern how such a component is built, patched and accessed, and equivalent network-and-information-security obligations apply in Europe. This does not block the deployment; it dates it. Teams that discover the assessment during phase three add six to nine months to a plan that had none allocated, and the months come out of the same control period.
- The evidence lane — cheap while the work is happening, impossible afterwards
- Agreeing a baseline with operations before a change costs a meeting. Reconstructing one after the change costs an argument and usually settles for a weaker claim, because the counterfactual is now contaminated by the change itself. The same asymmetry applies to decision logs: capturing accepts and overrides during phase two costs a table and an insert, while inferring them later is impossible. The utilities that carry benefits across a control-period boundary are, almost without exception, the ones that built this lane while the work was in flight.
The five phases in detail
For each phase: 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 the move to the next phase actually costs.
Each phase below is written for a practitioner rather than a buyer. The hallmarks describe observable conditions inside a network business, the diagnostic signals are checks you can run against your own systems and your own submission documents this week, and the anti-pattern is the specific mistake most often made trying to leave that phase. The investment lines are stated in team terms and elapsed time, because in a regulated business those are the two things a plan is actually constrained by.
Select a phase
Every phase'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
Foundations
34% of operators sit here
Foundations is the phase that makes operational data legible and the AI ambition fundable — no models in operations, one named sponsor, and a place secured in the next regulatory submission.
Foundations is dull, cheap and skipped more often than any other phase. The temptation is understandable: a utility already has decades of SCADA history, an AMI estate producing interval data at national scale, and an asset register that has survived three system migrations. It feels as though the data problem is solved. It is not solved until a single engineer can join a feeder's load history to its asset condition record to the weather at that substation without opening a spreadsheet, and in most utilities that join is a person rather than a pipeline.
What actually gets built in this phase is small: a governed feed from the historian, an as-operated view of the network model, and an honest measurement of how bad the joins are. The measurement matters more than the fix. A phase that ends with 'asset IDs reconcile between GIS and the EAM for 62% of primary transformers' is a phase that can be argued about, funded and improved. A phase that ends with 'we have a data lake' cannot.
The second half of Foundations is not technical at all. It is the work of getting a line into a regulatory submission — which means writing a business case in the language the price control or the rate case uses, with a benefits statement the regulator's own framework recognises. This is why Foundations has a hard deadline that has nothing to do with engineering: the submission window. A programme that finishes its data work two months after the filing has done good work and lost a year.
In practice
The transformer register nobody could join
A distribution network operator wanted to predict transformer end-of-life across a region. The condition data existed — oil analysis, thermal images, load history — in three systems with three different asset identifiers, reconciled quarterly by one engineer close to retirement. The first six months of the programme produced no model at all. It produced a mapping table, a nightly job that maintained it, and a measured reconciliation rate that went into the price-control submission as a stated starting position. That number is what made the phase-two ask credible.
What it looks like
- Historian, GIS and asset-register data can be joined without a manual reconciliation
- One named executive sponsor and one named operations owner exist on paper
- A data-quality baseline has been measured, not asserted
- The AI ask has an identified slot in the next price control, rate case or IRP
Diagnostic signals you can check this week
- Ask how a feeder's load history is joined to its asset record. If a person's name is the answer, you are in Foundations
- Ask when the last data-quality measurement was taken, and whether it produced a number or an adjective
- Check whether the AI ask appears anywhere in the current or next regulatory submission
- Ask who is accountable for AI outcomes in operations, not in IT. A vacancy here caps the programme at phase two
Anti-pattern · Buying the platform before the submission
The instinctive move is a large data-platform procurement — a lakehouse, a two-year integration programme, a governance council. Done before the submission, it consumes the discretionary budget that should have bought the evidence for the submission, and it guesses at requirements that no use case has yet generated. Worse, a platform bought outside a funded allowance often has to be justified retrospectively in the next filing, which is the hardest kind of justification to win. Measure the joins, buy the smallest feed that answers one question, and put the platform in the submission.
What holds you here
The data joins are held together by individuals, so nothing built on them is repeatable — and the AI ask has no place in a funded submission.
Highest-leverage next move
Measure the joins between historian, GIS and the asset register, publish the number, and write the phase-two ask into the next regulatory submission.
Cost of leaving
- Effort
- 9–12 months, ending at a submission window
- Team
- One data engineer, one network planning analyst, part of a regulatory-affairs manager
- Risk
- Low — nothing operational depends on the work, and the artefacts are reusable whatever the filing decides
- To next stage
- 9–12 months
If this is you, the next step is
A three-week engagement: measure the joins, size the feed, draft the submission language.
Stage 2
Proof
38% of operators sit here
Proof is the phase where one or two use cases demonstrate value on real operational data under innovation funding, with output still advisory and no business-as-usual dependency permitted.
Proof is where most utility AI lives, and the reason is structural rather than cultural. Innovation funding is designed for exactly this phase: Ofgem's Strategic Innovation Fund runs projects through discovery, alpha and beta stages precisely so that risk is retired in increments, and each licensee's Network Innovation Allowance exists to pay for work that would not survive a cost-benefit test on day one. That machinery works. It funds good research, it produces genuine learning, and it is not allowed to produce a dependency.
That last clause is the whole problem. Innovation funding comes with a condition that the output must not become something business as usual relies on, because business as usual is funded from a different pot with a different approval. So a proof that works ends with a screen the control room likes, a report the regulator reads, and a switch-off date. Utilities routinely run the same proof twice, four years apart, because the first one could not be kept.
The discipline that gets a programme out of Proof is therefore not modelling discipline. It is writing the proof so that its artefacts are submission-grade from the first week: a baseline agreed with operations before anything changes, a decision log that records every recommendation and every override, a stated benefit in the units the regulator's framework already accepts. A proof designed to be published is worth roughly three proofs designed to be demonstrated.
In practice
The forecast that was switched off on schedule
A transmission operator ran an innovation-funded project that improved day-ahead wind forecasting materially against the incumbent method. The control room liked it. The project closed on time, the model was decommissioned, and the learning report was filed. Eighteen months later the same capability was rebuilt under a funded line — the second build cost less than the first because the baseline and the decision log had survived, but the eighteen months did not come back. The team's own retrospective was blunt: the proof was scoped to satisfy the innovation fund, not to feed the submission.
What it looks like
- One or two models run on live operational data, not extracts
- Funding comes from an innovation allowance or a competitive innovation fund, not the totex base
- Output is advisory — a screen beside the control room, never inside the ADMS or EMS
- A learning report is a deliverable, and everyone knows the project has an end date
Diagnostic signals you can check this week
- Ask what pays for the AI work running today. If the answer is an innovation allowance, you are in Proof
- Ask whether a baseline was agreed with operations before the model was switched on, and who signed it
- Check whether accepts and overrides are logged, or whether only outputs are stored
- Ask what happens to the capability when the project's funding ends. A shrug is the phase-two signature
Anti-pattern · Running a second proof instead of writing a submission
When a proof succeeds and cannot be kept, the reflex is to run another one — a different use case, a different fund, a fresh learning report. It is easier than writing a business case, and it keeps the team busy and the sponsor pleased. But the second proof does not increase the chance of funded deployment; only a submission does that. If a proof has met its exit conditions, the next piece of work is the filing, even though the filing is a less interesting quarter for the engineers.
What holds you here
Innovation funding cannot support a business-as-usual dependency, so a proof that works still has no route into the control room until it appears in a funded allowance.
Highest-leverage next move
Convert the proof's baseline, decision log and benefit statement into the phase-three ask in the next price-control, rate-case or IRP submission.
Cost of leaving
- Effort
- 12–18 months, of which the last three are writing, not building
- Team
- One ML engineer, one data engineer, a named control-room owner, regulatory-affairs support
- Risk
- Medium — the risk is not technical failure but a successful proof with no funded destination
- To next stage
- 12–18 months
If this is you, the next step is
We audit an in-flight innovation project against what the next filing will need.
Stage 3
Scale
18% of operators sit here
Scale is the phase where a proven use case is re-engineered as a funded, supported service inside the control room's own systems, with an owner, an availability commitment and a tested rollback.
Scale is the first phase where the utility owns a capability rather than a project. The distinction is contractual as much as technical: there is a line in a funded allowance, a support model, a change process that includes the model, and a person whose objectives move when the number moves. Everything that made Proof cheap — no dependency, no availability commitment, no on-call — is now reversed, and the cost roughly triples for a capability that looks identical from outside.
Most of the engineering in this phase is unglamorous integration into systems that were not designed to receive an opinion from a model. An ADMS expects a value, a source and a timestamp; it has no field for a confidence interval, and the control engineer has no time to read one. Deciding how a probabilistic output is rendered as an operational instruction, and what the engineer is meant to do with it at three in the morning during a storm, is a design problem that the proof was allowed to defer and Scale is not.
The other half of the phase is regulatory hygiene. A funded capability in a control-room-adjacent position sits inside the cyber boundary, which in North America means the NERC CIP regime applies to how it is built, patched and accessed, and in Europe means an equivalent set of network-and-information-security obligations. None of this prevents the deployment. All of it adds months, and every month is one that a plan drawn without it will not have.
In practice
The three-week integration that took nine months
A utility scaled a proven outage-prediction model into its outage management system. The model work was finished in three weeks. The remaining nine months went on the cyber-security assessment for a component inside the control-room boundary, the change-approval path through two governance boards, agreeing what the control engineer should do with a probability rather than a prediction, and drilling the rollback to the previous rules-based alert twice on quiet shifts. Nobody had planned for any of it, because the proof had touched none of it.
What it looks like
- The capability has a funded line in the totex allowance or the approved rate base
- Output is written into the ADMS, EMS or work-management system, not displayed beside it
- A named operations owner carries the outcome metric, and someone is paged when it degrades
- There is a rollback to the previous decision source, and it has been exercised
Diagnostic signals you can check this week
- Ask whether the capability appears in a funded allowance line, or in a project code that expires
- Ask where the output lands. If the control engineer has to open a second application, you are still in Proof
- Ask when the rollback was last exercised, and whether it was a drill or an incident
- Ask who is paged at 03:00 when the feed stops, and check that the name is current
Anti-pattern · Scaling breadth before scaling depth
Funding usually arrives for a portfolio, not for one use case, so the natural move is to start five things at once. Each is then built as its own integration, its own monitoring, its own on-call entry, and the team's capacity is consumed by the fourth. Take one capability all the way through integration, cyber assessment, rollback drill and reporting before starting the second. The second then inherits the hard-won path and costs perhaps a third as much, which is the whole argument for phase four.
What holds you here
Each capability is integrated, assessed and supported as a one-off, so the second costs as much as the first and the funded portfolio cannot be delivered inside the period.
Highest-leverage next move
Extract the shared feed, serving and evidence layer from the first funded capability so the second is configuration, and put that platform line into the next submission.
Cost of leaving
- Effort
- 18–24 months, and it must start early enough to finish inside the control period
- Team
- Integration engineer, ML engineer, OT/cyber assessor, named control-room owner, on-call rota
- Risk
- Medium to high — the cyber and change-approval paths are the schedule, and they are outside the team's control
- To next stage
- 18–24 months
If this is you, the next step is
We map the integration, cyber and change-approval path before it becomes the schedule.
Stage 4
Embed
8% of operators sit here
Embed is the phase where AI stops being a programme and becomes a platform line in the operating model: shared data and serving, several live decisions, and benefits appearing in the annual regulatory reporting pack.
Embed is where the arithmetic changes. Because the feed, the serving path, the cyber assessment and the evidence trail are shared, the marginal cost of the next decision collapses — and so does the marginal time. Utilities at this phase stop talking about AI projects and start talking about which operational decisions are on the roadmap for the year, which is a conversation an operations director can run without a data scientist in the room.
This phase almost never fits inside the control period that funded phase three. A capability funded in year two of a five-year price control has to be built, assured and stabilised before it can be generalised, which puts platform extraction in year four or five — exactly when the organisation is writing its next submission. That collision is not a problem to be avoided; it is the mechanism. Phase four is argued for using phase three's reported benefits, in the filing that phase three's evidence made credible.
The characteristic failure at Embed is drift between the platform and the reporting. A shared serving layer makes it easy to add decisions and hard to keep saying, in the regulator's units, what each one is worth. Utilities that keep the per-decision baseline discipline through the platform transition carry their benefits into the next control period. Utilities that do not end up with a healthy platform and a benefits statement nobody can substantiate, which is a poor position to be in halfway through a submission.
In practice
The roadmap that stopped mentioning AI
An operator with a shared feed and serving layer reached a point where adding a new decision — low-voltage feeder constraint forecasting for a newly acquired licence area — took four weeks, three of which were spent agreeing the baseline and the reporting treatment with the regulatory-affairs team. The engineering was five days. The internal roadmap for that year listed eleven operational decisions and did not use the word AI once, which the programme director considered the clearest evidence the phase had completed.
What it looks like
- A shared feed, feature and serving layer supports more than three live decisions
- New decisions ship in weeks because the integration and cyber path is already assured
- AI benefits appear in the regulatory reporting pack as baselined, attributable numbers
- The platform has its own funded line and its own owner, separate from any use case
Diagnostic signals you can check this week
- Measure the elapsed time from decision agreed to decision live, for the last three. Falling means the platform is real
- Check whether one monitoring surface covers every served decision, or whether each has its own
- Ask whether the platform has its own funded line and owner, distinct from any use case
- Open the last regulatory reporting pack and count the AI benefits stated with a baseline behind them
Anti-pattern · Letting the platform outrun the evidence
Once serving is cheap, decisions get added faster than baselines get agreed, and within a year the platform supports a dozen decisions of which four have attributable numbers. The next submission then argues for a platform on the strength of a third of its portfolio, and the reviewer reasonably asks about the rest. Make an agreed baseline and a reporting treatment part of the definition of done for every decision added, even the small ones — especially the small ones, because they are the ones that accumulate.
What holds you here
The platform grows faster than the baselines behind it, so the benefits statement in the next submission covers only part of the portfolio it is asking to fund.
Highest-leverage next move
Make an agreed baseline and a regulatory reporting treatment part of the definition of done for every decision the platform serves.
Cost of leaving
- Effort
- 18–30 months, typically straddling two control periods
- Team
- Platform team, operations product owner, regulatory-affairs partner, standing cyber assessor
- Risk
- Higher — the constraint moves to evidence and governance, and the platform ask is the largest single line in the next submission
- To next stage
- Continuous; re-argued each control period
If this is you, the next step is
We turn a portfolio of live decisions into one defensible platform business case.
Stage 5
Optimise
2% of operators sit here
Optimise is the steady state: the marginal cost of the next decision is low, the constraint is governance and evidence rather than engineering, and the next five years are argued for in the submission rather than defended after it.
Optimise is narrower than it sounds and rarer than any vendor slide suggests. It does not mean an autonomous grid. It means a utility whose AI capability has become ordinary: funded as a standing line, planned like any other asset class, reported on annually, and argued for in each submission from evidence generated by the previous one. The programme has stopped being a transformation and become part of how the business is run.
The work at this phase is mostly about keeping evidence and policy current. Operating envelopes that were correct for one network topology stop being correct after a reinforcement programme or a large DER connection wave. Baselines drift as load growth changes the counterfactual — a point regulators themselves are now working through, as the load-growth material published for commissioners makes clear. The discipline is to review the envelope and the baseline on a calendar, not after an incident or a challenged benefit claim.
The commonest way to leave Optimise is not technical regression but a change of regulatory period. A new price control or a new commission brings a different benefits framework, and a programme that has been reporting comfortably for four years suddenly has to restate its value in an unfamiliar shape. Utilities that keep the underlying baselines and decision logs — rather than only the derived numbers — can restate. Utilities that kept only the summary cannot, and the capability quietly becomes unfundable despite working perfectly.
In practice
The restatement that took two weeks instead of two quarters
An operator entering a new control period found the benefits framework had changed: value that had been reported as avoided reinforcement now had to be expressed as customer-minutes-lost and deferred capex separately. Because every served decision still had its original baseline, its decision log and its raw counterfactual, the restatement was an analysis exercise rather than a rebuild. The team's estimate was two weeks. The comparable exercise at a peer that had retained only quarterly summaries ran for two quarters and settled for a weaker claim.
What it looks like
- The AI capability is a standing item in business planning, not a transformation programme
- Selected decisions execute inside a versioned operating envelope, with exceptions escalating
- Benefits are reported annually against agreed baselines and survive external scrutiny
- The next control period's ask is drafted from live evidence, not from a vision document
Diagnostic signals you can check this week
- Ask whether the operating envelope has a review date, and when it was last reviewed against the current network
- Ask whether raw baselines and decision logs are retained, or only the derived benefit numbers
- Check whether the next submission's AI ask is drafted from live reporting or from a strategy deck
- Ask how a single automated action from eighteen months ago would be reconstructed, and time the answer
Anti-pattern · Treating the operating envelope as configuration
Thresholds and bounds get adjusted in a settings screen with no version history, no review and no record of who changed what and when. It works until someone has to explain a decision made in a previous control period, at which point neither the model nor the envelope that produced it can be reconstructed, and a benefit claim that was fine for four years becomes indefensible. Version the envelope, review it on a calendar, and keep the trail as long as you keep the asset records.
What holds you here
Sustaining the position is a governance problem: evidence frameworks change between control periods, and only retained baselines and logs make a restatement possible.
Highest-leverage next move
Put the operating envelope and the baseline set on a review calendar, and retain raw logs for at least the length of a control period.
Cost of leaving
- Effort
- Continuous, with a heavier cycle every submission
- Team
- Platform team, standing governance forum, regulatory-affairs partner
- Risk
- Concentrated — low frequency, high consequence, and regulatory rather than technical in nature
- To next stage
- Continuous
If this is you, the next step is
We test the evidence behind your AI benefits claim against a changed reporting framework.
Where utilities actually sit on the timeline today
The distribution across the five phases, and why the Proof-to-Scale gate — not the modelling — is where the years go.
Most utilities are in Proof. The distribution is heavily weighted toward innovation-funded work: a large majority have at least one model that has demonstrably beaten an incumbent method on live operational data, and a very small minority have several decisions served from a funded platform with benefits stated in the regulatory reporting pack. The gap between those two states is not a modelling gap. It is a funding-route gap, and it is measured in submission cycles.
Illustrative distribution of utilities across the five phases
Proof is the mode and the plateau. The drop from Proof to Scale is the largest single transition loss on the timeline, and it is the one that costs whole control periods rather than quarters. Distribution is illustrative — treat it as the shape of the problem, not as a measurement of your peer group.
Share of utilities
- 34% — 1 · Foundations
- 38% — 2 · Proof (the plateau)
- 18% — 3 · Scale
- 8% — 4 · Embed
- 2% — 5 · Optimise
Source: Illustrative distribution, synthesised from IEA, EPRI and Ofgem innovation-programme reporting
The pressure behind the timeline is also external and rising. The IEA's Energy and AI (opens in a new tab) analysis puts data-centre electricity consumption at around 415 TWh in 2024 — roughly 1.5% of world electricity — and set to more than double to around 945 TWh by 2030, with nearly half of US data-centre capacity clustered in five regional areas. Load growth of that shape lands on specific substations and specific interconnection queues, which is precisely why regulators have begun publishing load-growth material for commissioners (opens in a new tab) and why an AI capability that can defer or avoid reinforcement is now a fundable line rather than a research curiosity.
Sector research bodies have moved on the same clock. EPRI convenes an Open Power AI Consortium (opens in a new tab) to build shared AI capability for the power sector, and NARUC now runs professional development on AI and regulation (opens in a new tab) for commissioners and their staff. Both matter to a timeline for the same reason: they shorten the phase-one work of establishing that AI is a legitimate, reviewable line in a filing, which five years ago was itself a multi-cycle argument.
Wiring the phases to the regulatory calendar
The centrepiece of this page: which phase fits in which window, what funds it, and what you are actually allowed to claim for it in a filing.
Each phase belongs to a specific place in the regulatory cycle, and the placement is not a preference — it follows from what each funding instrument is permitted to pay for. Foundations and Proof are pre-submission work funded from discretionary and innovation budgets; Scale requires an approved allowance and therefore cannot start before a filing has concluded; Embed is argued in the following submission using Scale's reported benefits. Reading the table below against your own filing dates is the single most useful hour a utility AI programme manager can spend.
| Phase | Typical window | Where it sits in the cycle | What funds it | What you can claim in a filing |
|---|---|---|---|---|
| 1 · Foundations | Months 0–12 | Pre-submission — must finish before the internal filing deadline | Discretionary IT and business-planning budget; some data work capitalised as part of an existing systems programme | Nothing yet. You state a measured starting position (data-quality baseline) and an ask, not a benefit |
| 2 · Proof | Months 9–24 | Inside the current control period, feeding the next submission | Network Innovation Allowance, Strategic Innovation Fund, or a US utility's research and development budget | A demonstrated effect against an agreed baseline, on a bounded scope, labelled as a proof — plus the learning report the fund requires |
| 3 · Scale | Months 18–42 | Starts after determination; must complete inside the control period that funded it | Approved totex allowance in GB; approved rate-base or opex line in a US rate case | A live, measured operational benefit on the funded scope — customer-minutes-lost, deferred reinforcement, avoided truck rolls, outage duration |
| 4 · Embed | Months 36–60 | Straddles two periods: built in the last years of one, argued in the submission for the next | A distinct platform line in the next submission, justified by phase-three reported benefits | Portfolio-level benefit across several decisions, plus a stated reduction in the marginal cost of the next decision |
| 5 · Optimise | Year 5 onward | Standing item in business planning; restated at each period boundary | Standing totex or rate-base line, renewed each period | Annually reported, baselined benefit that survives a change of reporting framework — the strongest class of claim available |
Great Britain gives the cleanest worked example because every date is published. Ofgem's RIIO-T3 price control (opens in a new tab) runs from 2026 to 2031 for electricity and gas transmission, RIIO-GD3 over the same window for gas distribution, RIIO-ED2 ends in 2028, and RIIO-ED3 will run 2028 to 2033. The RIIO-3 final determinations (opens in a new tab) set the allowances those networks now operate under. For a distribution network business reading this in the second half of 2026, that arithmetic is stark: there are fewer than twenty months of ED2 left, which is enough for Foundations and a Proof, and the Scale ask has to be in the ED3 submission that is being assembled now.
The same five phases, mapped onto the published GB price-control calendar
A worked example for a GB network business, using Ofgem's published control periods. A US utility substitutes its own dates — rate-case filing, procedural schedule, order, and the IRP cycle — but the shape does not change: pre-submission phases must finish before an internal deadline, and funded phases cannot start before a determination.
Now → the internal filing deadline
Foundations
Measure the joins, stand up one governed feed, and get the AI line drafted into the business plan. The external submission date is public; the internal deadlines for cost-benefit analysis and stakeholder engagement sit months earlier, and those are the real gates.
A data-quality baseline and a drafted allowance line
Remaining years of the current control period
Proof
Run one or two use cases under the Network Innovation Allowance or a Strategic Innovation Fund project. Agree the baseline with operations before switching anything on, and design the learning report so it doubles as submission evidence.
A published, baselined effect and a decision log that survives the project
From determination, inside the funded period
Scale
Build the supported service against the approved allowance. Book the cyber assessment and the change-approval path at the start, not when the model is ready — in most estates those two items, not the engineering, set the completion date.
One live capability with an owner, a rollback and a reported benefit
Final years of the period, into the next submission
Embed
Extract the shared feed, serving and evidence layer, and write the platform line into the next business plan using the reported benefit from Scale. This is the phase that must be planned across a period boundary rather than inside one.
A funded platform line in the following control period
The following control period and beyond
Optimise
Keep operating envelopes and baselines on a review calendar, retain raw logs across the boundary, and draft each subsequent ask from live reporting. Assume the benefits framework will change at least once and keep the underlying evidence, not only the derived numbers.
A benefits claim that can be restated in a new framework
The US pattern is different in mechanism and identical in consequence. A rate case sets what a utility may recover and when; an integrated resource plan sets the multi-year expectation the commission will hold it to; and FERC (opens in a new tab) governs the transmission and wholesale-market layer above both. The practical effect for a programme manager is the same as under RIIO: there is a filing date, there is a long internal preparation tail, and evidence that arrives after the tail belongs to the next cycle. The EIA's electricity data (opens in a new tab) is usually the neutral reference point both sides of a proceeding will accept for load and generation context, which makes it a sensible baseline source when the counterfactual is contested.
Draw the plan backwards from the filing, never forwards from today
A forward-drawn plan optimises for the earliest demo. A backward-drawn plan optimises for the evidence that has to exist on the internal deadline, which is typically two quarters before the external one. The two produce different first sprints: the forward plan builds a model, the backward plan agrees a baseline.
Treat internal deadlines as the real gates
Cost-benefit analysis, stakeholder engagement and executive sign-off each have their own dates inside a submission process. A capability that is technically ready the week before the external filing is not in the filing, because the business case closed months earlier.
Never let an innovation-funded capability become load-bearing
The rules of Ofgem's innovation funding (opens in a new tab) exist for a reason, and breaching them in spirit — by letting operations quietly depend on a proof — creates an unfunded dependency that surfaces at the worst moment, usually the day the project code closes.
Write phase-three's benefit statement during phase two
The wording of a benefit claim is a regulatory-affairs skill, not an engineering one, and it constrains what has to be measured. Drafting it eighteen months early changes what phase two instruments, which is the entire point.
Opex pilots and capex platforms: why the money changes the order
Two funding routes with different rules, different speeds and different permissions — and the 2×2 that decides which one the next piece of work belongs to.
The funding route changes the order of the work because the two routes permit different things. Innovation money is fast, tolerant of failure and structurally forbidden from creating a business-as-usual dependency. Allowance money is slow, gated by a public filing calendar and the only route to something the control room can rely on. A programme that treats them as interchangeable pots of cash will keep producing capabilities it is not allowed to keep.
Innovation allowance — fast, small, and explicitly non-load-bearing
In Great Britain each network licensee holds a Network Innovation Allowance inside its price control, and Ofgem additionally runs the competitive Strategic Innovation Fund (opens in a new tab) with Innovate UK, staged as discovery, alpha and beta so risk is retired incrementally. Expect months, not years, to get started — and expect the funded thing to be switched off at the end.
Totex or rate-base allowance — slow, large, and the only route to business as usual
This is the money that pays for a supported service with an owner, an availability commitment and an on-call rota. It arrives only through a determination or a commission order, which means the work it funds cannot start until the filing has concluded, and must complete inside the period it was granted for.
Capitalisation changes who says yes
Work that can be capitalised as part of an asset or systems programme is approved by a different route and on a different timescale from work charged as operating expenditure. The same engineering effort can be a two-week internal approval or a nine-month business case depending on which side of that line it falls, which is why the treatment question belongs in the first planning conversation rather than the last.
Third-party and framework routes buy time, not capability
Bringing a systems integrator inside an existing framework agreement can start work months earlier than a new procurement. It does not build internal capability, and capability that leaves with the contract has to be paid for twice — once in the current period and again in the next.
Choosing the funding route for the next piece of work
Plot the horizon the work genuinely needs against the funding route available for it. Three of the four quadrants describe a real, common and avoidable mistake; only one is the shape a fundable programme takes.
The orphan capability
- Long-horizon work paid for from a short-horizon fund
- The commonest stranded-pilot pattern in utilities
- Fix: shrink the scope to what the fund can finish, and move the rest to the submission
The shape that funds
- Platform and multi-decision work argued into the submission
- Five-year horizon, matched five-year allowance
- Fix: nothing — protect this by keeping the baselines current
Correct use of discovery money
- Short proofs, learning reports, no business-as-usual dependency
- Cheap evidence for the next filing
- Fix: name the filing it feeds, or it is not feeding one
Over-engineered for the question
- Asking for rate-base funding before any evidence exists
- The line most likely to be cut in review
- Fix: buy the evidence from an innovation allowance first
The practical rule that falls out of the matrix is a sequencing rule, not a budgeting one: use innovation money to buy the evidence, and allowance money to buy the dependency. Programmes that invert this — building the platform on discretionary budget in the hope of retrospective justification, or running a fifth proof because the submission is intimidating — are not funding failures. They are sequencing failures with a funding symptom, and they cost a control period each time.
