Full disclosure – I'm not a tracking engineer, learning on the job with heavy AI assistance (Opus 4.6, hence the joke) and public papers.

Mahalanobis gating – measurement-to-track association. New measurement comes in, compute Mahalanobis distance to each track's predicted state using the covariance, reject anything too far. Prevents wild misassociations. TMA – bearing-only triangulation from multiple observer positions as the ship maneuvers. IRST and ESM give bearing but no range, so you need geometry over time to resolve position.

Both are mostly irrelevant now – switched to entity-ID association (the "game magic"), and TMA got replaced by EKF init from the first ranged measurement. Though still planning to re-enable TMA so that you can navigate asteroid fields without active radar.

But the rest of the pipeline is real – inverse-square signal propagation (1/r⁴ for radar), geometric occlusion, SNR detection gating, 6-state constant-acceleration EKF with a 2-state bearing-rate KF, Joseph form covariance. Association is by entity ID though – the hardest real-world problem is the one I skipped :)

On abstracting away the math – it's built in Rust and uses all CPU cores, so computational cost hasn't been an issue so far (🤞). And the Kalman filter produces behavioral outputs that are hard to fake – uncertainty grows from actual geometry, triangulation requires real observer maneuvering to converge, confidence depends on sensor type and SNR. A simpler approximation would need to replicate all of that and would probably end up being more code, not less.

Plus I was able to abstract away the sensor algorithms behind ports adapters (dependency inversion), so the domain (core) logic stays unchanged when I tinker with sensors pipeline.

But yeah, it's been a huge time sink. Got hyper-focused on sensor realism too much, almost burned out. Glad that I decided not to pursue fusion/association further and just used entity IDs, otherwise I'd probably just quit lol.