0002 - Classification Engine: Flight Trust Levels

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

CONFIDENTIAL | DroneUp | April 2026

1. Purpose

Define the classification categories, resolution rules, and UI representation for aircraft trust levels in the live airspace view (Common Operating Picture).

The classification engine takes three independent data inputs – pilot identity, aircraft (UA) identity, and flight intent – and produces a single, deterministic trust level for each aircraft. The output is a color-coded indicator suitable for real-time display and downstream system consumption.

Scope

• Exact classification rules and the data inputs that feed each level
• A config-ready axis dictionary that maps directly to software implementation
• UI representation: colors, overlay states, badges
• Edge cases: partial data, degraded signals, conflicting inputs
• How classification changes in real time as conditions evolve
• Demo narrative arc for stakeholder presentations

Out of Scope

• Scoring, probabilities, or analytical models – all outputs are rule-based and explainable
• Real FAA DiSCVR integration (simulated for demo)
• Cryptographic implementation details (see crypto identity spike)
• Non-conformance detection internals (reuses existing collision service logic per Ihor)

2. Identity Axes

The classification engine evaluates three independent axes. Each axis has an ordered set of states from lowest to highest trust. These definitions are designed to be used directly as a configuration file.

2.1 Pilot Identity

2.2 UA (Drone) Identity

2.3 Flight Intent

2.4 Configuration Reference

The axis definitions above map directly to this YAML structure, intended as the source of truth for the classification engine implementation:

# classification-config.yaml
# Three independent identity axes with ordered states.
# Ordinals define the trust progression within each axis.

axes:
  pilot:
    unknown:       0
    declared:      1
    verified:      2

  ua:
    unknown:       0
    declared_rid:  1
    software:      2
    hardware:      3

  flight:
    absent:        0
    oi_only:       1
    authorized:    2

3. Trust Levels

Five trust levels, ordered from lowest to highest confidence. Each level defines the minimum axis requirements that must ALL be satisfied for an aircraft to qualify.

3.1 Level Definitions

3.2 Level Thresholds (Configuration Reference)

# Extends classification-config.yaml
# Each level defines minimum ordinal requirements per axis.
# Resolution: iterate L5 -> L1; first level where ALL axes meet
# or exceed the minimum is the assigned trust level.

levels:
  - id: L1_unidentified
    name: Unidentified
    color: red
    min_pilot: 0        # unknown
    min_ua: 0            # unknown
    min_flight: 0        # absent

  - id: L2_declared
    name: Declared
    color: orange
    min_pilot: 1         # declared
    min_ua: 1            # declared_rid
    min_flight: 0        # absent

  - id: L3_correlated
    name: Correlated
    color: yellow
    min_pilot: 1         # declared
    min_ua: 1            # declared_rid
    min_flight: 1        # oi_only

  - id: L4_authorized
    name: Authorized
    color: green
    min_pilot: 2         # verified
    min_ua: 2            # software
    min_flight: 2        # authorized

  - id: L5_verified
    name: Verified
    color: purple
    min_pilot: 2         # verified
    min_ua: 3            # hardware
    min_flight: 2        # authorized

3.3 Resolution Algorithm

The trust level for an aircraft is determined by a single rule:

Iterate from L5 down to L1. The first level where the aircraft’s pilot, UA, and flight intent values ALL meet or exceed the level’s minimum requirements is the assigned trust level.

This algorithm is:

• Deterministic – same inputs always produce the same output, no randomness or weighting
• Self-consistent – monotonically increasing thresholds prevent contradictions
• Complete – every possible axis combination resolves to exactly one level (L1 is the catch-all)
• Extensible – new axis states or levels can be added by inserting ordinals and threshold rows

3.4 Combination Verification

Key combinations verified against the resolution algorithm:

4. Non-Conformance Overlay

Non-conformance is an independent, transient state – not a trust level. It represents an aircraft that has deviated from its filed intent or authorized parameters. Because deviations can be momentary (e.g., briefly clipping the edge of an authorized area due to wind), non-conformance is modeled as a recoverable overlay rather than a change to the trust level.

4.1 Applicability

4.2 Trigger Conditions

• Aircraft position outside the authorized geographic area
• Aircraft altitude outside the authorized altitude band
• Aircraft operating outside the authorized time window
• Flight authorization rescinded by a jurisdiction

4.3 State Transitions and Grace Period

Non-conformance follows a three-state lifecycle:

Conformant ──[deviation detected]──> Non-Conformant ──[back in bounds]──> Grace Period ──[grace expires]──> Conformant
                                          │                                     │
                                          │                              [deviation again]
                                          │                                     │
                                          <─────────────────────────────────────┘

The grace period prevents visual flickering when an aircraft is near the boundary of its authorized area. The trust level never changes during any of these transitions – it remains at whatever the threshold algorithm assigned.

4.4 Visual Treatment

• The underlying trust level color remains visible (operators need to know who is non-conformant – a green aircraft out of bounds is a very different situation than a red one)
• A pulsing/flashing animation is applied to the aircraft indicator
• A red border or ring surrounds the color dot
• The aircraft detail panel displays the conformance state explicitly
• During the grace period, the overlay persists but may use a reduced animation (e.g., solid red border without pulsing) to indicate “recently non-conformant, recovering”

4.5 Configuration Reference

# Non-conformance is independent of trust level.
# Only applicable when flight intent >= oi_only.
non_conformance:
  applicable_min_flight: 1          # oi_only or higher
  grace_period_seconds: 10          # configurable; time before clearing overlay
  visual_active: pulsing_red_border
  visual_grace: solid_red_border    # reduced animation during grace period
  detail_label: "Non-Conformant"

5. Edge Cases and Future Considerations

5.1 Partial Data / In-Transit States

5.2 Signal Degradation

5.3 Future Extensions

• oi_planned state: A filed intent where timing has not been adhered to. Can be inserted at flight ordinal 1 without restructuring.
• External match correlation: A future axis or state that captures matches from external systems (LAANC/DroneZone) not processed through the platform.
• Multi-source identity: Cases where identity is confirmed by multiple independent sources, potentially warranting a confidence modifier.

6. UI Representation

6.1 Color Reference

6.2 Map Indicator

Each aircraft on the COP map is rendered as a colored dot or icon:

• Dot color corresponds to trust level
• Non-conformant aircraft: pulsing animation with red border ring
• On hover or click: trust level name, conformance state, and the three axis values are shown in the aircraft detail panel

7. Demo Presentation and Comparison

For the demo script, presentation narrative, talk-track guidance, and current-state-vs-ATOMx comparison, see PRD 0003 - Demo Script: Partner.

8. Relationship to PRD 0001

This document provides the detailed classification model for the MVP demonstration system defined in PRD 0001.

What this document supersedes:

• PRD 0001 Section G (Classification Engine) – replaced by the threshold-based model in Section 3 above
• PRD 0001 color coding reference – replaced by Section 6 above

What remains in PRD 0001:

• All other system components (Operator Submission, Authorization Management, Field Awareness View, Simulation Engine, External Awareness)
• Demo flow (high-level) – see PRD 0003 for the detailed presentation script
• Non-functional requirements and success criteria

Key Changes from PRD 0001