ATOMx — Product Overview

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

What ATOMx Is

ATOMx is a multi-authority airspace authorization network. It connects operators, authorities, and existing airspace management systems through a shared authorization record — so that every agency whose airspace a flight touches sees the same picture, in real time, without phone calls between them.

ATOMx is not a Common Operating Picture. It is a coordination plugin: a service layer that sits between supplemental data service providers (sensor networks, Remote ID, UTM Service Providers) and the COPs, tactical displays, and agency systems that authorities already use. ATOMx enriches those systems with authorization context and trust classification. It does not replace them.

The Problem

The bottleneck in multi-authority UAS coordination isn’t detection — sensor networks are increasingly capable of tracking aircraft across wide areas. The bottleneck is two compounding problems that no existing system addresses together.

Authorization records are not shared. An operator who has gone through a legitimate authorization process — filed a plan, been vetted, received approval — looks identical to an unknown aircraft when viewed by any agency that wasn’t part of that original approval. Compliant operators and unauthorized flights are indistinguishable at machine speed. Every unrecognized aircraft triggers a manual investigation that can take minutes or tens of minutes for a determination that should take seconds.

Identity is declared, not verified. Even when an authorization record can be found, the identity information underlying it is largely self-reported. Remote ID broadcasts what the operator claims. Flight plans are submitted, not authenticated. Certifications are filed by the operator, not independently verified at the moment of flight. The current system tells authorities what was declared — it provides no machine-readable confirmation that those declarations are true.

These problems are sharpest at the boundary where federal authorization frameworks (LAANC, AAP) end and state, local, and agency-specific restrictions begin. There is no shared record across that boundary, and no mechanism that automatically makes one authority’s approval visible to another whose jurisdiction the same flight touches.

What ATOMx Delivers

One shared authorization record. A flight plan submitted through ATOMx is routed to every authority whose jurisdiction it touches. Each authority approves their segment independently. The result is a single, real-time authorization record visible to all relevant parties — no bilateral coordination, no phone calls.

Trust classification. Every aircraft in the ATOMx operating picture carries a trust level based on what can be independently verified about its identity, its authorization, and its operator. Authorities know, at a glance, whether an aircraft is unknown, self-declared, correlated to a flight plan, or fully verified — without manual investigation.

A coordination layer, not a COP replacement. ATOMx publishes trust-classified aircraft data and authorization state through a standard Outbound API. Existing COPs — Lattice, Maven, agency-specific dashboards — consume this feed as clients. Operators on TAK or CivTAK receive ATOMx’s authorization status directly in their existing tactical display.

Trust Levels

Non-conformance is a separate flag, not a trust level. A Verified aircraft that deviates from its authorized area is still Verified — the flag signals a known deviation, not a loss of identity.

Product Surfaces

Network Effects

ATOMx’s long-term defensibility isn’t its feature set — it’s the authorization network itself. Once multiple agencies rely on ATOMx as a shared authorization layer, each new agency that joins makes the platform more valuable for everyone already on it. Operators must use it wherever it’s required. Authorities join because the operator roster is already there.

The bootstrapping path: an anchor contract establishes the mandate in a specific operational area. Operators flying there must use ATOMx, creating the initial operator population. Adjacent authorities inherit that operator roster when they join, removing the cold-start problem.

Related Documents