When Sensors Forget: Why Tracking Is Harder Than Detection

A radar detects a platform. An EO camera classifies it. An RF receiver records its emissions. For a brief moment, the system has a coherent picture.

Then the radar drops out — terrain masking. The EO camera can't see through the cloud layer. The RF signature fades as the platform goes silent.

Twenty minutes later, all three sensors reacquire. The platform is back — same type, same general area, possibly the same entity.

Here's the critical question: Does the system know it's the same platform?

For most AI systems today, the answer is no. They detect frames. They classify snapshots. They produce point-in-time observations. They don't remember.

And in defence operations, forgetting is not just inconvenient — it can be fatal.

The Tracking Gap

Detection and classification are solved problems, practically speaking. Modern AI can detect, classify, and localise platforms across RF, EO, SAR, and acoustic modalities with impressive accuracy.

But tracking — maintaining a persistent, coherent representation of an entity through time, through sensor dropouts, through environmental changes, through adversarial countermeasures — is a fundamentally different problem.

Tracking requires memory. Not just buffer memory or sliding-window memory, but structured, relational memory that captures what the system knows about each entity, how confident it is, and how that knowledge has evolved.

In short, tracking requires a knowledge graph.

What Is a Knowledge Graph (And Why Should You Care)?

A knowledge graph is a structured representation of entities, their attributes, and their relationships. Unlike a database table with fixed schemas, a knowledge graph is flexible — it can absorb new entity types, new attribute types, and new relationship types without restructuring.

In the context of multi-modal fusion for defence, a knowledge graph might contain:

When a new sensor observation arrives, the system performs entity resolution — determining whether this observation corresponds to an already-known entity or represents a new one. This is where the knowledge graph earns its keep.

The Entity Resolution Problem

Entity resolution sounds simple: if the new observation matches what we already know, merge it. If not, create a new entity.

The reality is messy.

Consider: A tracked vehicle was last seen heading west on a road 30 minutes ago. A new observation shows a vehicle heading west on a road 4 km from the last known position. Same road? Same vehicle? The position is consistent with the last known heading and a reasonable speed. The visual signature is similar but not identical — different lighting angle, partially occluded. The vehicle type matches.

Probabilistically, this is probably the same entity. But it's not certain.

The knowledge graph maintains a probabilistic entity model — a distribution over possible states rather than a single point estimate. When a new observation arrives, it computes the probability that the observation matches each existing entity, as well as the probability that it represents a new entity.

If the best match exceeds a configurable threshold (e.g., 85%), the observation is merged — the entity's state is updated with the new information, and the confidence model is revised. If not, a new entity is created and linked to the ambiguous observation.

This probabilistic approach is essential for contested environments where deception, decoys, and deliberate signature management are common.

Temporal Persistence: The 30-Minute Problem

One metric tracks a vehicle through all sensor modalities. Then connectivity drops. Sensors go dark. Thirty minutes of nothing.

When coverage resumes, the system needs to:

A well-designed knowledge graph handles this by maintaining a temporal model for each entity. The model includes:

Under NovaFuse's IDEaS research, we've demonstrated entity reacquisition after 30-minute dropouts with >90% correct matching — significantly exceeding the track-handoff performance of conventional tracking systems under similar conditions.

Distributed Knowledge Graphs: Edge and Backend

In NovaFuse's split architecture, knowledge graphs exist in two places:

Backend knowledge graph: The authoritative, comprehensive model. Contains all entities, all observations, all historical data. Supports complex queries, long-horizon analytics, and cross-mission correlation.

Edge knowledge graph: A compressed, mission-relevant subset. Contains currently active entities, recent observations, and local context. Operates within SWaP constraints on tactical hardware.

The challenge is synchronization — keeping the edge graph current with the backend when connectivity is intermittent. We use delta-encoding: only the changes (new entities, updated attributes, deleted relationships) are transferred, not the entire graph.

In testing, we've synchronized a 500-node edge knowledge graph with the backend in under 2 seconds over a 10 Mbps link — fast enough for periodic updates during connectivity windows.

Why This Matters

Piecemeal detection is not situational awareness. Snapshots are not understanding. A system that detects platforms every 30 seconds but can't tell you which detections correspond to the same entity is not tracking — it's just detecting in a loop.

Persistent entity tracking via knowledge graphs is what transforms a detection system into a tracking system. It's what gives operators continuity, context, and confidence in the operational picture.

For the Canadian Armed Forces, operating in vast, complex areas of responsibility with limited sensor coverage and contested electromagnetic environments, persistent tracking isn't a feature. It's the point.

NovaFuse Inc. is researching knowledge graph-based persistent entity tracking under IDEaS CFP-006. We are an Ottawa-based, 100% Canadian-owned AI company. Contact us at info@novafuse.ca to discuss your tracking challenges.