System Design and Implementation

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

1. System Components

1.1 Authorization Package Service

The signed-manifest model and endorsement structure produced by this service are documented in Authorization Package. Service responsibilities:

• Create signed authorization package manifests
• Bind identity, aircraft, operation, token, and policy references
• Collect and seal multi-authority endorsements
• Version, amend, and revoke packages
• Store package in audit ledger
• Support offline capsule generation

1.2 Identity Verification Service

The identity substrates this service consumes are documented in Pilot Identity (OIDC / login.gov / PIV / VC) and Aircraft Hardware Identity (TPM / dual-chain / PCR). Service responsibilities:

• Validate pilot/operator identity
• Validate operator organization
• Validate aircraft identity (TPM attestation challenge per Flight Lifecycle §1)
• Support software-validated (L4) and hardware-backed (L5) identity tiers
• Manage credential lifecycle
• Support federation-ready identity assertions for future external trust relationships

1.3 Public Token Service

Responsibilities:

• Create authorization-bound public aircraft token
• Keep token stable within a single authorization by default
• Rotate token across authorizations
• Support stricter token rotation for protected missions
• Prevent public reverse lookup
• Support authorized internal resolution
• Detect duplicate token use

1.4 Protected Field Encryption Service

The envelope-encryption model this service implements is documented in Authorization Package §6. Service responsibilities:

• Encrypt protected identity fields
• Manage key policy
• Support online brokered disclosure
• Support offline field disclosure capsules
• Support field-level disclosure, not all-or-nothing disclosure
• Support key rotation and revocation
• Support purpose-bound access
• Support audit hooks for every disclosure

The default online model should be brokered disclosure through ATOMx. ATOMx may decrypt protected fields inside controlled services after policy approval and return only the permitted fields to authorized users or systems.

Recipient-side encryption should be supported selectively for high-assurance, offline, federal, or special deployment environments, but it should not be the default API integration model because it would complicate common operating picture integrations without necessarily improving practical security.

1.5 Disclosure Policy Engine

Responsibilities:

• Evaluate requester identity
• Evaluate requester organization
• Evaluate role and authority
• Evaluate jurisdiction/geography
• Evaluate event or incident context
• Evaluate purpose code
• Evaluate time window
• Evaluate mission sensitivity
• Determine field-level release permissions
• Record disclosure decision
• Deny, redact, or minimize responses when access is insufficient

For emergency field use, purpose code selection should be one-tap and plain-language. A written narrative can be required later if policy requires it.

1.6 Conformance Engine

Responsibilities:

• Compare telemetry against approved flight plan or operating area
• Evaluate route, area, altitude, time, mission volume, and dynamic restrictions
• Generate conformance state
• Generate reason codes
• Track amendment/revocation compliance
• Support protected mission location-generalization policy
• Support local verification logic for offline mode

Conformance should be evaluated against the approved operation. The approved operation may be:

• Specific route
• Waypoint plan
• Operating polygon
• Altitude band
• Mission volume
• Time window
• Response area
• Patrol area
• Emergency operating area

1.7 Telemetry Ingest and Fusion Layer

Responsibilities:

• Ingest primary operator/control-system telemetry
• Ingest aircraft-originated telemetry
• Ingest broadcast observations
• Ingest third-party cooperative data
• Ingest non-cooperative sensor observations where available
• Deduplicate tracks
• Assign provenance
• Assign source confidence
• Detect mismatch, stale data, duplicate token use, replay, and suspicious divergence

Default rule: Primary telemetry comes from the operator/control system or aircraft. ATOMx uses corroborating feeds to validate, cross-check, downgrade confidence, or generate alerts when reported and observed telemetry diverge. Telemetry confidence should affect authorized-user state, not public state.

1.8 Trust State Engine

Responsibilities:

• Produce public trust state
• Produce authorized operational state
• Keep authorization, identity trust, and security alert state separate
• Apply mission protection policy
• Apply public visibility policy
• Prevent over-classification of cooperative aircraft as threats

The public trust state should never expose detailed telemetry confidence, reason codes, protected identity, or security-alert details.

1.9 Audit and Evidence Ledger

Responsibilities:

• Preserve authorization package creation
• Preserve package versions and amendments
• Preserve public token assignment
• Preserve telemetry history
• Preserve conformance history
• Preserve protected disclosure events
• Preserve revocation/amendment instructions
• Preserve compliance response
• Preserve offline reveal events once synchronized
• Preserve security alerts and investigation events
• Preserve API access logs

The audit model should be tamper-evident. It should support incident reconstruction, regulatory review, dispute resolution, enforcement, and internal debugging.

1.10 API Gateway

ATOMx should be API-first. Responsibilities:

• Provide trust state feeds
• Provide conformance feeds
• Provide protected disclosure endpoints
• Provide telemetry confidence metadata to authorized systems
• Provide audit access where permitted
• Integrate with existing common operating pictures, public safety tools, airspace-management systems, and security platforms
• Support the ATOMx operational airspace awareness interface

API responses must be field-level policy filtered. The same aircraft may produce different API responses depending on requester role, geography, purpose, and authority.

1.11 Operational Airspace Awareness Interface

Responsibilities:

• Provide native awareness for organizations without a mature common operating picture
• Show public trust state and authorized operational detail based on user permissions
• Support protected disclosure workflows
• Support one-tap purpose code selection
• Support incident and after-action workflows
• Support investigation workflows
• Support audit review where permitted

This interface should not be described as replacing every customer COP. It is the native ATOMx operational interface for users who need a lower-cost or purpose-built airspace awareness capability.

1.12 Offline Verification Module

The capsule format, RF broadcast layering, and field-verification flow this module implements are documented in Disconnected Operations. Module responsibilities:

• Verify authorization package or offline capsule signatures
• Validate validity window (with monotonic-counter time anchoring per Threat Model §5)
• Validate scoped field-user credential
• Validate managed device credential
• Validate geographic scope
• Validate purpose code
• Decrypt permitted protected fields
• Locally compare broadcast aircraft telemetry against signed approved operation
• Generate signed disclosure receipt
• Reconcile disclosure, telemetry, and verification events when connectivity returns

2. Connected Mode Flow

Service-architecture view. The connected runtime is documented in detail in Flight Lifecycle — that page is the canonical reference for Phase 0 (drone onboarding), Phase 1 (pre-flight authorization), Phase 2 (in-flight telemetry binding), mid-flight events, and reconciliation. The sequence diagrams here describe the service interaction shape behind that runtime, which is the engineering view this page owns.

2.1 Pre-flight or Pre-operation

    sequenceDiagram
    autonumber
    participant Op as Operator
    participant Auth as Authority Workflow
    participant ATOMx
    participant KMS as Encryption / KMS
    participant Tok as Public Token Service
    participant Led as Audit Ledger
    participant Cons as Approved Consumers
    Op->>Auth: Submit flight plan / operating area
    Auth->>ATOMx: Validated identities + approval context
    ATOMx->>ATOMx: Build signed Authorization Package manifest
    ATOMx->>KMS: Encrypt protected claims
    ATOMx->>Tok: Generate authorization-bound token
    ATOMx->>ATOMx: Attach trust, disclosure, conformance policies
    ATOMx->>Led: Persist package + version
    ATOMx-->>Cons: Operational view (policy-filtered)
  

1. Pilot/operator submits flight plan or operating area through an approved workflow.
2. Aircraft identity and pilot/operator identity are validated.
3. Approval context is established by the appropriate authority or authorization workflow.
4. ATOMx creates a signed authorization package manifest.
5. Protected fields are encrypted.
6. Public aircraft token is generated and bound to the authorization.
7. Public trust policy and disclosure policy are attached.
8. Conformance policy is attached.
9. Authorization package is stored in the audit ledger.
10. Approved systems receive the appropriate operational view through API or UI.

2.2 In-flight Connected Operation

1. Aircraft or operator system streams telemetry.
2. ATOMx compares telemetry against approved operation.
3. ATOMx produces conformance state.
4. ATOMx produces public trust state where policy allows.
5. ATOMx produces authorized operational state for approved users and systems.
6. Corroborating sources validate or challenge telemetry.
7. Telemetry confidence and mismatch indicators are generated for authorized users.
8. Protected fields remain encrypted unless disclosure is approved.
9. Every status change and disclosure event is logged.

2.3 Protected Disclosure

    sequenceDiagram
    autonumber
    participant Req as Authorized Requester
    participant API as API Gateway
    participant Pol as Disclosure Policy Engine
    participant Enc as Protected Field Encryption
    participant Led as Audit Ledger
    Req->>API: Request protected fields (purpose, role, geo, event)
    API->>Pol: Evaluate request context
    alt Approved
        Pol->>Enc: Decrypt permitted fields only
        Enc-->>API: Released field values
        API-->>Req: Field-level filtered response
    else Denied / Redacted
        Pol-->>API: Decision + redaction
        API-->>Req: Denied or minimized response
    end
    API->>Led: Log disclosure event (requester, purpose, fields, decision)
  

1. Authorized user or system requests protected field access.
2. Disclosure Policy Engine evaluates identity, role, geography, purpose, authority, time, and incident context.
3. ATOMx releases only approved fields.
4. Disclosure event is logged with requester, purpose, fields released, time, operation, and policy decision.

2.4 Amendment or Revocation

1. ATOMx receives or creates an operational change, such as a new restriction, emergency event, priority operation, or safety conflict.
2. ATOMx determines affected authorizations.
3. ATOMx amends or revokes the relevant authorization state.
4. ATOMx sends machine-readable compliance instruction to the operator/control system.
5. Suggested actions may include exit, hold, land, reroute, or refile.
6. Where possible, ATOMx provides a pre-deconflicted route out of the affected area.
7. Operator/control system accepts, modifies, or executes the response.
8. ATOMx tracks whether the aircraft is complying.
9. Cooperative compliance does not downgrade identity trust.
10. Non-compliance becomes an authorized-user investigation cue.

Direct aircraft or autopilot execution should be treated as an approved integration path, not the default assumption. OEM and aircraft integrations are critical for future automated execution but should not be required for the core connected governance model.

3. Disconnected Mode Flow

Disconnected verification is not the primary operational mode, but the architecture must support it. The full flow — capsule provisioning, RF broadcast over the Remote ID Authentication Message, local authorized verification, time-tampering mitigations, and reconciliation — is documented in Disconnected Operations. The architectural implications for the services in §1 are:

4. API Model

4.1 API design principle

All API responses must be policy-filtered. The API should not have one universal aircraft detail response. It should return the maximum information permitted for the requesting user/system, geography, purpose, and event context.

4.2 Core API domains

• Authorization Packages
• Public Tokens
• Telemetry
• Conformance
• Trust State
• Protected Disclosure
• Security Alerts
• Restrictions and Amendments
• Audit and Evidence
• Offline Capsule Reconciliation
• Field Device Credentialing

4.3 Example response categories

5. Engineering Data Model Sketch

6. Product Requirements

6.1 Core requirements

1. ATOMx shall bind pilot/operator identity, aircraft identity, and approved flight plan or operating area into an authorization package.
2. ATOMx shall use a signed manifest model for the authorization package.
3. ATOMx shall expose an authorization-bound public aircraft token instead of permanent aircraft identity.
4. ATOMx shall keep pilot/operator identity and control-station location out of the public view.
5. ATOMx shall encrypt protected identity fields.
6. ATOMx shall disclose protected fields only through policy-controlled access.
7. ATOMx shall log all protected disclosures.
8. ATOMx shall support three public trust states: Within Authorization, Not Within Authorization, and Not Publicly Verifiable.
9. ATOMx shall clearly distinguish Not Publicly Verifiable from unauthorized.
10. ATOMx shall maintain separate authorization, identity trust, and security alert states.
11. ATOMx shall support connected conformance monitoring.
12. ATOMx shall support API-first integrations into existing operational systems.
13. ATOMx shall provide its own operational airspace awareness interface.
14. ATOMx shall preserve a tamper-evident audit record.
15. ATOMx shall support disconnected verification as an architectural path.

6.2 Disclosure requirements

1. Disclosure decisions shall be based on user, role, organization, geography, purpose, time window, authority, and event context.
2. Disclosure shall be field-level, not all-or-nothing.
3. Pilot/operator identity and control-station location should be disclosed together when the requester has approved need-to-know access.
4. Purpose code selection shall be simple and fast for emergency or field users.
5. Break-glass access shall be logged, marked, scoped, and reviewed.

6.3 Conformance requirements

1. ATOMx shall compare telemetry against the approved operation.
2. ATOMx shall support route, operating area, altitude, time, and mission-volume conformance.
3. ATOMx shall distinguish amended/revoked authorization from identity trust degradation.
4. ATOMx shall track whether aircraft comply with exit, hold, land, reroute, or refile instructions.
5. ATOMx shall provide reason codes to authorized users and systems.

6.4 Telemetry requirements

1. ATOMx shall ingest primary telemetry from operator/control system or aircraft.
2. ATOMx shall support corroborating telemetry and sensor observations.
3. ATOMx shall assign telemetry confidence for authorized users.
4. ATOMx shall detect stale telemetry, mismatched telemetry, duplicate public tokens, possible replay, and possible spoofing.
5. Telemetry confidence shall not change the public state directly, but may change the authorized operational state.

6.5 Offline requirements

1. Offline verification shall use pre-cleared authorization packages or compact offline capsules.
2. Offline reveal shall require person-bound authority credential, managed device credential, and purpose code.
3. Offline reveal shall be geographically scoped by default.
4. Offline devices shall create signed disclosure receipts.
5. Offline events shall reconcile with ATOMx when connectivity returns.
6. Offline verification shall support local comparison of aircraft telemetry against signed approved operation.

7. Open Engineering Decisions

These decisions do not block the product concept but need technical design.

8. Deployment, SLOs, and Operational Concerns

8.1 Deployment Topology

ATOMx services run on managed Kubernetes in the DroneUp shared-platform foundation. Per-service responsibilities (§1) map to discrete deployments with horizontal scaling. Stateless services (Classification Engine, Conformance Engine, Trust State Engine) scale by request volume; stateful services (Audit Ledger, Authorization Package store) scale read replicas with leader-driven writes.

8.2 SLOs and SLIs

Indicative targets — calibrated against early-deployment telemetry:

8.3 Observability

• Metrics: per-service Prometheus-compatible metrics; per-tenant cardinality budgeted to avoid blow-up
• Traces: OpenTelemetry; trace IDs propagated through Authorization Package issuance, telemetry binding, disclosure decisions
• Logs: structured JSON; correlation by package_id, disclosure_event_id, org_id
• Audit ledger: separate from operational logs; tamper-evident; never deleted, only archived
• Customer-visible health: per-tenant status dashboard; SLO compliance reports

8.4 API and Schema Versioning

• API versioning: URL-path versioned (/v1/, /v2/); minimum 12-month deprecation window for breaking changes; partner notification via versioning portal
• Schema versioning: every signed manifest carries package_version (per-package) and a separate schema_version (manifest-format version); verifiers MUST handle older schema_version values for the deprecation window
• Event-stream versioning: schema-registry-backed; consumers subscribe to a specific version range; broadcasts include schema URI

8.5 Multi-Tenancy Isolation

Operator orgs and Authority orgs are isolated at the data layer:

• Per-tenant logical schema; queries filtered by org_id
• Per-tenant signing keys for authority endorsements (HSM partition per authority)
• Per-tenant audit-ledger partition; cross-tenant queries require explicit access grant
• Operator org cannot enumerate other operators; authority org cannot enumerate flights outside its jurisdiction

8.6 Disaster Recovery

• Audit ledger replicated across regions with synchronous primary + async secondary
• Configuration-as-code allows rebuild of services from a known-good state in hours
• HSM keys held in dual-region custody; ceremony-witnessed migration available
• Annual DR exercise validates rebuild time

9. Recommended MVP Boundary

The most logical first implementation should focus on connected operations and API/UI disclosure. Offline should be designed into the model but not made the critical path.

10. Target Architecture Summary

ATOMx should be implemented as a policy-controlled trust broker for low-altitude airspace.

The architecture centers on a signed Authorization Package Manifest that binds aircraft, pilot/operator, approved operation, public token, protected claims, conformance policy, disclosure policy, and audit references.

In connected mode, ATOMx is authoritative for conformance and protected disclosure. It compares telemetry against the approved operation, produces public and authorized trust states, and releases protected fields only after policy approval.

In disconnected mode, approved local verifiers can use pre-cleared packages, scoped credentials, and managed devices to validate permitted details locally, then reconcile disclosure and telemetry records once connectivity returns.

This creates the internal implementation foundation for the customer-facing promise: ATOMx reduces unnecessary public exposure of pilot/operator identity and control-station location while increasing the operational value of the identity signal. It moves the system from public identity broadcast to authorization-bound cooperative trust.

11. Bottom Line for Product and Engineering

Build ATOMx around the authorization package, not around Remote ID.

Remote ID becomes one possible transport or compatibility surface. The product is the trust layer that binds identity, aircraft, approved operation, telemetry, conformance, disclosure, and audit into one operational system.

The near-term implementation should be connected, API-first, policy-controlled, and auditable. The architecture should preserve a path to disconnected verification, stronger aircraft identity, and approved OEM integrations without making those dependencies required for the initial product.

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.