Dynamic sensor fusion: what if your sensors could move?

In the first post I said DomeCommand is a bet on two things. This one is about the first: sensor fusion, and why I think the interesting version of it involves sensors that move.

Let me start with the honest version of the problem, because most descriptions skip it.

The picture is usually bad

"Sensor fusion" sounds like addition. You have radar, RF, electro-optical, infrared, acoustic. Add them up, get one clean track. If only.

In reality each sensor lies in its own way. Radar gives you a position but not a name. RF tells you something is transmitting but not exactly where. A camera confirms what a thing is, but only once it is pointed at it and close enough to see. Coverage has holes. The contacts you care about are often the ones sitting in a hole, or the ones two sensors disagree about.

So the failure mode of a naive system is not that it misses things. It is that it is confidently wrong. Every blip becomes a track with a threat level attached the instant it appears. The operator ends up staring at a screen full of certainty that the system has not earned. Fuse bad inputs faster and all you have done is reach a wrong answer sooner.

The comfortable story: many sensors collapse into one clean track. The uncomfortable truth: each source sees a different, partial, sometimes contradictory slice.

Three questions, not one

The mistake underneath the bad picture is that it collapses three different questions into a single answer. When we started modelling this properly, the first move was to pull them apart. A fused entity is not one number. It is three separate channels, each answering its own question:

• Existence, "is it real?" A running score that goes up when a sensor corroborates the contact and down when it does not. It has a status you can read: tentative, confirmed, coasting, deleted. A single radar return is not a track. It is a suspicion that has to earn its way up.
• Identity, "what is it?" A belief spread across the possible classes rather than a hard label, with a measure of how uncertain that belief is. Radar alone leaves it near "unknown." An RF match narrows it toward a commercial quad. A close visual look collapses it to a specific model.
• Affiliation, "whose is it?" Friend, neutral, suspect, hostile, on a proper ladder, tagged with whether a machine inferred it or a human declared it.

Keeping these apart lets the console show something it never could before: the honest state of "we know something is there, but not what it is or whose it is." That is a real, common situation in this domain, and pretending otherwise is how you get a fabricated picture.

It also lets us hold one rule that matters more than any other:

Kinematics alone can never make something hostile.

A fast contact heading for a protected asset can reach suspect on its own. It cannot reach hostile without positive identification, a hostile RF signature, or a human making the call. Speed is not intent. Baking that into the type system, not the training material, is the point.

The part I actually care about: making it move

Here is where the "dynamic" in the title comes in.

There is a well-worn idea in this field called cross-cueing, or slew-to-cue: one sensor's output tasks another. A radar hit slews an electro-optical camera to go look. It is production-proven and it works. But notice the quiet assumption. The camera is bolted to a mast. The cue can only ever point the sensors you already happen to have, wherever they already happen to be.

So the question I keep coming back to: what if the cue could task a sensor that flies?

When identity is uncertain and the contact is near something you care about, the system does not just sit there and average its confusion. It raises a request: this contact is ambiguous, the thing that would resolve it is a closer visual look, and here is the drone that can get there, with an estimated time to do it. The operator sees a plain-English recommendation. Unidentified contact 1.2 km from the site. Send a drone to identify? ETA 40 seconds. They approve. The drone repositions, gets eyes on, and a picture comes back that firms the identity from "unknown" to a named model, and the affiliation off "unknown" to a real call.

The loop that makes fusion active: sense, weigh what is unknown, decide to collect, act by moving a sensor, then reassess with what it learned.

That is the whole thesis in one motion. A fixed sensor sees what it sees. A moving one can be sent to the gap in coverage, to the ambiguous contact, to the one angle you do not have. It turns fusion from "combine what you were given" into "go get a better look, then combine." Harder to build. Also, I think, where the real advantage is.

And it changes what certainty even means on the screen. Instead of a made-up "87% confident," a contact reads as its evidence: radar plus RF, two sensors, seen three seconds ago, identity still open. The operator instantly sees which modality is missing, and therefore what would fix it. The system is not hiding its ignorance. It is showing you the shortest path out of it.

What we are building

We are building this in layers, and the foundation is in place: the three-channel model, the existence scoring, the identity belief and the affiliation ladder with the kinematics-never-hostile rule enforced. The association math that keeps two crossing targets from swapping identities. Sensor models honest enough that RF and acoustic come in as bearings without a magic position attached, so fusion has to triangulate the way it would anywhere else.

On top of that we are building the collection loop end to end: the recommendation, the human approval gate, the drone repositioning, and the look coming back to firm the picture. In the simulator the closer look is a range-degraded capture, blurry far out and sharpening as the drone nears, so we can build and exercise the whole loop deterministically. The architecture is shaped so that as we bring the loop onto real optics and real airframes, the machinery is already there to receive it.

That is the through-line of everything here: build the honest picture first, then build the loop that goes and improves it.

Why this is the first bet

Fusion is where most of C2 quietly gives up and hardcodes its way to a confident guess. Making it honest about uncertainty is worth something on its own. Making it active, letting the picture task the fleet to go improve itself, is the part I think is genuinely new, and it only works because the same drones that defend can also go collect. Which is the second bet, and the subject of another post.

If a picture that argues with itself and then goes and settles the argument sounds like your kind of problem, follow along.