SC-05: Data Quality Anomaly
| Field | Value |
|---|---|
| Scenario ID | PER-006-SC-05 |
| Context / Trigger | At 11:40 AM, Rafael observes a track (AUTH-2026-06117, commercial inspection flight) exhibit a sudden 300-meter position jump on the COP. The track was at 180 feet AGL on a steady northbound heading, then instantaneously appears 300 meters to the east at 240 feet AGL. This could be a genuine rapid maneuver, a GPS multipath error, or a fusion artifact from conflicting sensor data. |
Narrative
Rafael sees the position jump and immediately checks the track’s data quality indicators. Trust score has dropped from 0.88 to 0.54 [UERQ-SYS-1638]. The system has flagged the observation with validation failure code “acceleration plausibility exceeded” [UERQ-SYS-1826] — the implied acceleration for the position change exceeds the vehicle’s performance limits.
He checks source attribution [UERQ-SYS-1643]: the track is being reported by two sensors. Provider M-02 (ADS-B) shows the aircraft at the original position (northbound, 180 feet). Provider M-04 (Remote ID) shows the aircraft at the jumped position (east, 240 feet). The fusion pipeline has followed Provider M-04’s more recent timestamp, but the positions are contradictory.
Rafael assesses: this is a sensor disagreement, not a real maneuver. A small UAS cannot physically execute a 300-meter lateral displacement instantaneously. Provider M-04’s Remote ID data likely has a GPS multipath error (common near tall structures — the flight is operating near a bridge).
He flags the track with a data quality annotation: “Sensor disagreement. M-04 Remote ID suspected GPS multipath. M-02 ADS-B position preferred.” He applies the data quality response policy [UERQ-SYS-1756]: “flag and include with reduced weight” for M-04’s observation, effectively weighting the fused position toward M-02’s more plausible report.
He does NOT escalate this as a non-conformance event, because the aircraft’s actual position (per M-02) remains within its authorized volume. He logs the data quality event and notifies the Traffic Data Analyst for provider-level investigation of M-04’s accuracy in the bridge area.
Rafael notes: if he had treated the jumped position as real, the track would have appeared 300 meters outside its authorized boundary, triggering a geofence breach alert and potential rescind. His data quality assessment prevented a false-positive escalation.
Traceability
| Linked End Goals | Detect and flag data quality issues. Classify tracks accurately even with anomalous sensor data. |
| Linked Capabilities | Trust Scoring (UERQ-SYS-1638), Data Quality Flagging (UERQ-SYS-1671), Acceleration Plausibility Validation (UERQ-SYS-1826), Source Attribution (UERQ-SYS-1643), Data Quality Response Policy (UERQ-SYS-1756), Data Quality Attribution (UERQ-SYS-1757). |
| Safety Relevance | Yes: data quality assessment is a safety function. Both directions are dangerous — treating a sensor artifact as real triggers unnecessary response (false positive), while treating a real non-conformance as a sensor artifact suppresses a genuine alert (false negative). Rafael’s ability to distinguish the two depends on the system providing source attribution, trust scores, and validation failure codes. |