Three documents published within a few months of one another have converged on the same finding, and it is not the one the sector expected. The government's call for evidence on planning reform for digital infrastructure closed on 26 February 2026. The Institution of Civil Engineers published State of the Nation 2026 in March. The International Energy Agency published its analysis of demand flexibility. Read together, they place the constraint on how quickly a network can answer demand somewhere other than the equipment: in permissions, in records, and in whether the load on the far side of the meter can be asked to move.
What that costs is easy to name. Appeal timetables. Surveys repeated because the last one was never filed where the next team could find it. Substation capacity bought at the worst price of the year because the alternative was never wired up. What it saves is harder to see and larger: some of the capacity a network needs at its busiest hour does not have to exist at all.
The word state carries two meanings, and the argument needs both
State means the physical estate: substations, masts, cabinets, ducts, fibre, the plant a country runs on. State also means the record of that estate: the asset register, the as-built drawing, the configuration file, the state file a provisioning tool reads before it changes anything.
Both are called state because both claim to be the truth at a given moment. Both fail the same way, when the record and the thing it describes drift apart. A mast decommissioned two years ago but still present in the register generates a planning application for a site nobody needs. A subnet that exists in the cloud but not in the state file produces a surprise the next time a pipeline runs. Scaling either kind of state for demand begins with knowing which parts carry load.
Why demand now moves faster than the assets that serve it
Electricity systems are changing structure. The IEA's Scaling Up Demand Flexibility describes rising demand driven by the electrification of transport, heating, cooling, industry and digital infrastructure, while low-emissions sources take a larger share of generation. Grid operators have to manage both the size and the shape of the load.
The IEA's central argument is that demand need not stay passive. Digitalisation, connected devices and new market arrangements allow consumption to respond to system conditions, which supports reliability, lowers cost, integrates renewable generation and defers investment in infrastructure. Demand stops being a number forecasters estimate and engineers build for, and becomes something the system can call on.
For anyone running a network estate, the practical consequence is that the load a site presents is now a design variable. A charging hub, a fleet of heat pumps or a large industrial process can be scheduled, curtailed or shifted. The IEA is careful to say the potential is unevenly distributed across end uses, and that the largest consuming sectors are not automatically the most flexible ones. That distinction decides where the money goes.
What the planning system actually withholds, and what the reform targets
In England, planning permission is required for work that meets the statutory definition of development under the Town and Country Planning Act 1990, as the DSIT and MHCLG call for evidence sets out. That covers building operations, engineering operations such as groundworks, and material changes of use. Operators holding rights under the Electronic Communications Code get permitted development rights under Part 16 of Schedule 2 of the General Permitted Development Order, which let them install, alter or replace telecommunications equipment without a full application, subject to conditions.
Those rights come in two intensities, and the difference between them is the whole argument:
Some permitted development rights are subject to a requirement that the developer seek the prior approval of the local planning authority before the development can commence.
That is the call for evidence defining the mechanism. The authority considers only specified matters, such as siting and appearance, within a time-limited window, and a refusal can follow. The lighter alternative is notification: the developer tells the authority of the intention to use the right and proceeds after a set notice period, with no approval to wait for.
The call for evidence also names the areas where the government wants more evidence, including temporary redeployment after a notice to quit, larger rooftop infrastructure on protected land, ground-based masts, and bringing fibre exchanges into permitted development. It records that industry says moving from prior approval to prior notification would speed deployment.
Why a refusal costs more than the decision it delays
An appeal is not a slower yes. It is a different process on a different timetable. The call for evidence records what industry reports: that a significant proportion of prior approval applications are refused, that operators frequently appeal, and that a large share of appeals are overturned by the Planning Inspectorate. The appeal route can extend a deployment by up to a year and add material cost.
The government's own framing is cautious in a way worth reading closely. It notes that planning application statistics suggest the vast majority of prior approval applications across all sectors are approved, but that telecoms applications are a small share of the total and are not separately identified, so no conclusion can be drawn from those figures. That is an honest statement of an evidence gap, and it is why the exercise is a call for evidence.
The operational lesson for a delivery team is not to wait for the outcome. A site with an unresolved planning position is a site with an unresolved design position. Keeping the design, the consents and the asset record in step is what stops a refusal from restarting work that had already been done.
The same drift between record and reality, one layer down
Software infrastructure has lived with this problem longer, which makes its vocabulary useful. In its treatment of scalable infrastructure, Spacelift describes the point at which a codebase swells because many engineers work on different parts of it, and names the failures that follow: a leaked key, a permissive storage setting, an open security group. It describes deployments run from individual terminals, with consistency degrading as the number of environments passes the point where key rotation, traversal attacks and privilege escalation can be reasoned about by hand.
The remedy it sets out will be familiar to anyone who has reconciled a register with reality. A Git repository as the single source of truth for code, with merges flowing through a pipeline so the deployment mechanism is centralised and visible. A deliberate choice between one repository and many, taken on the basis of how much visibility the organisation can tolerate. State kept out of the repository, encrypted, locked and access controlled, because the state file holds values the code deliberately does not.
Spacelift also names the failure that matters most once an estate is large: blast radius. Its example policy scores resource changes by type and by action, so a change touching a production database requires authorisation while a change adding instances to an autoscaling pool does not. The mechanism is a policy engine. The effect is that the size of an estate stops being an excuse for not knowing what a change will touch.
The ways capacity can be added, taken one at a time
Vertical scaling adds capacity to an existing machine. It lifts performance without introducing more machines to manage, and it suits workloads that are hard to distribute. It meets the ceiling of the hardware, costs more per unit of capacity at the top end, and may require downtime to perform.
Horizontal scaling adds machines and spreads the workload. It tolerates the failure of one node, balances load across many, and permits the use of commodity hardware. It needs load balancing to distribute work evenly, and it multiplies the number of things to monitor and maintain.
Automatic scaling adjusts resources in response to measured demand. It holds performance through a spike without a human decision and lets spending fall away afterwards. It demands careful policy configuration at the outset, and it still needs review, because a policy nobody revisits scales the wrong thing.
Folio3's overview of scalable infrastructure sets out those three modes as the starting taxonomy, and the cloud providers implement all of them as managed services. Microservices and container orchestration extend the horizontal mode by letting one component scale without dragging the rest with it, which is the architectural version of the same idea: do not make the whole estate absorb a local change.
What the record has to carry once it is treated as infrastructure
Treating the record as infrastructure means giving it the properties you would demand of the plant. That means:
- An owner, named, for each register, state file and dataset, with the authority to accept or reject a change.
- Version control for every artefact that describes the estate, so a change can be traced to the decision behind it.
- Segregation between the record and the credentials that act on it, so reading the estate is not the same permission as changing it.
- Encryption at rest for anything holding connection details, addresses or keys.
- Locking, so two processes cannot modify the same state at once and leave the estate in a condition neither intended.
- A retention rule that removes entries when the asset they describe is genuinely gone, since a register that only grows stops describing anything.
- A reconciliation step, run on a schedule, that compares the record against the estate and reports the difference.
- An audit trail that outlives staff turnover, because the reason a duct was routed a particular way is usually known to somebody who has since left.
# reconciliation record: one row per disagreement, never auto-corrected
asset: MAST-4471
register_says: active
field_check: absent
action: raise for asset owner decision
None of that is novel on its own. The difficulty is that the physical register and the software state file are typically owned by different teams, funded from different budgets and reconciled on different cycles, while the demand that arrives does not care which team owns which.
How to sequence the work
Express Data's guide to scaling network infrastructure sets out an order that matches the constraint described above. It begins with a structured assessment covering capacity, performance at peak, security posture against current threats and compliance requirements, and the growth expected over the next few years. The gap between present performance and future need becomes the objective.
From there it argues for modularity: structured cabling, segmentation that separates critical services from general traffic, and high availability through redundancy, failover paths and load balancing, designed according to recognised standards. Security is built in from the start, on the basis that retrofitting it costs more and carries more risk. Monitoring and automation follow, and the roll-out is phased, with a pilot in a controlled environment and fallback plans before anything goes estate-wide.
The sequencing discipline is the part most often skipped. A phased plan assumes the assessment was honest about which constraints bite now and which bite later, and that somebody recorded what the pilot proved.
What the delivery side says it needs
The ICE's State of the Nation 2026 examines the same problem from the delivery end. Its headline messages are that more collaboration is required, that large-scale innovation is needed including rapid uptake of non-traditional solutions spanning investment, procurement and technology, and that the industry must build capacity and capability through recruitment, training and more efficient ways of working.
The report also notes a change in how infrastructure is assessed, describing a government trial of an asset condition index that aggregates data on condition, performance, risk and reliability into a single score, beginning with the strategic road and rail networks. That is the physical estate's version of the state file: a record kept current enough to guide expenditure. The ICE's concern is that this discipline takes time to prove itself before it can reach council-run assets, and that those assets keep deteriorating while the proof is gathered.
The connection to digital infrastructure is direct. A network estate is an asset estate. Where its record is incomplete, the operator cannot demonstrate the case for a change, cannot show which assets are critical, and cannot price the alternative of not building. The planning system asks for evidence, and the asset register is where that evidence lives.
Where to start
Begin with reconciliation. Establish what the register says exists, then establish what exists, and write down the difference without fixing it silently. That single exercise settles which records can be trusted in a planning submission.
Then decide, per site and per service, whether the next increment of demand is met by moving load, by adding capacity to an existing asset, or by adding an asset. Demand flexibility is the cheapest of the three where it is available, and the IEA's analysis is clear that availability depends on the end use, on the enabling technology present, and on whether consumers will take part.
Finally, put the change under a policy. Whether the policy governs a plan against an estate or an application against a local plan, its job is the same: to stop a local change from consuming the whole estate's headroom. The estate that scales is not the one with the most headroom. It is the one whose record tells the truth about where the headroom is.
Sources
- Reforming planning rules to accelerate deployment of digital infrastructure
- Scaling Up Demand Flexibility
- State of the Nation: Infrastructure in 2026
- Building a Scalable Infrastructure: Strategies & Best Practices
- Scalable IT network infrastructure
- Scalable Infrastructure: Types, Benefits & Best Practices
Some permitted development rights are subject to a requirement that the developer seek the prior approval of the local planning authority before the development can commence.
Source: Are governments ready for their expanding responsibilities?, The Arab Weekly