0009 - Rules Engine

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

Problem Statement

Existing national frameworks like the FAA Airspace Authorization Program (AAP) and LAANC give operators a structured path through federal authorization. Authority-specific conditions — a jurisdiction’s own requirements for operating within a zone — have no equivalent structured expression. An authority managing a restricted area may require a pre-existing Certificate of Authorization (COA), a specific class of aircraft, or verified operator identity. Today those requirements exist in briefings, policy documents, or bilateral conversations.

Operators who aren’t part of the right conversation don’t know what’s required until a flight is denied or flagged. There is no machine-readable way for an authority to surface its requirements to an operator at submission time, collect the required declarations inline, or tie compliance to the trust level the operator earns.

ATOMx closes this gap by giving authorities a rules layer: zone-specific requirements that are discoverable by operators before submission, satisfied inline during the submission flow, and visible to all reviewing authorities as part of the authorization record.

Business Justification

• Demo storytelling: Shows ATOMx as a rules-aware coordinator that surfaces authority-defined requirements to operators — not just a track display or approval queue
• Fort Campbell range management: Different zones have different aircraft class and pre-authorization requirements; the rules engine makes these explicit and enforceable
• Nationwide applicability: The same rules pattern — COA declaration, identity verification, aircraft class restriction — applies across military ranges, restricted areas, and public safety deployments
• Foundational for L4 trust: Verified operator identity and declared aircraft characteristics are the precursors to machine-verifiable compliance; the rules engine establishes the collection and attestation layer

Personas

• PER-003 — David Okafor, Jurisdictional Admin — creates and manages rules for zones under their authority
• PER-001 — Julia Rivera, RPIC — discovers zone requirements and satisfies them during flight plan submission
• PER-007 — Morgan Hayes, Authorization Manager — reviews operator-submitted declarations as part of the flight authorization decision

Outcomes

Requirements

Rule management:

• A jurisdictional admin can add one or more rules to a zone
• Multiple rules on the same zone are stacked — an operator must satisfy all of them to proceed
• Zone requirements are discoverable by an operator before initiating a submission (visible on the zone detail view or at the start of the submission form)

COA Rule — pre-existing authorization declaration:

• A jurisdictional admin can add a rule requiring operators to declare and upload a pre-existing Certificate of Authorization (COA) to fly in a zone
• At submission, the operator is prompted to upload a PDF of their COA
• The uploaded COA is attached to the flight record and visible to all authorities reviewing the request
• The reviewing authority approves or denies based on the submitted COA; no automated validation occurs

Verified Identity Rule — login.gov:

• A jurisdictional admin can add a rule requiring verified operator identity to fly in a zone
• At submission, an operator without a current verified identity attestation is prompted to complete identity verification via login.gov (sandbox environment for demo)
• On successful verification, a timestamped attestation is attached to the operator’s profile and visible to all reviewing authorities
• Verification is stored per operator; completing it once satisfies the requirement for future submissions until the attestation expires

UAS Group Restriction Rule:

• A jurisdictional admin can add a rule restricting a zone to specific UAS groups (Groups 1–5, defined by FAA weight class)
• The rule displays the weight and class requirements to the operator at submission
• The operator declares their aircraft’s characteristics (weight, class) via an inline form during submission
• The declared aircraft characteristics are attached to the flight record and visible to all reviewing authorities
• If ATOMx detects that the active aircraft does not match the declared characteristics at activation, the flight is flagged as non-conformant

Submission and activation timing:

• All rules are evaluated at flight plan submission time
• Rules are not re-evaluated at activation; a mismatch detected at activation is treated as non-conformance, not a rule failure

Scope

In scope:

• Three rule types: COA attachment, login.gov identity verification, UAS Group restriction
• Stacking multiple rules per zone
• Operator-facing disclosure of zone requirements before and during submission
• login.gov sandbox integration (not production credentials for demo)
• Non-conformance flag when the active aircraft at activation does not match declared characteristics

Out of scope:

• LAANC integration or coordination with national airspace authorization frameworks
• Auto-approval based on rule satisfaction
• Automated aircraft declaration (future: aircraft hardware declares its own characteristics; for this build, operator-entered only)
• Hardware-based identity enforcement (L5)
• Custom or arbitrary rule types beyond the three defined above

Operational Environment

Physical — Operators complete the submission form on a web interface. Declarations (COA upload, identity verification, aircraft data entry) must be completable from a laptop or tablet before a mission; the flow is not optimized for a phone in the field.

Regulatory — login.gov is a federal identity provider used across U.S. government services. The demo uses the login.gov sandbox; production access requires a formal agreement with GSA. The COA rule acknowledges existing FAA authorization structures without replacing or integrating with them directly.

Organizational — Rules are created by jurisdictional admins and apply to flights within their jurisdiction’s zones. Reviewing authorities see all submitted declarations but do not manage the rules themselves.

Constraints

• Demo uses login.gov sandbox throughout; no production identity verification is in scope for this build
• Nothing prevents an operator from submitting false declarations; enforcement of declared identity and aircraft characteristics is the domain of L4/L5 trust levels, not the rules engine itself
• Rule types are fixed to the three defined above for this build; a general-purpose rule authoring interface is out of scope

Open Items

Product Surfaces