The Architecture That Has to Move

The previous post argued that the fidelity problem in defence software delivery does not disappear when distance is added. It just changes form. That argument ended at the data layer. In deployed military environments, AI systems face the same fidelity problem, but this time it is not between people. It is between the model and the data that it needs to be useful. The same logic applies: when the data cannot travel to the capability, you take the capability to the data.

This post is about what that means, why it matters, and why the architecture of most commercial AI makes it harder than it should be.

The Bet That Cloud AI Made

Cloud AI made a rational bet. It assumed that data would flow to the model. In most commercial contexts that assumption holds. Connectivity is reliable, compute can be centralised in data centres that scale to meet demand, and the round-trip from data source to model to decision is fast enough to be useful. The architecture that grew from that assumption, cloud-first, centralised inference, data exfiltration and analysis at scale, is genuinely powerful. It was designed for the environment it operates in.

The military operating environment was not consulted.

Two Reasons the Bet Fails

There are two distinct reasons the cloud AI assumption breaks in military contexts, and both deserve to be named clearly.

The first is connectivity. Military operations happen in what practitioners call denied, degraded, intermittent and limited (‘DDIL’) conditions. This is not an edge case. It is the baseline. A patrol in rough terrain, a vessel operating under emissions discipline, an aircraft with burst communications only: these are not failure modes. They are the normal operating environment. Any architecture that depends on reliable connectivity to a central model has built its own failure condition into its design.

What makes this more pointed is that the vulnerability is not accidental. Adversaries have learned they do not need to defeat Western military capability directly. They need to disrupt the data flows on which that capability depends. Cloud-dependent AI is not just fragile in DDIL conditions. It is a target.

The second reason is volume. The modern battlefield generates sensor data, intelligence, surveillance, and reconnaissance (‘ISR’) feeds, and autonomous system outputs faster than any network can carry them, even when connectivity is available. A tactical edge node ingesting data from a dense operating environment is producing information at a rate that makes centralised processing impractical on physics grounds alone. The constraint is not just that connections drop. It is that even in permissive environments, the volume of data generated at the tactical edge exceeds what can be exfiltrated in time to be useful.

The combination of these two factors makes the cloud AI assumption not just fragile but structurally misaligned with the environment it is being asked to serve.

The Architecture Inverts

When the data cannot travel to the model, you invert the architecture. The model goes to the data. This is not a future vision. It is already happening, driven by operational necessity rather than design preference.

In the United States, the Combined Joint All-Domain Command and Control (‘CJADC2’) programme is building the architecture for AI-assisted decision-making across land, air, maritime, space, and cyber domains, with edge inference built into the design rather than added later. The Replicator Initiative, which is fielding autonomous systems at scale, is producing platforms with embedded AI by construction. These are not demonstrations. They are operational commitments.

The equivalent logic is present in NATO’s multi-domain operations (‘MDO’) framework and in UK investment in edge-capable platforms and tactical AI. The direction of travel across the alliance is consistent: inference needs to happen where the data is, not where the data centre is.

What this requires architecturally is a different starting assumption. AI designed for the edge is not the same as AI adapted for the edge. A model designed for cloud inference and compressed for deployment on a tactical platform carries the assumptions of its origins with it. A model designed from the outset for constrained compute, intermittent connectivity, and on-platform inference is a different kind of thing. The distinction is not primarily technical. It is one of the starting conditions.

One Principle, Three Layers

This is the third post in a series, and it is where the argument the series has been building arrives at its most general form.

The first post argued for forward-deploying engineers. Get the builder close to the user. Close the gap between the person who understands the problem and the person who can solve it by reducing the physical and procedural distance between them. The model that treats software delivery as a hand-off rather than a conversation produces software that is technically compliant and operationally marginal.

The second post asked whether physical proximity was always the point. The answer was no. Proximity was always a mechanism for preserving information fidelity: how much of the real problem survives the journey from the person who has it to the person who can act on it. Large language models (‘LLMs’) change what fidelity is achievable at a distance because they can absorb plain language, hold context, and translate across the vocabulary gap separating operators from engineers.

This post makes the same argument at the data layer. The AI model needs to be close to the data to be useful. When the data cannot travel, the model must. Not because of a preference for edge computing, but because the operating environment makes centralised inference unreliable at precisely the moments it is needed most.

The principle is the same at every layer: always take the capability to the problem. Never assume the problem will travel to the capability intact. It is the same insight whether you are talking about an engineer, a language model, or an AI system on a tactical platform in a contested environment. Distance degrades fidelity. Proximity preserves it. And when physical proximity is unavailable, the right response is to find the next-best way to close the gap, not to accept the loss.

The Companion Post

I have written elsewhere about what makes edge AI deployments fail in practice: the operating model challenges of power, identity, change control, and supportability that determine whether a capability works in the field once the architecture decision has been made. That question is downstream of this one.

The question this post addresses is the earlier one: whether the architecture decision is being made deliberately, with the operating environment as the starting point, or whether it is being inherited from commercial AI models designed for conditions that do not apply. The answer to that question determines a great deal about what happens next.

The data does not travel well in contested environments. The capability has to go to the fight. That is not a technical constraint. It is a design principle, and it was always going to be the conclusion of this series.