Skip to content

SC-05: Connectivity Loss

Andi Lamprecht Andi Lamprecht ·· 3 min read· Draft
Emergency
FieldValue
Scenario IDPER-002-SC-05
Context / TriggerThe concert reaches peak attendance. 40,000 attendees are streaming video and sharing on social media. Cellular network congestion causes Jason’s tablet to lose its data connection to the ATOMx backend. The COP stops receiving track updates. Jason’s area of interest has 4 active tracks that were visible moments ago.

Narrative

The ATOMx mobile field application detects connectivity loss. The display transitions to offline mode: the COP continues to show the last known positions of all 4 tracks, each with a “Last Updated” timestamp and expanding uncertainty ellipses that grow over time to reflect decreasing position confidence [UERQ-SYS-1745, UERQ-SYS-1813(e)].

A prominent “OFFLINE” banner appears at the top of the screen with the last sync timestamp: “Last sync: 2 minutes ago.” The banner is yellow, not red — indicating data is stale but the system was healthy at last contact. The 4 cached track positions are displayed with faded symbology and growing uncertainty circles. Jason knows the positions are approximate and aging.

He cannot receive new non-conformance alerts while offline. He cannot submit sighting reports. He radios the TOC: “Field Unit 3, I’ve lost data connectivity. COP is offline. Last sync 2 minutes ago with 4 tracks in area. Switching to visual-only awareness. Request TOC monitor my area of interest as primary.”

Jessica Cooper at the TOC acknowledges and assigns a Tactical Controller to actively monitor Jason’s area on the TOC COP. Jason continues field operations in visual-only mode. He queues a sighting report locally (a drone sighting reported by a patrol officer) that will upload when connectivity restores.

Seven minutes later, cellular congestion eases and connectivity restores. The app re-syncs: track positions update to current, the uncertainty ellipses collapse to normal size, the “OFFLINE” banner clears. Jason’s queued sighting report uploads successfully. He confirms with the TOC that the COP picture matches. Jason notes that the offline experience was not ambiguous: he knew his data was stale, he knew when it went stale, and the expanding uncertainty ellipses made it visually obvious that confidence was decreasing.

Capability Gap: Offline caching of track data and queuing of sighting reports for later upload are implied by the field operational context but are not explicitly covered by existing UERQ-SYS requirements. This scenario identifies a potential gap for mobile/field-specific offline resilience requirements.
Traceability
Linked End GoalsKnow immediately when data feed is degraded or disconnected. Clearly distinguish “no activity” from “no data.”
Linked CapabilitiesIn-Band Status Flags (UERQ-SYS-1664), Fused Track Output Schema staleness indicator (UERQ-SYS-1813(e)), Uncertainty Growth Model (UERQ-SYS-1745), Degraded Mode Declaration (UERQ-SYS-1680), Fusion Pipeline Failure Consumer Guidance (UERQ-SYS-1806).
Safety RelevanceCritical: trusting a stale COP as current is one of the highest-consequence errors for this persona. The offline mode design — prominent staleness indicators, expanding uncertainty, explicit “OFFLINE” banner — is a safety-relevant display requirement. A COP that silently shows stale data without indication is worse than a COP that clearly shows “data unavailable.” [UERQ-SYS-1806]
Last updated on