Origins, Decisions, and Open Threads

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

1. How We Got Here

Cryptographic identity binding of UAS, operator, and flight intent is not a new feature — it is a year-long thread that started in policy testimony, hardened into a product concept, became architecture, and is now active engineering. The progression matters because it explains why ATOMx looks the way it does.

2. Naming Evolution

Older artifacts use different names. Reading them is easier with this map:

3. Architectural Decisions

These are decisions made deliberately in meetings, with rationale, that the formal PRD parts do not always preserve.

3.1 Centralized cryptographic authority — explicitly not a blockchain

The Jun 30, 2025 finalized DHS comments deliberately use “centralized cryptographic authority” rather than “one cryptographic chain” or “ledger.” The intent was to avoid implying a distributed-ledger architecture. ATOMx’s audit chain is a signed event log under a single root of trust, not a blockchain.

3.2 Layer on top of Remote ID — do not invent a sideband

“Append a unique ID to the existing Remote ID broadcasts.” — Aug 12, 2025 Legislative Review

ATOMx attestations ride inside the ASTM F3411 Authentication Message (Type 2) under a registered Authentication Type code. ATOMx-unaware receivers see an unknown-type Authentication Message and ignore it. Backwards compatibility was treated as a hard constraint — a single aircraft satisfies regulatory Remote ID and emits ATOMx attestations on the same channel at the same time. This implies a Part 89 amendment is on the policy ask, not a new RF spec.

3.3 Build on IATF + GRAIN, not green-field

Aug 12 Legislative Review identified IATF (already in use by DOT for SWIM) and GRAIN as the foundation. ATOMx is layered on existing federal cryptographic frameworks rather than invented. This is a procurement-and-trust posture as much as a technical one.

3.4 Cryptographic identity scoped out of the near-term RFP

Feb 23, 2026 (Andi / John 1:1): cryptographic identity binding was deliberately removed from an in-flight RFP scope so it could be preserved as a separate White House funding ask. UTM-based cooperative flight-intent submission carries the near-term proposal. The decision was strategic, not technical.

“If I don’t chase it, then I don’t know that we make it.” — John Vernon, Feb 23, 2026

DC250 → IOC → FOC was used as a deliberate timeline-stretch to keep crypto identity in scope past the first six months while justifying the additional funding line.

3.5 Trust ladder is a regulatory product strategy, not just a scoring scheme

The five-level scheme (L1 detected → L5 hardware-verified) is retained even though military counter-UAS partners have asked for three levels (Apr 14 Demo Review). The reason is migration incentive:

“Orange and yellow provide incentive to migrate off legacy systems like LAANC and move toward more blue and green aircraft.” — John Vernon, Apr 14, 2026

L2 (orange) and L3 (yellow) exist to give legacy and partially-cooperative operators a visible upgrade path. Removing them collapses the migration story.

3.6 Blue = software-verified, Green = hardware-verified

The Apr 8 Flight Auth & Identity Demo locked the color split. Blue is L4 (software-anchored cryptographic identity); Green is L5 (hardware-anchored, TPM/secure-element). The whitepaper sometimes labels both as “verified” — operators see the distinction.

3.7 Trust calculation lives in the frontend

Apr 2, 2026 PE Open Office Hour: trust scoring is calculated in the UI/frontend, not the backend. The backend emits raw decorators; the frontend resolves color. Rationale: flexibility — policy can change without redeploying telemetry pipelines. Non-obvious; worth knowing before you go looking for the algorithm in a service.

3.8 Authorization ID is the primary structured identifier

auth-XXXXXXXX (e.g. auth-943da899) is the user-visible identifier on telemetry frames and panels. Flight names and call signs are secondary. Internal call signs prefixed with _ (underscore) are hidden from operator UIs but still allow flight-history correlation — a privacy convention for sensitive operations.

3.9 Conformance only applies at L3 and above

L1 and L2 cannot be “non-conformant” because they have no operational intent to deviate from. A deviating L4/L5 retains its color and pulses red — the trust level does not flicker. This is the signal-to-noise property the whitepaper describes; the L3+ floor is the rule that delivers it.

3.10 Advisory, not blocking

“We advise. The authority decides.” — paraphrased, Jan 16, 2026 Planathon

ATOMx never prevents an operator from submitting. Liability remains with the operator and the approving authority. This is why the rules engine returns advice and why operators may want to show rules on their map (e.g., schools) even when not legally required to avoid them — a deliberate two-layer model: rules-shown vs. rules-evaluated.

3.11 Authorization can be rescinded by external events

Jun 30, 2025: an authorization is not a token issued once and forever. Pop-up TFRs, jurisdiction state changes, or authority action can rescind a live authorization. The capsule and broadcast must reflect amendment/revocation, and the conformance engine must compare against current-authorized-state, not authorized-at-issuance. This is a meaningfully different lifecycle than “JWT until expiry.”

3.12 Revocation by avatar destruction

Mar 5, 2026 ARB landed an elegant primitive: device-pair certificates issued per aircraft connection. To revoke, delete the server-side cert from inventory; the avatar pod dies; the client cert becomes useless. No CRL distribution, no rotation list. Combined with short-lived MTLS sessions issued via CSR (Mar 12 ARB), this collapses the revocation problem for connected operations. Disconnected operations retain CRL snapshots in the capsule — see Disconnected Operations §3.1.

3.13 TPM-or-encrypted-vault fallback for BYOD aircraft

Mar 12 ARB: when an OEM lacks a TPM, the fallback is a non-root encrypted vault inside a read-only Docker container, with explicit liability-shift to the customer. The trust tier degrades from L5 to L4. The system does not refuse non-TPM aircraft; it expresses the difference.

4. Telemetry Frame Decoration Model

Each telemetry frame is decorated with three classes of identity metadata, evaluated at the edge and forwarded with the frame:

This frame-level structure is what makes the conformance overlay independent from the trust state, the LiveMap fast, and after-action replay possible.

5. The Five Verification Scenarios

Locked Apr 3, 2026; demonstrated Apr 14. These are the canonical demo cases that cover the matrix.

A sixth implicit scenario — Hardware aircraft, verified pilot, authorized flight, but deviating — keeps its green color and adds a pulsing red conformance overlay. This is the test case for the L3+ conformance rule and the trust-doesn’t-flicker property.

6. Pilot Identity Channels

PRDs reference “verified pilot identity” abstractly. The concrete channels named across meetings are:

• login.gov — primary federal channel
• PIV / CAC — federal personnel
• Agency SSO + biometric — state and local
• Clear / TSA PreCheck / passport-grade KYC — commercial tier (Apr 3)
• Part 107 credential proofing — recreational/commercial sUAS

FAA DiSCVR is referenced as an authoritative correlation source, not as a primary identity-proofing channel — its availability for direct identity verification is constrained.

7. Multi-Jurisdiction and Federation

7.1 Approval invariant

Every overlapping jurisdiction must independently approve before the Authorization Package is issued. Operators do not see the count or identity of jurisdictions involved — they see one queue, one outcome.

7.2 Slack-Connect-style federation

Jan 22, 2026 ATOMx Team Call introduced the federation model: authorities connect to peer authorities and choose what to share — jurisdiction boundaries, user lists, no-fly geometries. The mental model is Slack Connect, not a federated identity provider. Cross-agency coordination becomes opt-in selective sharing rather than schema-level merging.

7.3 Selective NFZ

Apr 2, 2026: a no-fly zone may be invisible to authorized pilots (their map does not show it) while still being enforced for unauthorized aircraft. The geometry exists; the disclosure of it is policy-gated.

7.4 Form-builder per authority

Authorities define their own intake forms. Version management of forms across authorities is an open question (§9.4).

8. The Four-Layer FAS Framework

The Apr 9, 2026 Andi/Greg whiteboard reframed the entire system as four sequential capability layers, plus a crosscut:

    flowchart LR
    FA["1 · Flight Authorization<br/>multi-authority approval"]
    VI["2 · Verifiable Identity<br/>pilot + OEM + aircraft + auth bundling"]
    CO["3 · Conformance<br/>real-time deviation detection"]
    CT["4 · Containment<br/>polygon deauthorization, route updates"]
    XC["Crosscut: PM · Interop · Security"]
    FA --> VI --> CO --> CT
    XC -.- FA
    XC -.- VI
    XC -.- CO
    XC -.- CT
    classDef l fill:#eef3ff,stroke:#1f6feb
    class FA,VI,CO,CT l
  

Each layer requires the previous to function. The crosscut (Program Management, Interoperability, Security) runs alongside all four. This framing is the cleanest summary of what ATOMx is for: each layer is one of the four “Operational Threat Areas” being addressed, and each is a separate procurement-and-deployment unit.

9. Open Questions and Research Gaps

These are unresolved as of May 2026 — flagged for the roadmap.

10. External Stakeholder Signals

11. Quotes Worth Preserving

“Flight authorizations serve as cryptographic envelopes that bind together pilot identity, aircraft identity, and flight intent with a signature verified by the platform’s private key, creating non-repudiation.” — John Vernon, Apr 3, 2026, [Private] Google Meet

“Real-time verification at machine speed in milliseconds — whether someone is verified, authorized to fly, and cooperative or non-conformant — all in one system across the entire NCR.” — John Vernon, Apr 3, 2026

“There is no such thing as a no-fly zone — airspace access should be layered based on credentials.” — Andy Thurling, Jun 30, 2025, Homeland Security Review

“If you don’t know what normal looks like, how do you know what abnormal looks like?” — Andy Thurling, Jun 30, 2025

“Access to airspace is a privilege and not a right — especially in sensitive areas like the NCR.” — Jake Goldsberry, Aug 21, 2025, CCB

“Whoever owns the key generates the key, and the private key never leaves that device.” — Sybil Melton, Mar 12, 2026, ARB

“Currently registered systems can be easily bypassed with fake registries, unlike smartphones which have more robust identity verification.” — Andi Lamprecht, Jun 30, 2025

“Without enforcement, it’s all pointless anyway.” — Andy Thurling, Jun 30, 2025

12. Source Meeting Index

The structured analysis above draws on 30 deep-read meetings between June 2025 and May 2026. A representative sample, anchored by what each contributed:

Untapped meetings worth follow-up if a future contributor has bandwidth: the Nov 2025 ATOM+UNCREW+NCR working sessions, Apr 17 DroneUp Demo, Apr 29 JTF NCR Debrief, the late-April / early-May Tech Daily Recap series.