Onboarding Authorities

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

1. Authority Org Onboarding

Authority orgs onboard the same way operators do — corporate identity, regulatory standing, agreed scope of jurisdiction — and receive an Authority Org Certificate under the Authority Credentialing CA.

The org cert is annual. Within the authority, individual users are credentialed separately — see §2.

2. Field Verifier Credentialing

A user inside an authority org with the field-verification permission can perform offline disclosure on a managed device. A field-verification action requires three independent factors at every offline reveal:

These are bound together at credential issuance. The person-bound credential is short-lived (typically hours to days of offline validity) and geographically scoped by default. The authority org holds a long-lived org cert; person and device credentials are issued under it and rotate frequently.

3. Field Device Setup

The device is enrolled by the authority org through its MDM (Mobile Device Management) system and registered with ATOMx. Enrollment installs:

• ATOMx Root public key (trust anchor)
• Current Manufacturer CA list and revocation snapshots
• Authority Org Certificate
• Per-device managed-device certificate
• Per-person credential template (issued at login)
• Capsule cache (pre-synced for the jurisdiction)
• One-tap purpose codes scoped to the user’s role within the authority

Person-bound credentials require live authentication at the start of each shift and re-authentication at policy intervals. The credential carries geographic and time scope; verification outside that scope requires break-glass — see Disconnected Operations §6.5.

4. Slack-Connect Federation

Authorities connect to peer authorities through a Slack-Connect-style federation model rather than schema-level merging. Each authority chooses what to share with each peer:

• Jurisdiction boundaries (or specific sub-zones)
• User lists (for cross-agency operations)
• No-fly geometries
• Endorsement signing privileges within a peer’s airspace

Cross-agency coordination becomes opt-in selective sharing, not centralized identity federation. See Origins and Decisions §7.2.

5. Form Builder per Authority

Each authority defines its own intake form for flight-authorization requests in its airspace. Fields, validation rules, and required attachments are authority-specific. Versioning of forms across authorities is an open question — see Origins and Decisions §9.

6. Selective NFZ

A no-fly zone may be configured to be invisible to authorized pilots (their map does not show it) while still being enforced for unauthorized aircraft. The geometry exists; disclosure of it is policy-gated. See Origins and Decisions §7.3.

7. Regulatory Anchoring and Inter-Agency Agreements

7.1 What Makes an Org an Authority

Authority status is not self-asserted. An org is admitted as an Authority only on the basis of an explicit regulatory or delegated authority claim, anchored in:

ATOMx records the citation alongside the Authority Org Certificate so endorsements carry an auditable basis for jurisdiction.

7.2 MOU / IGSA Pattern

ATOMx does not act unilaterally to grant authority status. The standard pattern is:

1. ATOMx and the candidate authority sign an MOU (federal partner) or IGSA (intergovernmental services agreement, state/local) that establishes:
   • Scope of jurisdiction (geographic + operational)
   • Endorsement signing rights and authority key custody (ATOMx-held, see Authorization Package §4)
   • Field-verification permission grant scope
   • Evidentiary export terms (see §7.4)
   • Incident notification and response commitments
   • Termination and transition clauses
2. ATOMx provisions the Authority Org Certificate
3. Authority enrolls administrators, who in turn enroll field verifiers

7.3 Jurisdictional Boundary and Concurrent-Claim Disputes

Overlapping authority is the norm, not the exception (federal + state + local; aviation + protection; etc.). ATOMx does not resolve disputes — it surfaces them. When two authorities have overlapping jurisdiction over a flight:

• Both must endorse before the Authorization Package issues (the approval invariant — see §7.1 Approval Invariant in Origins)
• If one approves and the other denies, the package does not issue; the operator sees a denial without naming which authority denied
• Pre-coordination between authorities (handoff at boundaries, NSSE-style joint operating cells) is supported via the federation model — see §4
• Disputes over jurisdiction itself are out-of-band; ATOMx does not adjudicate which authority is correct

7.4 Evidentiary Export and Court Discovery

Authority operations against ATOMx may be the subject of court discovery, FOIA, IG inquiries, or after-action reviews. ATOMx supports:

• Read-only audit console for authority-side review of their own org’s signing events, disclosure events, and field-verifier actions
• Signed evidentiary export — a portable record of a specific incident or time window, signed by ATOMx, that a court or auditing party can verify independently
• Chain-of-custody preservation — exports include hash-chain anchors so a recipient can confirm no events were dropped or altered between the live audit ledger and the export
• Body-cam correlation hooks (where the authority captures body-cam during field verification, the disclosure receipt can carry a body-cam reference for joint correlation)

7.5 Classified-Jurisdiction Handling

Some federal facilities operate in airspace whose existence, geometry, or operations are classified at varying levels. ATOMx supports a classified jurisdiction mode:

This requires a deployment posture aligned with the classification level (FedRAMP High, IL5/IL6 cloud, isolated tenancy as appropriate). It is a roadmap capability for the broadest ATOMx deployment; MVP does not include classified-jurisdiction handling.

7.6 Incident Command and Scene-Commander Override

For active incidents (active shooter, wildfire, hazmat, mass-casualty event), the senior on-scene commander may need temporary endorsement-signing authority that they do not normally hold. ATOMx supports an Incident Command override path:

• Pre-authorized at MOU level for specific authority orgs (typically state/local emergency management)
• Activated by a named scene commander with second-person witness
• Limited to the geographic and time scope of the active incident
• Logged distinctly so post-incident review can examine the override use

8. Cross-References

• The endorsement signature flow that uses authority credentials: Authorization Package §3
• Field verification in austere environments: Disconnected Operations §6
• The org-type substrate: Disconnected Operations §2.1

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.