Critical infrastructure and regulated industry

This sector has a problem the others do not: the software has to still work, and still be defensible, long after everyone who built it has moved on. That makes dependency surface a strategic liability rather than an operational one, and it is the thing AI-accelerated delivery grows fastest.

Section 01Typical workloads

Asset and network management

Registers, condition monitoring, maintenance planning, capacity and outage schedulingLong-lived records describing physical plant. The data outlives several generations of the software holding it.

Operational dashboards and reporting

Aggregated views over operational telemetry, historians and control-adjacent systemsSits at the IT/OT seam, which is where an enterprise compromise becomes an operational one.

Incident and safety workflow

Fault reporting, permit-to-work, safety case evidence, regulatory notificationSafety-adjacent rather than safety-critical, and therefore assured far more lightly than the plant it describes.

Customer and regulatory interfaces

Supply data, billing, statutory reporting, industry data exchangeObligations that persist across decades and multiple regulatory regimes.

Health and care systems

Patient records, referral and scheduling, device-adjacent workflowSpecial-category personal data, statutory retention, and a strong duty of continuity — you cannot simply take the system down.

Section 02The threat picture

• Dependency rot over decades. The mean production application in a corpus we measured carries roughly 135 direct runtime dependencies, and the transitive closure is an order of magnitude larger.^[14] Over a twenty-year asset life, the expected number of those that become abandoned, transferred to an unknown maintainer, or compromised is not small, and no organisation has the attention to track it.
• The IT/OT seam. Enterprise-side compromise reaching operational systems is the characteristic serious incident in this sector, and the bridging software is usually the least assured code in the estate.
• Supply chain into long-support environments. Systems that cannot be patched quickly inherit every vulnerability in their dependency graph for longer than anyone intended.
• Machine-authored volume in a safety-adjacent context. The same evidence applies here as everywhere — roughly half of functionally correct generated backends exploitable in a benchmark with executable exploits^[1] — but the consequence tail is physical rather than financial.
• Sector-wide monoculture. Operators in the same industry buy from the same small supplier set and inherit the same components, so a single compromise has correlated national impact.
• Loss of institutional knowledge. Where the people who understood the system have left and the documentation is stale, the codebase is the specification — and nobody can enumerate what it reaches.

Section 03What is used today, and where it runs out

Section 04What changes

The dependency surface is deliberately small

A large part of a conventional application's dependency graph exists to make three programs agree with each other: validation on both sides of a boundary, serialisation, client type generation, schema tooling and the adapters between them. Where one description generates every derived artifact, that entire category has nothing to do. The dependency you removed cannot be abandoned, transferred, or compromised. For a twenty-year asset that is a different kind of saving from a productivity gain.

Stability is a designed property, not a freeze

The programme commits to change arriving only through explicit editions after a stability declaration. That is aimed at model corpora, but it produces exactly what a long-lived estate needs: a language that does not move under a system nobody is actively developing, and a defined mechanism for when it must. Freeze-and-certify becomes less punishing when the substrate is not churning underneath the freeze.

The IT/OT seam becomes enumerable

Bridging software is dangerous because nobody can state precisely what it can reach. Where authority is explicit, that question has a complete, checked answer — which is the input a segmentation argument has always needed and rarely had.

Data outlives the code, on purpose

Exportability in standard formats at every milestone is a permanent commitment in the programme's constraint set rather than a feature. The historical failure of language-owned persistence is that users could not get their data out; for a sector whose data has statutory life spans measured in decades, that commitment is load-bearing rather than reassuring.

Institutional knowledge degrades more gracefully

When authority and boundaries are declared and checked rather than implicit and remembered, a system that has outlived its authors is legible to the compiler even where it is no longer legible to the organisation. That does not replace documentation. It does mean the most safety-relevant questions have mechanical answers.

Section 05Questions worth asking

• How many direct and transitive dependencies does our critical operational software carry, and who is accountable for each over its remaining life?
• What can our IT/OT bridging software reach, and can that be produced mechanically?
• When we freeze a configuration for certification, what is our position on the vulnerabilities we are choosing to inherit for the freeze period?
• If a supplier's coding agent were compromised, what in our acceptance process would detect it?
• For systems with a twenty-year life, what is our plan for the parts of the stack that will be unmaintained within five?