0008 - Alerts & Notifications

Andi Lamprecht ·2026-05-11· 7 min read· Draft

Problem Statement

UAS incident management involves too many stakeholders with too little shared context. When something goes wrong — a non-conformant aircraft, an L1 or L2 incursion, a flight plan that needs immediate review — the coordination effort fragments across agencies, tools, and communication channels. Authorities may not have a direct line to the operator; operators may not know which authority to contact; and escalation paths are inconsistent across jurisdictions.

This PRD covers two related but distinct concepts:

• Alerts — stateful entities with a lifecycle (active → acknowledged or auto-resolved). An alert is created when a triggering event occurs and persists until it is acknowledged by a recipient or the underlying condition resolves itself.
• Notifications — the fire-and-forget delivery mechanism that carries an alert to its recipients (SMS, CivTAK push). A notification is sent; an alert is managed.

ATOMx is positioned as a coordination plugin that lives between supplemental data service providers and common operating pictures. That position makes it the natural place to broker alerts and their notifications without requiring any party to adopt a new COP. Pushing timely, contextual information into the tools people already use — SMS, TAK — is the mechanism.

Business Justification

• Demo storytelling: Real-time SMS and CivTAK push notifications demonstrate that ATOMx is a coordinator and facilitator, not another display. This is the “wow factor” that distinguishes the product in front of JIATF and Booz Allen Hamilton.
• Fort Campbell opportunity: Range management at Fort Campbell requires notifying operators and authorities of training events, conformance violations, and airspace incursions. Conversations with Fort Campbell and Fort McNair confirmed that today all coordination happens over radio — there is no digital alert platform in place.
• Product positioning: ATOMx pushes into existing workflows (TAK, SMS, agency tools) rather than replacing them. Alerts and notifications are the clearest expression of this.
• Future integration: Some organizations may already use on-call platforms (e.g., PagerDuty). The architecture should leave the door open to external on-call integration without requiring it now.

Personas

• PER-001 — Julia Rivera, RPIC — receives notifications about flight status and airspace events relevant to her operation
• PER-004 — Jessica Cooper, Airspace Manager — configures alert rules; receives and acknowledges alerts
• PER-007 — Morgan Hayes, Authorization Manager — receives escalation notifications when primary recipients don’t acknowledge

Outcomes

User Journey

    sequenceDiagram
    actor AM as Airspace Manager
    participant ATOMx
    participant NS as Alert & Notification Service
    actor Recipient
    actor Esc as Escalation Target

    Note over AM,NS: Configuration
    AM->>ATOMx: Create alert rule — trigger type, recipient group,<br/>escalation target, acknowledgement timeout
    ATOMx->>NS: Persist rule

    Note over ATOMx,Esc: Event fires
    ATOMx->>NS: Non-conformance / L1-L2 detection / flight plan submission
    NS->>NS: Match trigger → resolve recipient group<br/>(by user group or geofence/area)
    NS->>Recipient: Deliver via configured channel<br/>(SMS or CivTAK)
    NS->>ATOMx: Record in alert history

    Note over Recipient,Esc: Acknowledge, self-resolve, or escalate
    alt Recipient acknowledges before timeout
        Recipient->>ATOMx: Acknowledge
        ATOMx->>NS: Update status → ACKNOWLEDGED
        Note over NS,Esc: Escalation cancelled
    else Triggering condition resolves itself
        ATOMx->>NS: Non-conformance cleared / condition resolved
        NS->>NS: Auto-resolve alert
        Note over NS,Esc: Escalation cancelled
    else No acknowledgement and event still active
        NS->>Esc: Deliver to escalation target<br/>via configured channel (SMS or CivTAK)
    end
  

Requirements

Alert rule configuration:

• An authority can configure an alert rule specifying: a triggering event type, a primary recipient group, an escalation target group, and an acknowledgement timeout
• Trigger types are authority-configured — there are no default rules. The authority must explicitly set up each rule including the event type, target audience, and timeout
• Supported trigger types for the demo:
  1. Non-conformance — an aircraft operating in violation within a jurisdiction
  2. L1 or L2 detection — on first detection or declaration of an L1 or L2 aircraft in the jurisdiction
  3. Flight plan submission — when a new flight plan is submitted for review
• Recipient groups can be defined by explicit user membership (named users) or by area/geofence (all users associated with a geographic zone), or both
• Each ATOMx user has a configured delivery channel (SMS or CivTAK); alert notifications are delivered to their configured channel

Delivery — SMS:

• When a rule triggers, all members of the primary recipient group receive an SMS
• SMS recipients include both operator and authority users as configured

Delivery — CivTAK:

• When a rule triggers, CivTAK-configured recipients receive a push notification on their TAK device
• CivTAK delivery must work on physical iOS and Android devices, and on a Mac-hosted Android emulator (for virtual demos via screen share)

Escalation:

• If no member of the primary recipient group acknowledges the alert within the configured timeout, and the triggering condition has not self-resolved, the escalation target group receives the same notification
• If the triggering condition resolves itself before the timeout expires (e.g., non-conformant aircraft returns to conformance), the alert auto-resolves and escalation is cancelled
• Escalation is one level: primary group → escalation group

Alert history:

• All alerts and their notifications are visible in an alert history log within ATOMx, showing trigger type, timestamp, recipients, delivery status, and acknowledgement state
• The log is real-time — new entries appear immediately as alerts fire, without a page refresh. This also serves as a demo visibility tool, allowing a facilitator to show notifications arriving live during a demo

Stretch — deep link access:

• The SMS notification contains a time-bound URL granting the recipient authorized read-only access to a scoped ATOMx view
• The scoped view shows only data relevant to the triggering notification (e.g., non-conformant aircraft: that aircraft’s current position and submitted flight plan only; no other traffic visible)
• Access expires after the configured time window

Scope

In scope:

• SMS delivery (demo-grade; single provider, no retry SLA)
• CivTAK push — physical device and Mac emulator
• Trigger types: non-conformance, L1/L2 detection, flight plan submission
• Recipient targeting by explicit user group and/or area/geofence
• Single-level escalation (primary group → escalation group, configurable timeout)
• Alert auto-resolution when triggering condition clears
• Alert history log (real-time + historical)
• Stretch: time-bound deep link with scoped read-only ATOMx view

Out of scope:

• Mock RFMSS scheduled event triggers (may be revisited in a future milestone)
• Real RFMSS integration (future workstream)
• Email or push notification channels beyond SMS and CivTAK
• Multi-level escalation chains
• Full incident management lifecycle (assign → resolve tracking in ATOMx)
• Sit-x integration
• Production-grade SMS reliability, retry, or delivery guarantees
• Integration with external on-call platforms (e.g., PagerDuty) — future consideration; architecture should not preclude it

Operational Environment

Physical — Notifications must reach users in the field (operators on a flight line, range safety officers in a vehicle) and in command centers. SMS reaches any cellular-connected device. CivTAK reaches ruggedized handhelds, phones, and tablets already carried by military and public safety operators.

Regulatory — No additional regulatory constraints beyond those in the base ATOMx operational environment. Notification content should not expose PII or controlled information to unintended recipients; deep link scoping is the mechanism for controlling access.

Organizational — Alert rules are configured by authority-side users. Both operator and authority users may appear in recipient or escalation groups. The escalation target is explicitly configurable — there is no default or assumed chain of command.

Constraints

• Demo scope: SMS and CivTAK are sufficient for storytelling. Production-grade delivery guarantees, retry logic, and additional channels are out of scope for this build.
• CivTAK must work in a virtual demo context: Mac emulator + screen share is an acceptable path.
• Deep link scoping must never expose data from outside the triggering event to an unauthorized or time-expired recipient.

Product Surfaces