The Substrate Problem: Architecting Infrastructure 4.0 So Its Gains Compound

You have paid for the same digital twin more than once

Ask an infrastructure owner how many digital twins they have paid for, then ask how many they still own and use today. The two numbers are rarely the same, and the difference is one of the most expensive habits in the built environment.

The sector is entering the largest construction wave in history, with global output heading from $13 trillion toward $22 trillion a year by 2040 (McKinsey, 2024). It is also the one large sector whose productivity has barely moved in twenty years while the rest of the economy pulled away. The cause sits beneath the tools: each project digitises on its own and leaves nothing behind, so the same capability is bought again and again and compounds never.

That waste is an architecture choice, and your organisation is making it right now, on programmes already running, usually without anyone choosing it on purpose. The owners who will compound their spend through the 2030s have already made one decision the rest have not, and they made it before buying a single sensor.

Foreword

Infrastructure is the quiet architecture of modern life. The roads, grids, pipes, transit lines, and buildings that surround us shape how people live, how economies grow, and how heavily both press on the natural world. When infrastructure works, it disappears into the background of a functioning society. When it falls behind, everything built upon it slows with it.

The world now finds itself building more of this foundation, and faster, than at almost any point in its history. Global construction output is set to rise from $13 trillion to $22 trillion a year by 2040, driven by urbanisation, the energy transition, and the demands of an economy reorganising around artificial intelligence. Yet a gap of some $15 trillion already separates the infrastructure societies need from the infrastructure they are on course to finance (McKinsey, 2024; Global Infrastructure Hub, 2025). Closing it stands among the defining challenges of the coming decade, and it will not be met by capital alone.

For all the digital tools now reaching the built environment, the sector's productivity has barely moved in twenty years. The cause lies in the way that technology is adopted: project by project, with little that endures once each project ends. The promise of Infrastructure 4.0, the joining of physical assets and digital intelligence across their whole life, will be realised only when those who own infrastructure build the shared foundations that let progress accumulate rather than reset.

That is a shared undertaking. It asks owners to treat their data as a lasting asset, governments to set the standards that let information move across a fragmented value chain, and industry to hand over living systems rather than finished files. Where these efforts meet, the prize is considerable: infrastructure that learns from itself, capital that delivers more for every unit spent, and a built environment better able to serve both people and planet.

This paper is offered as a contribution to that effort. It sets out a design logic for the owners and architects who carry these decisions, names the failure that most often traps them, and points to the choices that turn isolated projects into compounding capability. It is written to inform action, and to invite challenge.

The gains are real and the sector throws them away on repeat

The world is about to build more infrastructure than at any time in its history, and on current form it will get less of it for the money than it does today. Construction productivity has grown at roughly 1 percent a year for two decades, against 2.8 percent for the wider economy, even as global construction output climbs toward $22 trillion a year by 2040 and a $15 trillion investment gap opens (McKinsey, 2024; Global Infrastructure Hub, 2025). Digital methods that would ease this already work on individual projects, with the potential to raise productivity by 14 to 15 percent and cut costs by 4 to 6 percent — yet the sector productivity needle has not moved. The reason is architectural. Infrastructure owners buy digital capability one project at a time, and the gains retire when each project closes.

The clearest symptom has a name: the deliverable twin. A digital twin is built to a project's specification, admired at handover, and rendered useless within two years because no one held the data model across the asset's life. The remedy is equally clear: one shared, standard-based, owner-held data substrate that every project plugs into and every asset reports to across its life. Public owners from New South Wales to India and the United States are already writing these rules ahead of the technology. Owners who sequence these decisions early build infrastructure that compounds; owners who defer them keep paying for the same capability twice.

Infrastructure delivery, not capital, now sets the ceiling on the economy

Infrastructure is bought with money, but it is delivered with capability, and the two are drifting apart. The world's appetite for new infrastructure has rarely been greater. Global construction output is set to rise from $13 trillion in 2023 to $22 trillion a year by 2040, and national programmes are accelerating on every continent: Saudi Arabia has announced $1.25 trillion of capital projects, the European Chips Act commits more than $50 billion of public and private funds, and India is directing 3.3 percent of its GDP to infrastructure (McKinsey, 2024; McKinsey, 2025). Against that, the Global Infrastructure Hub still counts a $15 trillion gap between the infrastructure the world needs by 2040 and the infrastructure it is on course to fund (Global Infrastructure Hub, 2025).

The reflex is to read this as a financing problem and to reach for more capital. The data argues for a second reading. A sector that has improved its labour productivity by roughly one percent a year for two decades, while the wider economy compounded at 2.8 percent, cannot simply absorb a surge of spending and turn it into proportionally more built infrastructure (McKinsey, 2024). Part of every additional dollar is lost to the same delays, overruns, and rework the sector has tolerated for a generation. The force that now makes change unavoidable in the built environment is the widening gap between what the world needs built and the sector's capacity to deliver it.

That gap no longer stays inside the construction industry. Infrastructure delivery has become the constraint on other sectors' ambitions. The data centres behind artificial intelligence, the semiconductor fabs behind every supply chain, and the grids behind the energy transition are all, first, construction projects. When the built environment cannot deliver, those agendas stall with it. McKinsey records a $40 billion semiconductor facility in Arizona delayed into 2025 by a shortage of construction skills, a delay in chips caused by an inability to build (McKinsey, 2025). The same dependency runs through housing, transport, and water, where shortfalls translate directly into lost competitiveness and slower decarbonisation.

This is what raises Infrastructure 4.0 from an industry upgrade to an economic priority. The phrase, in the sense the World Economic Forum gave it, describes the joining of physical assets and digital intelligence so that infrastructure behaves as a connected system across its whole life (WEF, 2021). Done well, it is the most direct lever the sector has on delivery: the means to turn the coming wave of spending into more built, better run, lower carbon infrastructure. Done as most owners are doing it, project by project, it will leave the productivity line as flat in 2040 as it has been since 2000. The difference between those two outcomes begins with a simple observation about where digital gains actually go.

D5 reframes the failure as a missing foundation, not a missing tool

The analytical frame this paper uses is the D5 dimension of DigitalQatalyst's 6xD model: Digital Platform and Substrate Continuity. D5 examines whether the enabling layers beneath an organisation's digital capability are owned, persistent, and compounding — or whether they are rebuilt from scratch at every cycle and therefore cannot accumulate. It is the dimension that asks not whether digital tools have been bought, but whether the organisation has built the foundation on which digital capability can grow.

Applied to infrastructure, D5 exposes the core failure mode with precision. The built environment has no shortage of digital tools. What it lacks is the persistent substrate those tools depend on: an owned data model, held to a common standard, that outlives every project and every contractor. Without that substrate, each tool purchase begins the same capability from zero. The D5 lens makes this visible as a design choice rather than a technology gap — and it points directly at the thing to build.

Every section of this paper follows the same D5 logic. The delivery imperative (Section 2) establishes why the substrate problem now has economic urgency. The Evidence Base (Section 2) shows the concrete cost of its absence in the sector's most documented case. The Enterprise Implications (Section 3) name what leaders must design. The Road Ahead (Section 4) describes what the next 24 months will force upon the question. The D5 lens holds throughout: the question is always not what has been digitised, but what the organisation now owns that persists.

The cost of the missing substrate is already on the public record

Flat construction productivity, abandoned digital twins, and repeated reinvestment in the same tools point to the same structural cause — and the evidence trail is public.

Where the gains go

Follow the money on a typical infrastructure programme and a pattern appears. The programme is organised as a series of capital projects, and each project, sensibly, adopts the best digital methods available to it. A digital twin, a live virtual model of the asset kept in step with the physical thing through sensor data, is built for the project. A common data environment holds the design and construction information. Analytics watch progress, cost, and safety. On that project the methods earn their keep, and the 14 to 15 percent productivity gain that McKinsey attributes to digital methods is real (McKinsey, 2024).

Then the project closes, and the gain leaves with it. The data model is archived or handed to an operations team that did not commission it and cannot extend it. The next project opens a fresh sheet, procures its own twin, defines its own data structure, and rebuilds much of what already existed. Across a portfolio the same capability is bought again and again, and almost none of it accumulates.

The capability that would accumulate is different in kind from any single tool. It is a shared data and orchestration layer that outlives every project: the foundation each project plugs into while it is being built and each asset reports to once it is running. Think of it as a platform the whole portfolio stands on, owned by the organisation and not by any one project. The thing worth building, in other words, is the layer that turns the tools into a system.

The built environment already accepts this in principle. The World Economic Forum described infrastructure as a system of systems, linking the built environment, the natural world, and human experience (WEF, 2021). Most owners have bought the systems. Few have built the layer that connects them into one, and that missing layer is where the gains leak away.

The consequence is a clean test of architecture. Build the shared substrate, and each project's gain stays with the owner and adds to the last. Fund the capability inside each project, and each gain departs when the project does. The tools are identical in both cases. The difference is whether anyone designed the layer beneath them, and on most programmes that layer appears on no one's drawing.

The deliverable twin

The most expensive mistake in Infrastructure 4.0 has a recognisable shape, and naming it helps you catch it early. Call it the deliverable twin.

A transport authority commissions a digital twin as part of a station upgrade. The contractor builds it to specification, it passes acceptance, and it impresses at the handover review, with every duct, beam, and sensor modelled. But the contractor owned the data environment the twin lived in, the structure was tuned to the build phase, and what changed hands at the end was a model file rather than a live system the authority could run. Eighteen months into operation the asset has moved on, the model has not, and no team inside the authority holds the rights or the structure needed to keep it current. When the next upgrade begins, a fresh twin is commissioned from the ground up. The authority has paid for a twin twice and operates a useful one never.

Every part of the technology worked. The sensors worked, the modelling was sound, the analytics were accurate. What was missing was an owner of the data across the asset's life, and a decision, taken early, about who that owner would be.

The scale of the problem is easiest to see on the projects large enough to report it. London's Elizabeth line, delivered by Crossrail, is among the most digitally sophisticated railways ever built, with a mature common data environment and a published record of its methods. Even so, its hardest and most time-critical task was handover: the assurance and transfer of around 500,000 individual assets, supported by close to 200,000 documents, before the railway could safely open (UK Public Accounts Committee, 2021).

Crossrail itself described delivering a complete, structured set of asset information for operations and maintenance as one of its major challenges (Crossrail Ltd, 2018). The programme ran from an original GBP 14.8 billion to more than GBP 19 billion and opened three and a half years late, with system integration and handover on the critical path throughout (UK Public Accounts Committee, 2021). The lesson for owners is direct: the point where the owner's lifetime return on an asset is won or lost is the handover of structured, owned data, and that is precisely the point most programmes design last.

The reason this keeps happening sits beneath the technology. The built environment splits the work of creating an asset across owners, designers, contractors, and operators, each holding a slice of the asset's data on its own terms and passing the others a deliverable. No shared data contract spans them. The technology to instrument and model assets is mature and improving fast; the arrangement for owning and exchanging the data it produces is not yet. So the first architectural act in Infrastructure 4.0 is a governance decision: who owns the asset data model, on what standard, across the whole life of the asset.

A standard already exists to anchor that decision. ISO 19650, the international standard for managing information about a built asset across its life, gives the value chain a common way to structure and exchange that information. It is widely cited and unevenly applied, and the space between citation and application is where the deliverable twin breeds.

Public owners are beginning to close that space, and their moves point the same way. New South Wales now requires shared infrastructure data practice across the asset lifecycle through its Infrastructure Digitalisation and Data Policy, built on four principles and thirteen mandated actions and aimed squarely at stagnant productivity and rising cost (Infrastructure NSW, 2025). India's Department of Telecommunications has agreed with the International Telecommunication Union to apply AI-driven digital twins to national infrastructure planning, placing the twin at the level of the system rather than the single asset (ITU and India DoT, 2025).

In the United States, federal mandates and the CHIPS Act have made digital twins a condition of large public and subsidised projects, treating them as strategic infrastructure in their own right (Mordor Intelligence, 2025). The owners moving fastest write the data rules first and let the technology follow. They treat those rules as a standing capability, governed continuously rather than renegotiated as a fresh clause on every job.

A substrate that compounds is owned, standard-based, and live

For infrastructure owners, the D5 analysis leads to five decisions that must be made before procurement — not after it. Each is a leadership and governance choice, not a technology purchase.

A substrate worth building has three properties, and each is a design decision rather than a purchase.

It is owned by the asset owner. The data model, its structure, and the rights to extend it sit with the organisation that will run the asset for the next forty years, not with whichever contractor delivered the latest phase. Ownership is what lets capability persist from one project to the next.

It is standard-based, so the value chain can exchange information without rebuilding it at every handover. ISO 19650 is the natural anchor for built-asset information; what matters is less which standard than that one is chosen, written into every contract, and enforced. Interoperability across owners, designers, and operators is a contract an owner writes, not a feature an owner buys.

And it is live. The twin stays in step with the asset across its operating life, fed by the same sensors and maintained by the same teams that run it, so the model reflects the asset as it is rather than as it was at handover. A twin specified this way becomes the operating model of the asset.

Where those three properties hold across a portfolio, a larger possibility opens. An organisation whose assets all report to one live data model, and whose planning and maintenance decisions draw on it, begins to behave like an organisation that learns. For an infrastructure owner that is concrete. It looks like maintenance priced from real asset condition, planning that can be simulated against the live network before capital is committed, and a portfolio that grows cheaper to run as its data deepens.

This is already happening at sector scale. The United Kingdom has spent years building exactly this foundation. Its National Digital Twin programme, guided by the Gemini Principles published by the Centre for Digital Built Britain in 2018, set out to connect the country's infrastructure through securely shared data and a common information management framework, on the explicit logic that the prize lies in strong data infrastructure rather than the latest tool (CDBB, 2018). The economic case was sized at the outset: better data sharing across UK infrastructure could release on the order of GBP 7 billion a year, roughly a quarter of total infrastructure spend (National Infrastructure Commission and Deloitte, 2017). That is the compounding return the substrate exists to capture, quantified by a national programme rather than asserted.

Turning this into a programme is a matter of sequence, and most programmes get the sequence wrong. Five moves, in order, make the gains compound.

First, organise the programme around the lifecycle asset rather than the capital project. This one reframing changes what you procure, whom you hold accountable, and where the data lives.

Second, write the data contract first. Before procurement, decide who owns the asset data model and on what standard it is held, and name ISO 19650 or your chosen equivalent in every contract that touches the asset.

Third, specify the twin as a living system the owner controls, with continuing data feeds and an owner-held structure, and define handover as the transfer of that live system. Acceptance should test whether your operations team can read, query, and extend the twin on day one.

Fourth, build the substrate once and connect every project to it, funding the shared layer as a platform programme with its own roadmap and owner.

Fifth, govern the substrate as a standing function that owns the model, enforces the standard, and settles disputes between parties, rather than a checkpoint that dissolves at each phase end.

The same logic applies everywhere, but its starting point depends on where you build. In the greenfield programmes of the Gulf, where Saudi Arabia alone has announced $1.25 trillion of new capital projects, owners can design the substrate into assets from the first day and avoid the retrofit problem entirely (McKinsey, 2025). In the mature, retrofit-heavy markets of Europe, the substrate has to be added to assets and contracts that already exist, which makes the next major upgrade the moment to introduce the data contract rather than a clean sheet to wait for.

And where governments are building national digital twins, as in the United Kingdom, Singapore, and now India, individual owners gain most by aligning their own data model to the national standard so their assets can join the wider system rather than stand apart from it (CDBB, 2018; ITU and India DoT, 2025). The destination is shared. The first move is local.

Regulation, AI, and talent will reward owners who built the substrate early

The next 24 months will sharpen the divide between owners who have built the substrate and those who have not. Three signals are worth watching.

Regulatory pressure will harden. The moves already made by New South Wales, India, and the United States federal programmes are early indicators of a broader shift toward mandated lifecycle data practice. Owners in jurisdictions that have not yet moved should expect equivalent policies within two to three years, and those who have built the substrate voluntarily will face no disruption when the requirement arrives. Those who have not will face a retrofit under regulatory deadline — a significantly more expensive condition.

AI makes the substrate more valuable, not less necessary. Infrastructure operators are beginning to apply generative and predictive AI to network planning, maintenance scheduling, and capital prioritisation. Every one of those applications depends on a continuous, owner-held data model. An owner without a live substrate cannot benefit from these tools at portfolio scale; they are locked to project-level use cases only. As AI capability in the built environment matures, the substrate becomes the gating factor on what an organisation can do with it.

The talent market for substrate-capable teams will tighten. The skills required to own, govern, and extend an asset data substrate — information management, BIM ownership, standards governance — are in short supply and growing shorter. Owners who build the substrate now are also building the internal capability to run it. Those who defer the decision will face both a retrofit and a capability gap simultaneously.

The practical test remains simple. Look at your next three programmes. Is there one owned data model connecting them, or three deliverables on their way to being stranded? The answer tells you which version of Infrastructure 4.0 your organisation is already funding.

Buy the data contract first, or keep re-buying what your peers learn to keep

Strip the argument to its core and one claim remains. The built environment's productivity has stayed flat for two decades despite abundant tools, capital, and demand, because owners digitise project by project and build nothing that outlives the project (McKinsey Global Institute, 2017; McKinsey, 2024). The gains are real, and they are thrown away on repeat. The fix is a matter of design: one owned, standard-based, live data substrate that every project plugs into, with the governance written before procurement.

The numbers cut both ways. Digital methods can lift project productivity by 14 to 15 percent and cut costs by 4 to 6 percent (McKinsey Global Institute, 2017), and the United Kingdom valued better data sharing across its infrastructure at around GBP 7 billion a year (National Infrastructure Commission, 2017). Set against that, the Elizabeth line spent years and billions with the handover of half a million assets sitting on its critical path (UK Public Accounts Committee, 2021). Architecture is the difference.

The roles follow. Owners claim the data model and fund the substrate as a standing platform. Designers and contractors deliver into a shared standard and hand over living systems. Operators are equipped to run the twin from day one. Governments are already showing the way, from the UK National Digital Twin to the data policies of New South Wales and India (CDBB, 2018; Infrastructure NSW, 2025; Government of India, 2025). Private owners who wait will keep re-buying what their public peers are learning to keep.

The reason to move now is the scale of the spend. Over the next fifteen years a $22 trillion-a-year build pipeline arrives, and each project sets its pattern, stranded or compounding. The decisions taken this year will shape a decade of portfolio performance.

So it comes down to one action and one test. Make the data contract the first thing your next programme procures: name the owner, name the standard, and require every project to connect. Then look at your next three projects and ask whether they share one owned data model, or hand you three deliverables waiting to be stranded.

The harder question is for the boardroom. If the data contract sets the return on everything built after it, why is it almost never bought first? Answer that, and the productivity line that has not moved in twenty years finally will.