Atomx Approvals

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

Title

Context

Authorities will need the ability to create airspaces and rules that ATOMx can use to block or allow operations (flights). Pilots will need to submit operational intents for ATOMx to validate and Authorities to approve.

Scope

This ADR presents the first level break up of ATOMx into its functional components. We don’t attempt to specify the software stack or name tools at this stage. This ADR is about naming and separating concerns.

In the course of writing this ADR we encountered several questions that are out of scope but that will be necessary to answer. These are detailed in the Consequences section of this document.

Definitions

GeoObject

2D or 3D geographic geometry with attributes/metadata to allow classification (e.g.: class airspace or class b airspace) and identification (e.g.: Yankee Stadium).

Rule

A requirement that must be met for a flight to be permitted. There are various types of rules - for instance:

1. Jurisdiction-Level Rules

• Class-Based Rule: Applies to all GeoObjects of a specific kind within a jurisdiction.

  • Example: 500m buffer around all schools in the US.

• Specific Object Rule: Applies to a specific object within a jurisdiction.

  • Example: Do not fly over [Specific School Name].
  • Example: Fly only if GeoObject metadata contains autoapproval field equal to 1

• Exclusion Rule: Explicitly overrides another rule or rules that would otherwise apply for a GeoObject.

  • Example: This jurisdiction ignores the Washington DC Flight Restriction Zone.

2. Derived & Complex Object Rules

• Intersection/Group Rule: Applies to a new type of GeoObject defined by the relationship between existing GeoObjects.

  • Example: LAANC grids defined as the intersection of UASFM and class airspace geometries.

• Non-Intersection Rules A simple rule that attaches to a GeoObject is triggered when an Operational Intent is inside that geometry. A rule may exist that calls for a different relationship - the simplest example is distance to a geometry:

  • Example: A 3NM radius around stadiums in the US creates a new “Stadium GeoObject”.

3. User-Defined Rules

• Custom Geometry Rule: Applies to a custom, user-generated GeoObject.

  • Example: A user draws a polygon on the map and attaches a specific rule to that area.

Ruleset

A set of related rules, e.g.:

• LAANC rules.
• Rules that emergency responders must obey when flying over an emergency response area.
• Rules that prohibits the general public from flying in the emergency response area.

Airspace

A GeoObject with a set of rules applied to it.

Tile

A geographic area yielded by a tiling scheme such as OSM slippy tiles or Uber’s H3.

Jurisdiction

An area under the authority of a governing body who has the power to set out rules applicable in the area, for example: FAA for the US territory or a rectorate of a university that wishes to shape rules for when flying is permitted above the university grounds. Jurisdictions can overlap and/or nest through delegation.

Authority

One of the two main personas in the ATOMx model. Authority has a control over one or many jurisdictions. Can delegate partial or entire control to other authorities, where the portioning can be geographic or qualitative. For instance, FAA can delegate control to FEMA over a particular emergency response area or the security aspect of the approval to TSA.

Pilot

The other main persona and the person that will be in control of the aircraft when flying an eligible flight.

Operational Intent - a flight plan that a pilot submits to authority for approval.

Decision

At the first pass, the overall domain splits into the regulatory and approval domains - the former where rules are created and the latter where they are evaluated. Pilot doesn’t take part in the regulatory domain, while authority is involved in both, but at distinct stages: strategic and operational. An Authority first prepares the rules and later oversees them being applied, manually approving operations as the rules demand. It is very likely that different personnel is in charge of these distinct stages.

Regulatory

GeoObject Pipeline and Rules Service

We must allow authorities to create rules and rulesets as that is their main prerogative. A rule may apply in the entire jurisdiction or to a specific area within it, which is why we also have to allow the authorities to create airspaces, i.e.: pinpoint an area where a rule or rules apply. Because authorities may evolve the rules independently from the areas where they apply, we must allow them to create geoobjects, i.e.: areas that will be later matched by rules. For instance, an authority can map all the schools in the jurisdiction and later decide to permit flight over them during weekends or at night.

Instead of asking Authorities to create airspaces and rules by hand, we will also be required to ingest them from external sources such as advisory databases, FAA, LAANC performance rules or similar. This is why there is a pipeline put in charge of that.

Airspace System

GeoObjects

This service provides an API to allow Authorities manage their GeoObjects. Some GeoObjects need to be transformed (e.g. having a buffer added) before they can be used to create Airspaces. Others can be used as they are. The GeoObjects service provides access to do both, but the exact manner and interfaces are out of scope for this ADR.

GeoObjects that do not require transformation are ready to use and can be inserted into the GeoObject data store directly.

Clients (such as Geodata Service) shall be able to subscribe to the contents of the Geoobject Service storage. They will receive updates expressed as Tiles. Each Tile will be carry zero or more GeoObjects (or Airspaces, which is subject to a followup ADR).

Rules/Jurisdictions

The Rules Service provides CRUD operations for rules. Authorities need the ability to create and manage their own rules. Rules have one or more predicates that are used as criteria to approve or deny flights. Rules are combined into RuleSets that allow for Rules to interact with each other (things like either/or choices).

The FlightPlans service will use the rules to approve or deny flight intents.

Data Flow from Raw Data to Airspace

1. Raw data is inserted into the GeoObject Pipeline

2. The first stage of the pipeline converts raw data into GeoObjects

   1. For GeoObjects that don’t need to be transformed before use, we will support directly inserting GeoObjects, bypassing the pipeline

3. The rules are combined with GeoObjects to create an Airspace

4. The GeoData service requests Tiles that contain Airspaces or GeoObjects depending on the followup discovery that will tell us how to match Rules to GeoObjects. If the GeoData service ends up returning GeoObjects the rules will be applied in the FlightPlans service.

5. Flight plans are validated against the Airspaces via the Validation Library provided by the Rules/Jurisdiction service.

Approvals

This view presents the services, personas, interfaces and dependencies that partake in the process of approving an Operational Intent.

Flights and FlightPlans Services

FlightPlans is the exchange that the Authorities and Pilots contact to mediate Operational Intents until they are approved or rejected. After they are approved they become Flights. Both services look after the same entities, but at distinct moments of their lifecycle. FlightPlans evaluates rules, Flights deconflict. FlightPlans look after an Operational Intent between the time it is submitted or updated until the time it is approved. Only approved flights are subject to deconfliction.

Deconfliction requires a transaction (reserving airspace as if reserving a seat) and therefore Flights are stored in a transactional, geospatial database such as Post-GIS-enabled Postgres. A central database in charge of deconfliction is problematic because it doesn’t scale and its usage is later dismissed when seeking solution for airspace intersections. However, Operational Intents are different to airspaces. Deconfliction needs to only find the first intersecting volume, not all. Operational Intents are temporarily short-lived, which dramatically reduces the search scope. Operational Intents tend to be way less complex (fewer vertices) than airspaces are.

Concerns (function) of Flight and FlightPlans don’t overlap. Flights maintains that immutable register of all flights ever planned, while FlightPlans store intended/initiated Operational Intents.

Lastly, Operational Intents submitted by ATOMx Pilots may not be the only Operational Intents we need to deconflict with. Maybe not a immediate perspective, but Flights could source “external” Operational Intents from something like a DSS.

Flights aren’t exactly immutable (though each change record may be) - an approved Operational Intent can be deleted by the Pilot or rescinded by the Authority. Flights can be changed mid-air when responding to en emergency. Perhaps a useful metaphor is in stating that Pilots ask permission via FlightPlans and they ask forgiveness via Flights.

Naming these services is difficult. The names should really reflect the concept of Operational Intents, but then one would need to be called “Pending Operational Intents” and another “Approved Operational Intents”, which is tedious and lacks brevity.

Geodata Service

The FlightPlans service evaluates how a submitted Operational Intent agrees with the rules set out by the Authority. In doing so, it must find the airspaces the Intent intersects with in order to identify the rules it needs to evaluate. Matching rules to Operational Intents isn’t transactional. There is no requirement demanding that a rule is followed the moment it is published. This permits using a read-only replica of the airspace database and the CPU cycles of the horizontally scalable FlightPlans service to perform the intersections. This instead of asking the database to calculate said intersections. This is why FlightPlans service consumes the airspace-bearing tiles it takes from the Geodata Service in order to find intersecting airspaces. Tiles in turn cut the airspaces to the subregion relevant for the Operational Intent and thus the airspaces are less complex and cheaper to intersect with. Tiles are also an excellent geospatial index.

Consequences

We discovered several open questions that warrant more discovery work

• What does the ERD for Jurisdictions, Rulesets, rules, transforms, predicates and GeoObjects Look like? (including their attributes) to allow us to answer:

  • How do we map Rules to GeoObjects?

    • Should Tiles carry GeoObjects that can be mapped to Rules later, or do they carry Airspaces that refer to Rules by ID?

  • How an Authority can define a Rule (for example, do not fly within 3 miles of a stadium)

• How do we handle altitude references when applying rules? FlightPlan represents altitude in WGS84 for its segments.

  • If a rule requires altitude to be represented in AGL or MSL then how do we handle that? Do we sample the flight plan or precompute the GeoObjects to use a uniform reference.

• Geodata Service - Tile Handling

  • How should the GeoData service manage subscriptions?
  • What is the cache duration for tiles?

• Unpack the GeoObject + Atlas interaction -

  • What interfaces do we need?
  • How are transforms applied?
  • How do we distinguish GoeObjects that need a transform from those that don’t.
  • Does Atlas have an admin interface?
  • Do we need to provide controls to start/stop ingestion?

Alternatives Considered

Regulatory and Approvals

At the first level break up between the regulatory and approvals, we found no alternatives to consider.

We attempted to single out the geospatial domain, but its only purpose is to serve the regulatory. Unlike the approvals, which can just function as an airspace reservation service, the geospatial can’t exist on its own.

We asked the Copilot and it did initially put rules evaluation into the regulatory, but upon reflection, it change its mind

FlightPlans Authorization State Machine

The FlightPlans service is said here to oversee Operational Intents until they are accepted or rejected, which implies, they receive verdicts (events) from the Authorities and progress the Authorizations through its states. Airmap FlightPlans service was different. It only faced the pilots, while Authorties had services dedicated to them (FAA Proxy for LAANC and Operations for the dashboards). The state machine itself was executed in the Authub Service that overlooked each authorization journaling events, states and transitions - essentially a durable execution engine.

This ADR deems this as excessive fragmentation. Authorities and Pilots mediate the same Operational Intents - now.. not true. As it was the case in LAANC, the FAA only wanted to see the fragment of the operation that intersected with the Airspace requiring manual authorization. This ADR thinks that poses no difficulty for the FlightPlans service it posits. Two tables: pilot_operatioal_intents and authority_operational_intent can solve this within a single database controlled by a single service.

Formal Impact

List any systems or services that are impacted by this architectural decision.

Cited by queries

• Multi-authority approval, telemetry sharing, and authority/org IAM coverage — 2026-04-28