Skip to content
Mehridian
Search published pages · Ctrl/Cmd + K

When a report fits two tracks, leave it out

5 min readFrom Seemorgh consoleSources checked 30 October 2026

In one line

At a crossing in a synthetic air picture, a hostile drone's radar plot fitted the friendly group slightly better than its own. The fusion engine attached it to neither, and the tests check that kind of decision against the scenario's truth.

At t=74 in the Seemorgh scenario, a hostile drone and a friendly interceptor are about 145 m apart and closing on each other’s paths. The plot radar reports two returns from each of them. One of the drone’s returns lands close to the drone, about 27 m from its fused position. But the engine attaches plots before it fuses anything, by comparing them with groups seeded from the reports that carry identity, and against those the plot sits nearer the wrong aircraft: about 51 m from the interceptor’s C2 report and 67 m from the drone’s. The interceptor’s C2 report is itself about 76 m from that aircraft’s fused position.

A radar plot is the least informative report the engine receives. It has a position, a timestamp and a signal strength, which the engine uses to set how uncertain the position is. It has no motion and no identity: no velocity, no heading, no IFF call. Nothing in that plot says which aircraft produced it. The FUSE engine attached it to neither track.

That’s the decision this note is about. Matching it to the best-fitting group would have been the obvious move, and here the best fit was the wrong aircraft. A wrong report doesn’t just nudge a position. It puts another aircraft’s return into the track’s list of supporting reports, which is the list an operator reads to see what the track rests on. At a crossing, the place where a fused picture is most likely to be wrong, a report that fits two tracks is better left out.

How the engine decides

The engine never matches reports by their IDs. Five vendors’ IDs mean five different things, and none of them is shared, so it works by geometry. Every report becomes a position in metres about the ground station, with an uncertainty ellipse shaped by how its sensor errs. The long-range radar’s ellipse is wide across its beam. The precision tracker’s is a few metres all round.

Grouping happens in two passes.

  • Reports that carry identity form the groups, strongest first. C2 tracks with an IFF call and motion go first, then the precision tracker, then the long-range radar. A report joins a group only inside a statistical gate (a squared Mahalanobis distance below 9.21, about the 99% level for two dimensions) and only if nothing contradicts it: opposite IFF calls, a second report from the same sensor (radar plots excepted: several may share a group), or two moving reports more than 60° apart in heading.
  • Then plots and RF fixes attach, under two stricter rules. A report has to sit close to the group’s sharpest member, not merely inside the radar’s wide ellipse. And if its second-best group is within twice the distance of its best, it joins neither.

That last rule is the one that left the t=74 plot out. The engine doesn’t log its reasons, so the frame was rerun with the association steps measured from outside, using the engine’s own functions unchanged. The rerun reproduced the recorded tracks exactly. The plot passed both gates for both aircraft. By squared Mahalanobis distance it fitted the interceptor’s group at 0.32 and the drone’s at 0.40, so the friendly group was the better fit. The second-best fit was only 1.27 times the best, well inside the factor of 2, so the plot joined neither.

The code’s own comments name the problem these rules exist for. Without them, the long-range radar’s wide ellipse can let a different object’s report into a track at the crossing. Seeding groups from the strongest identity evidence keeps the two aircraft’s motion groups apart before the fuzzy radar attaches. Requiring plots to sit near the sharpest member stops a stray plot riding the radar’s ellipse into a track.

Checked against the truth

A rule like this is easy to describe and hard to trust, so the claim needs a check that doesn’t depend on the engine’s own view of things. Here the check is available: the synthetic scenario encodes, in every report’s ID, which object really produced it. The engine never reads those IDs. The tests do.

Across all 91 timesteps they assert that no track’s identity-bearing reports come from two objects, and that each object ends up as exactly one track with the right classification. At t=73 to t=75, the middle of the crossing, they check every report, plots and RF fixes included. The timeline audit repeats the full-run checks and adds that the hostile stays priority 1. All of it is among the 33 fusion tests that passed in the recorded gate run on 27 October 2026. The test file’s own comments say crossing plot attribution was originally expected to fail, because a velocity-less plot there seemed impossible to attribute without temporal history.

What it rests on

  • Labels come from the inputs. “Hostile” and “friend” are the C2 network’s IFF calls and the RF sensor’s threat calls. The engine combines them; it doesn’t infer them. Because opposite calls can never share a group, correct labels are part of what keeps the two aircraft apart, and in this scenario they are always correct.
  • One instant at a time. The engine fuses each timestep on its own. Track numbers are ranks recomputed every frame, so a stable FT-001 is a consequence of hostiles ranking first, not of the engine following one aircraft.
  • One scenario. The crossing is deterministic and synthetic. Away from t=73 to t=75, the purity tests cover the identity-bearing reports, not every plot.

The rule worth keeping

Leaving a report out has a cost: the drone’s track at t=74 rests on one plot instead of two, and its modelled uncertainty, ±37.5 m, is the highest it reaches in the whole run. That is consistent with the missing plot, though no rerun with the plot forced in was made. Its actual position didn’t suffer: 11.8 m from the scenario’s truth, against a run average of 30.9 m. Attaching a report to the wrong track is likely to cost more, because the track then lists evidence it doesn’t have, at the moment that’s hardest to notice. When the evidence fits two answers almost equally well, the honest output is neither. Then test that choice against something the engine can’t see.

Basis: the FUSE association and fusion code at the export commit named in the replay README (private source); the recorded frame at t=74 in the public replay data; a read-only rerun of that frame on 30 October 2026 that matched the recording; the timeline tests and audit; and the recorded test gate of 27 October 2026. Distances in metres are from the frame’s recorded positions. See also the Seemorgh operator console case study and the crossing, frame by frame.

Further reading: Yaakov Bar-Shalom, Peter K. Willett and Xin Tian, Tracking and Data Fusion: A Handbook of Algorithms (YBS Publishing, 2011), the text the engine’s gate constant cites.

More in Notes.

Where this note sits

From the projects · 2 linked pages

Graph View

Linked from

All notes, on one map →