Mapping What Breaks: The ARTS Dependency Framework
Most analysis of European strategic dependency stops at the geopolitical layer.
It names the problem — cloud infrastructure concentrated in the US, critical materials processed in China, energy systems exposed to foreign pricing mechanisms. It describes the risk in structural terms. It earns the agreement of everyone in the room.
But then it stops. They rarely answer the question: So What?
What breaks, what are the consequences, and for whom?
Not at the level of trade statistics or diplomatic leverage. At the level of the building you are sitting in. The food on your table. The tap you turned on this morning.
That gap — between structural dependency and lived consequence — is what the ARTS framework is designed to close.
Why Existing Analysis Falls Short
The standard approach to dependency analysis focuses on sectors: energy, defence, digital, supply chains. These categories are useful for policy. They map onto ministerial portfolios, budget lines, and treaty structures.
But they create a blind spot.
When you analyse energy as a sector, you ask questions like: how much gas do we import, and from where? When you analyse digital infrastructure, you ask: which cloud providers hold our data?
These are legitimate questions. But they are answered at the wrong level of abstraction for two reasons.
First, they treat dependencies as isolated risks rather than coupled systems. The cloud dependency in your energy management system does not appear in energy sector analysis. It appears, if at all, in digital policy. The two conversations rarely happen in the same room.
Second, they do not trace consequences to the point where people actually experience them. A dependency on foreign cloud infrastructure is abstract. A heating system that stops working because dispatch software lost its API connection is not.
The ARTS framework starts from the other end: Societal Needs
The Framework: Three Layers
The framework organises analysis into three levels, read from left to right as dependency, and from right to left as provision.
Layer 1 — Societal Needs
The starting point is what society actually requires in order to function. Not technologies. Not sectors. Needs.
Housing. Nutrition. Mobility. Communication. Healthcare. Security. Economic exchange.
These needs are technology-agnostic and stable across time. Heating can be delivered by gas boilers, heat pumps, district heating, or biomass. The need — warm buildings — does not change. This distinction is important because it prevents the analysis from becoming captured by technology preferences or policy narratives.
Layer 2 — Functions
Functions describe what a system must do to meet the societal need. They are the operational capabilities that infrastructure must provide.
For housing: building structures, controlling the indoor climate, ensuring sanitation. For nutrition: producing food, processing it, distributing it, preserving it. For communication: transmitting data, storing it, identifying users.
Multiple technologies can fulfil the same function. The function is the stable analytical unit. This matters because dependencies often hide at the functional level. You can substitute one technology for another and unknowingly carry the same underlying dependency across.
Layer 3 — Strategic Resources
Every function depends on three categories of underlying resource:
Energy — all functions ultimately require energy. The dependency may be obvious (a pump needs power) or hidden (a data centre cooling system requires continuous electricity that is rarely counted in energy sovereignty discussions).
Materials — functions depend on physical materials and components. Critical raw materials, industrial metals, semiconductors, cables, transformers, chemicals. Material constraints determine what is buildable and repairable, and therefore set the physical ceiling on any transition or recovery effort.
Data — modern systems increasingly depend on digital infrastructure. Cloud platforms, control software, identity systems, AI models, data standards. A system may be physically present and operationally capable, yet functionally dependent on foreign digital infrastructure it cannot control or recover independently.
Reading the Dependency Map
Once the three layers are populated, each resource node is assessed on two dimensions.
Fragility measures how exposed the dependency is to external disruption — through supply concentration, geopolitical leverage, price volatility, or the absence of realistic substitutes.
Three levels: Stable, Exposed, Critical.
Capability measures whether the relevant organisation, sector, or country can deploy, operate, maintain, and recover the resource independently.
Three levels: Sovereign, Dependent, Absent.
These two dimensions interact. A resource that is externally concentrated but domestically operable is a different problem from one that is externally concentrated and domestically inoperable. The second is significantly more dangerous, and significantly harder to see.
The hard rule: if capability is absent, fragility cannot be rated below critical. You cannot be strategically stable in a resource you cannot operate independently.
An Example: Housing
Consider housing as a societal need. Two of its core functions are building construction and climate control.
Building construction depends on structural steel (material), diesel (energy), and engineering software (data). The critical node is diesel. Construction equipment and cement production both run on fossil fuel. A disruption to supply routes — a Hormuz blockage, a sanctions regime, a logistics breakdown — does not stay in the news. It stalls building sites across Europe. Fragility is rated Exposed; the dependency is real but not acute under normal conditions.
Climate control — keeping buildings habitable — depends on copper for grid infrastructure (material), grid electricity (energy), and cloud-connected dispatch software (data). The critical node is the data layer. Many modern building energy management and heat pump systems are increasingly coordinated through virtual power plant software and cloud-connected dispatch platforms. Most of this runs on AWS or Azure.
This is not billing software or a client dashboard. It is core operational intelligence — the layer that decides what runs, what scales back, and what gets dimmed across gigawatts of distributed energy assets.
If that layer becomes unavailable — through a legal dispute, a sanctions order, a political deterioration, or a technical failure — the heating system does not know what to do. The grid loses a balancing mechanism. The building gets cold.
Fragility: Critical. Capability: Absent. We depend on it entirely and cannot operate it independently.
Two Strategies, Not One
The framework generates two types of response, and the distinction matters.
Autonomy — eliminate the dependency. Find a substitute, onshore the capability, build the alternative. This is the right answer when elimination is feasible within a relevant timeframe.
Resilience — manage the dependency you cannot eliminate. Hedge it, diversify it, protect against its failure mode, design for graceful degradation. This is the right answer when elimination is not feasible, which is more often than policy prefers to admit.
Most European infrastructure sits somewhere between those two strategies, without a clear plan for either. The framework makes that visible. Once you know whether a dependency is eliminable or not, you can stop having the wrong conversation about it.
The cloud dependency in energy management is not eliminable in the short term. The honest conversation is therefore about re-hostability requirements, contractual protections, offline capability, and European alternatives at scale. Not about whether the dependency exists.
What the Framework Is Not
It is not threat intelligence. It does not predict who will act against European interests or when. Threats are the mechanism. Dependencies are the terrain. ARTS maps the terrain.
It is not a policy programme. It does not prescribe industrial strategy or regulatory frameworks, though it generates clear inputs for both.
It is not anti-American or anti-technology. Many of the dependencies it identifies are the result of rational decisions made under reasonable assumptions. Those assumptions are changing. The framework exists to make that visible before failure occurs.
It is not an effort to complete map dependency chains or value chains. We depart from a fixed set of societal needs on one end, and known dependencies on the other end. We connect the dots and uncover consequences.
What Comes Next
This framework will be applied systematically across the societal needs that underpin European stability: nutrition, mobility, communication, healthcare, security.
Each analysis will follow the same structure. Each will identify the dependencies that are hidden, the fragility ratings that are honest, and — where relevant — the capability gaps that make fragility unmanageable.
The goal is not to produce a comprehensive audit. It is to produce a set of analytical tools sharp enough to change the decisions that professionals actually make.
Dependency is not destiny. But unnamed dependency is.