UTM Operational Intent Conflict Notification to Operators

Andi Lamprecht ·2026-05-11· 8 min read· Proposed

Metadata

Context and Problem Statement

The UTM USS Standard (ASTM F3548-21 / SDD 2.0) requires the managing USS to notify UAS personnel when operational intent conflicts are detected — specifically when an OI conflicts with a higher-priority OI during state transitions (Accepted, Activated) or modifications within those states (SCD0015–SCD0030), and to deliver those notifications within ConflictingOIMaxUserNotificationTime (SCD0090, SCD0095).

Today, Themis (the UTM engine) performs conflict verification during OI state transitions, but has no mechanism to deliver the results of that verification to operators in the Uncrew UI. The conflict is detected, but the operator is not informed. Themis currently uses Slack for ad-hoc alerting, and the Uncrew UI misuses the mission updates stream for notifications — both are architectural violations that do not meet the traceability, auditability, or latency requirements of the SCD specification.

The SDD 2.0 delivery deadline is March 6, 2026. The platform needs a minimal, requirements-traceable path from UTM conflict detection to operator notification before that date. ADR-0138 (Centralized Notification Service Architecture) proposes the full notification infrastructure; this ADR scopes the minimum architectural changes needed to satisfy the SCD conflict notification requirements and unblock the SDD 2.0 delivery, serving as the Phase 1 precursor to ADR-0138.

Decision Drivers

1. SCD compliance — SYS-886–889 (conflict verification) and SYS-901/902 (operator notification within time bound) must be satisfied for SDD 2.0.
2. March 6 deadline — Only work that can be delivered within the sprint is in scope.
3. Requirements traceability — Every implementation story must trace to an HLR, and every HLR must trace to the originating SLRs. The ARB flagged the absence of this traceability in ADR-0138.
4. Correct architectural pattern — The solution must establish the right pattern (dedicated notification path) rather than deepening existing architectural violations (Slack, mission updates misuse).
5. Extensibility without overbuilding — The Phase 1 implementation must be compatible with ADR-0138’s full architecture without requiring the routing engine, preference service, metadata enrichment, or multi-channel adapters now.

Considered Options

Option 1: Thin Notification Service with Requirements-First Decomposition

Description: Establish a minimal notification service (gRPC API, PostgreSQL persistence, WebGRPC streaming) scoped exclusively to the SCD conflict notification use case. Define HLRs first — decomposed from SYS-884–889 and SYS-901/902 — then map implementation stories to those HLRs. The notification service implements only what the HLRs require: CreateNotification, StreamNotifications with subscription filtering, ListNotifications, and persistence. Themis implements a gRPC client to emit one conflict notification per conflicting OI pair at each applicable state transition. The Uncrew UI subscribes via WebGRPC with a mission-scoped filter.

Pros:

• Every story traces SLR → HLR → Story, satisfying the ARB’s traceability condition
• Scoped to exactly what the SCD requirements demand — no speculative features
• Establishes the correct service boundary and proto contract that ADR-0138 Phase 2+ will extend
• Deliverable within the sprint (7 stories, minimal infrastructure)

Cons:

• No multi-channel delivery (email, Slack) — UI only
• No routing engine or preference management — all connected clients matching the filter receive the notification
• No metadata enrichment — Themis must attach mission_id directly (derived requirement, requires safety assessment)

Estimated effort: Small (7 stories, estimated 1–2 weeks)

Option 2: Direct Themis-to-UI Notification (No Intermediate Service)

Description: Extend Themis’s existing gRPC API with a StreamConflictAlerts RPC that the Uncrew UI subscribes to directly. No new service, no intermediate persistence.

Pros:

• No new service to deploy
• Fewer moving parts for the March 6 deadline

Cons:

• Couples the Uncrew UI directly to Themis’s API for notification delivery — the exact coupling Remek flagged in the ARB
• No persistence or audit trail for notifications — fails SCD auditability needs
• Not extensible to non-UTM notification sources (Mission Service, UAV telemetry) without repeating the pattern per service
• Must be discarded and replaced when ADR-0138’s full service is built — wasted effort

Estimated effort: Small, but throwaway

Option 3: Wait for Full ADR-0138 Implementation

Description: Defer until the complete notification service (routing engine, preferences, multi-channel, horizontal scaling) is built and reviewed by the ARB.

Pros:

• No interim architecture to maintain
• Full feature set from day one

Cons:

• Misses the March 6 SDD 2.0 deadline
• Full ADR-0138 was deferred by the ARB for scope and traceability concerns — no timeline for re-review

Estimated effort: Large (multi-sprint)

Decision Outcome

Chosen option: “Option 1: Thin Notification Service with Requirements-First Decomposition”

We build the minimum notification service scoped to the SCD conflict notification requirements, with HLRs defined before implementation begins. The service, proto contract, and integration patterns are designed to be forward-compatible with ADR-0138’s full architecture — Phase 2+ extends the service rather than replacing it.

Reversibility: Low cost to extend (the proto contract and service boundary are designed for ADR-0138 compatibility). Moderate cost to reverse entirely (producers and UI would need to be re-integrated with an alternative).

Argument

Option 1 is the only approach that satisfies all five decision drivers simultaneously. It meets SCD compliance by providing a traceable path from SYS-886–889 and SYS-901/902 through HLRs to implementation stories. It fits the March 6 timeline because the scope is constrained to exactly what the SLRs require — no routing engine, no preference management, no metadata enrichment, no multi-channel delivery. It establishes the correct architectural pattern (dedicated notification service with a defined proto contract) that ADR-0138 will extend, rather than creating throwaway coupling (Option 2) or missing the deadline entirely (Option 3).

The key discipline of this approach is requirements-first decomposition. The ARB’s primary criticism of ADR-0138 was that it read as a generic notification service design rather than a response to specific system requirements. This ADR inverts that: we start from the SLRs, derive HLRs, and scope the implementation to satisfy those HLRs — nothing more.

The trade-off we accept is that Phase 1 is UI-only, single-channel, and has no preference management. An operator receives all conflict notifications matching their subscription filter, with no ability to mute or configure delivery. This is acceptable for the SDD 2.0 use case because the immediate need is operator awareness of OI conflicts — preference management is a quality-of-life concern, not a compliance requirement.

The derived requirement (HLR-NOTIF-004: adding mission_id to the OIE schema) is the one area where we go beyond what the SLRs explicitly require. This is necessary because the Uncrew UI’s subscription model filters by mission_id, and without it, notifications cannot be routed to the correct operator context in Phase 1. This derived requirement requires safety assessment per DO-178C §5.1.1.d.

Diagrams

Safety Impact

This decision has direct safety impact. The notification path is the mechanism by which operators become aware of OI conflicts that may require action to maintain safe flight operations.

1. Safety-critical data flow: Conflict detection results (safety-critical information) flow from Themis through the notification service to the operator. A failure anywhere in this chain means the operator is unaware of a developing hazard.
2. Derived requirement: HLR-NOTIF-004 (mission_id in OIE schema) is not traceable to a parent SLR and must be submitted to safety assessment.
3. Non-blocking design trade-off: Notification submission is non-blocking to Themis’s primary OI operations (HLR-NOTIF-005). This means a notification failure does not prevent Themis from completing conflict verification — correct for primary function safety — but introduces a risk that the operator is not notified. Mitigation: retry with exponential backoff, circuit breaker, and monitoring of notification submission failure rates.

Mitigations: Write-ahead persistence (persist before ack), idempotency (no silent duplicates or drops), per-notification delivery status tracking, and monitoring dashboards for end-to-end delivery latency.

Assumptions

1. The Uncrew UI can integrate a WebGRPC streaming client within the sprint timeline.
2. Themis can resolve mission_id for OIs that have an associated mission without a cross-service lookup (the data is available locally or via existing relationships).
3. A single PostgreSQL instance is sufficient for Phase 1 notification volume (estimated < 1K conflict notifications/day during SDD 2.0 testing).
4. The Envoy/gRPC gateway in the Uncrew deployment can proxy WebGRPC traffic without configuration changes beyond routing rules.

Constraints

Imposed by this decision:

1. Themis must add a gRPC client dependency on the notification service.
2. Themis must include mission_id in the OIE schema (derived requirement, safety assessment required).
3. The notification service .proto contract must be forward-compatible with ADR-0138’s full API surface — fields and RPCs may be added but not removed.
4. Phase 1 delivers UI-channel-only notifications. Email, Slack, and other channels are deferred to ADR-0138 Phase 2+.

Existing constraints that shaped this decision:

1. March 6, 2026 SDD 2.0 delivery deadline (non-negotiable per Colin Blues / ARB).
2. Platform standardization on Go, gRPC, PostgreSQL.
3. ARB conditional approval of ADR-0138 Phase 1 only.

Implications

1. Proto contract is the ADR-0138 foundation. The .proto file defined in CORE-2650/2651 becomes the contract that ADR-0138 Phase 2+ extends. It must be designed with extension in mind (reserved field numbers, extensible enumerations).
2. ADR-0138 re-review scope narrows. With Phase 1 delivered and traceable, the subsequent ARB review of ADR-0138 Phases 2–4 can focus on the routing engine, preference management, multi-channel adapters, and horizontal scaling — without re-litigating the core service boundary and proto contract.

Related Requirements

Related Decisions

Related Artifacts

• [ARB Meeting Notes — 2026-02-24](confluence-title:///2026-02-24 Architecture Review Board Meeting Notes on Centralized Notification Service Proposal and Concerns): Conditional Phase 1 approval and concerns
• [ADR-0138 — Centralized Notification Service Architecture](confluence-title:///ADR–0138–Centralized Notification Service Architecture): Full notification service design (Phases 1–4)

Notes

• 2026-02-24 — ARB deferred full ADR-0138, approved Phase 1 conditionally. Required: traceability backfill, scoping session, revised documentation.
• 2026-02-26 — This ADR drafted as the requirements-traceable precursor to ADR-0138, grounding Phase 1 in the SCD SLRs rather than in a generic notification service design.