Identity switches in ADAS and video surveillance: what unreliable tracking really costs

A pedestrian crosses in front of the vehicle. The camera detects them, tracks them, and assigns them an identifier. Then a car passes between the two, a half-second of occlusion, and the moment the pedestrian reappears, the system assigns them a new identifier. For the decision module, it is no longer the same person. It is a new target, appeared out of nowhere, one meter from the trajectory.

This is what is called an identity switch. On paper, it is a line in a performance report. In production, it is what separates normal braking from an unjustified emergency stop.

This article starts from a technical metric, -46% of identity switches measured on TrustalAI V-Tracking and explains what it really changes, in euros and in safety, for two families of systems: ADAS and urban video surveillance.

What is an identity switch, concretely?

A tracking system does not just detect objects frame by frame. It must link these detections over time: understand that the pedestrian in frame 100 is the same as the one in frame 130. Each object receives an identifier that it must keep as long as it remains in the field.

An identity switch occurs when this identifier changes while the object itself has not changed. Or, conversely, when two distinct objects inherit the same identifier. Three situations trigger this in practice:

• Occlusion: one object hides another for a few frames, then reappears. The tracker has "lost" it and re-initializes it as a new object.

• Crossing: two trajectories cross, and the system swaps their identifiers at the point of contact.

• Dense scene: saturated traffic, crowd, parking lot, when objects are numerous and close, association becomes ambiguous and identity errors multiply.

The important point: an identity switch is almost never visible in an average performance metric. A tracker can display an excellent overall detection rate and make identity errors precisely at the most critical moments—occlusion, crossing, density. The average remains good. The local decision, however, becomes incorrect.

In ADAS: an identity switch is an unjustified emergency stop

Let's take the pedestrian occluded for a half-second. Before the occlusion, the system was tracking a continuous, predictable trajectory at a constant speed. After the switch, it sees a "new" target, with no motion history, which it must treat as a sudden appearance in the immediate vicinity.

The most cautious reaction the decision module can take when faced with an unqualified appearance is to brake. Hard. This is the unjustified emergency stop, a phantom braking triggered not by a real danger, but by a loss of continuity in tracking.

The consequences are measured at several levels. First, safety: sudden braking for no apparent reason increases the risk of rear-end collision and degrades the driver's trust in the system. Second, validation: each unjustified emergency stop is an event to be analyzed, documented, and corrected before homologation. On SAE L3/L4 autonomy levels, this translates to validation time and compliance costs.

The regulatory context makes this point central. The EU AI Act (Regulation 2024/1689) classifies ADAS among high-risk systems. Perception reliability is no longer just a product issue: it becomes a documentable obligation of result. And when a perception pipeline multiplies identity errors at critical moments, it is precisely this reliability that cannot be proven.

Field incidents highlight the stakes. In April 2026, a system failure immobilized over a hundred Apollo Go robotaxis in Wuhan, reported by TechCrunch and confirmed by CNN. Perception dropping out in dense scenes does not remain a laboratory subject: it paralyzes a fleet on public roads.

In video surveillance: an identity switch is a false alarm

Let's change setting. An urban video surveillance camera tracks movements in a busy street. The system is supposed to raise an alert on a specific behavior: an object staying in place too long, a trajectory entering a restricted area, a target disappearing and then "reappearing" elsewhere.

An identity switch falsifies each of these triggers. The same person, counted as two individuals, artificially inflates a crowd count. A target that changes identifier after an occlusion behind a post can trigger an "abandoned object" or "intrusion" alert when nothing actually happened.

The cost is not theoretical. Every false alarm mobilizes an operator, sometimes an intervention. On a city scale, surveillance systems generate thousands of alerts per day, mostly false positives. Beyond the operational cost, there is a trust cost: a system that "cries wolf" too often ends up being ignored, which defeats its purpose.

Industry benchmarks give an order of magnitude: more reliable perception can reduce video false alarms by about -50% (Hanwha Vision, 2024). This is an industry benchmark, not a TrustalAI result, but it highlights the scale of waste that unreliable tracking maintains daily.

From metrics to ROI: why -46% of identity switches changes the equation

Here is the business translation, the only one that matters to a decision-maker.

In ADAS, fewer identity switches means fewer trajectory re-initializations, therefore fewer "ghost" appearances, and therefore fewer unjustified emergency stops. Each avoided braking is one less risk of rear-end collision, a preserved driver experience, and one less event to investigate in the validation file.

In video surveillance, fewer identity switches means accurate counts, alerts that correspond to real events, and operators addressing incidents rather than noise.

This is where TrustalAI V-Tracking comes in. The product ensures real-time, multi-object, learning-free tracking: no retraining, no access to model IP, it works on the existing detection flow. Its official metrics (Client Deck 9.1, TRL9):

These figures are the official product metrics of TrustalAI V-Tracking. They are distinct from the VEDECOM PoC (cooperative perception, multi-sensor fusion) and the industry benchmarks cited above. Confusing them would be overinterpreting data—exactly the opposite of what we aim to deliver.

The fundamental difference: reliability by prediction vs. aggregated monitoring

This is the distinction that shapes the entire TrustalAI positioning, and it applies directly to identity switches.

The dominant approach to tracking AI quality relies on aggregated monitoring: observing system behavior after the fact, over time windows, through averages. Global detection rate, switch rate over an hour, performance curves. This is useful for steering a trend or detecting model drift over time.

But this monitoring is by nature post-mortem. When an aggregated metric signals a degradation, the unjustified emergency stop has already occurred. The false alarm has already been sent. The risk has already entered the operation.

Reliability by prediction (per-prediction reliability) reverses this logic. Instead of measuring average quality after the action, it attaches a confidence metric to each prediction, in real-time, before the downstream decision is made. Concretely, for tracking: the system doesn't just say "here is target 7". It qualifies the reliability of this identity association, at this precise moment, so the decision module knows if it can trust it.

This is the difference between knowing, at the end of the day, that the tracker made too many identity errors, and knowing, at moment T, that this specific association is weak because we are in the middle of an occlusion. The first piece of information is used for a report. The second is used to avoid braking.

This reliability layer is added as a reliability brick on top of the existing model. It is black-box compatible, requiring no modification to the detection model and no access to its weights, and operates at 20 ms on the edge, <100ms in the cloud. For the system integrator delivering a perception cell under an obligation of result, this is documentable proof of reliability added without touching the existing chain.

What this changes for compliance

The EU AI Act and the Machinery Directive (now Regulation 2023/1230) impose a common logic: moving from static qualification to continuous assurance of reliability, as analyzed by Robotics & Automation News. A monthly aggregated metric is not enough to demonstrate that a specific decision was reliable at the moment it was made.

Reliability by prediction generates exactly the trace that compliance requires: for each tracking prediction, a timestamped confidence metric. TrustalAI contributes to this reliability documentation without certifying compliance, which remains the responsibility of the competent bodies.

FAQ

What is an identity switch in video tracking?

It is an error where the tracking system changes an object's identifier while the object has not changed, or assigns the same identifier to two distinct objects. It occurs mainly during occlusions, trajectory crossings, or in dense scenes. Consequently, the decision module believes it sees a new target or confuses two targets.

Why does an identity switch trigger an emergency stop in ADAS?

When a tracked object changes identifier after an occlusion, the system loses its motion history and treats it as a sudden appearance nearby. Faced with an unqualified and close target, the most cautious reaction is to brake heavily, resulting in an unjustified emergency stop, or phantom braking, without real danger.

What is the difference between reliability by prediction and aggregated monitoring?

Aggregated monitoring observes average performance after the fact, over time windows. Reliability by prediction associates a confidence metric to each prediction, in real-time, before the downstream decision. The first is used to analyze a trend; the second helps avoid errors when they occur.

Does TrustalAI V-Tracking require retraining my model?

No. TrustalAI V-Tracking is learning-free and black-box compatible: it works on the detection flow of your existing model, without retraining or access to its IP. The reliability layer is added plug-and-play and operates at 20 ms on the edge, <80ms in the cloud.