Sensor Fusion and the Common Operating Picture

Why a fused picture is an architecture problem

A common operating picture is usually discussed as a display: one screen, one set of symbols, one shared understanding of where things are. That framing hides the decision that matters. Before anything can be drawn, some component has to decide which of several contributions describes the same object in the world, and which of them to believe when they disagree. That decision is architecture, and it is made long before an operator looks at anything.

This paper treats the picture as a data problem with a display attached, rather than a display problem with data behind it. Programmes that specify the display inherit the reconciliation decision by accident, usually from whichever integrator delivered the last increment.

What CJADC2 actually specifies

The programme documents describe an outcome, not an interface. Every participating service is asked to contribute tracks to a shared picture, but the specification stops short of naming the authority that reconciles two contributions describing the same object. In practice that authority is assigned late, by whichever component fields the integration contract.

This matters because reconciliation is not a display concern. A picture that shows one track where two custodians disagree has made a decision on the operator’s behalf, and it has made it without recording why.

Track identity across custodians

Two custodians can hold what they each believe is a single track and disagree about its identity without either being wrong. Identity is asserted relative to a sensor picture and a time base, and neither is shared by default.

Latency budgets nobody owns

Every contributing system has a latency budget and every one of them is met. The budget for the fused product is not owned by anyone, because no component is accountable for the sum. The result is a picture that is individually timely and collectively late.

Six failure modes observed in exercise

Across six exercises the same six failures recurred, in roughly the same order, and none of them were reported as fusion failures at the time. They were reported as sensor problems, network problems or operator error.

The requirement was drafted before anyone characterised the threat, and nothing in the process forced a re-baseline when they finally did.

§4, Requirements, Not Radars

What an acquisition authority should require

Where a reconciler is named in the contract, disagreement is logged and recoverable. Where it is not, the picture silently prefers whichever feed arrived last — an outcome no requirement document in the sample anticipated. Naming the reconciling authority costs nothing at contract time and cannot be retrofitted cheaply.

Method and limitations

This version draws on a documentation review of six programmes and observation of six joint exercises. It does not include vendor interviews, and it makes no claim about programmes outside the sample. The exhibit in §5 carries a correction issued on 18 June 2026; the earlier version cited the wrong source record for the custody figures.