0001 - MVP Demonstration: Flight Authorization + Verifiable Identity

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

CONFIDENTIAL | DroneUp | March 2026

1. Purpose

Build a demonstration system that shows how airspace trust can be determined in real time using:

• Flight Authorization
• Aircraft Identity
• Conformance

2. Demo Goals

The demo must convincingly show:

1. Operators can submit flight authorization requests (LAANC-like experience)
2. Multiple jurisdictions can approve a flight
3. Aircraft appear in a live airspace view
4. Each aircraft is deterministically classified
5. External awareness (DiSCVR-like) improves visibility but not authorization
6. Non-conformance is detected and flagged in real time
7. Field personnel (e.g., law enforcement) can consume classification data in real time without flight management privileges
8. The resulting data is suitable for integration into external systems (no live integration required)

3. Key Principles

4. System Overview

The MVP consists of five primary components:

5. Functional Components

A. Operator Submission

Use existing LAANC-style interface.

Capabilities:

• Submit flight request:
  • Area (polygon)
  • Time window
  • Aircraft selection

B. Authorization Management UI

Simple interface for jurisdictional approval.

Features:

• View flight request
• Map overlay of flight area
• Display 2-3 overlapping jurisdiction boundaries
• Approve or Deny actions

Constraints:

• No partial approvals
• No complex rule engine
• No automation required

C. Field Awareness View

Read-only interface for law enforcement or public safety personnel operating in the field. This role demonstrates that the classification data produced by the system is directly actionable by downstream consumers who need to determine whether a drone is authorized — without granting any flight management capabilities.

Persona: A law enforcement officer who encounters a drone in the field and needs to quickly determine its authorization status.

Features:

• Live airspace map (same visualization as the primary map)
• Aircraft classification status (color-coded)
• Aircraft Detail Panel (read-only: authorization status, identity type, conformance)
• Filter or focus by geographic area (center on current location)

Constraints:

• Strictly read-only — no ability to approve, deny, or modify flights
• No access to operator identity or pilot PII
• No ability to create or manage flight requests
• Authenticated separately from operator and jurisdiction roles

D. Authorization Object

When a flight is approved, generate a structured object containing:

• Flight area
• Time window
• Aircraft ID
• Pilot ID (implicit)
• Aircraft identity type:
  • Software-anchored
  • Hardware-anchored
• Simulated digital signature

E. Simulation Engine

Simulates real-time airspace activity.

Aircraft Types:

1. Authorized (from system)
2. Externally observed (DiSCVR-like simulation)
3. Unknown (no correlation)

Each Aircraft Includes:

• Position (continuously updated)
• Aircraft identifier (optional)
• Identity type (none / software / hardware)
• Optional link to authorization

F. External Awareness (Simulated)

Represents systems like DiSCVR.

Capabilities:

• Provide aircraft correlation independent of authorization
• Elevate aircraft from “Unknown” to “Limited Information”

Constraints:

• Fully simulated
• No real integration required

G. Classification Engine (Core Logic)

Deterministic evaluation based on:

• Authorization status
• External correlation
• Aircraft identity type

Classification Output (exactly one per aircraft):

• Unknown
• Limited Information
• Known
• Verified

Conformance State (independent):

• Conformant
• Non-Conformant

    flowchart TD
    A[Aircraft Detected] --> B{Authorized?}
    B -->|No| C{External Match?}
    C -->|No| D["<b>Unknown</b><br/>(Gray)"]
    C -->|Yes| E["<b>Limited Information</b><br/>(Yellow)"]
    B -->|Yes| F{Identity Type?}
    F -->|Software| G["<b>Known</b><br/>(Blue)"]
    F -->|Hardware| H["<b>Verified</b><br/>(Green)"]
    B -->|Yes| I{Within Bounds?}
    I -->|No| J["<b>Non-Conformant</b><br/>(Red Overlay)"]
  

H. Live Airspace Map (Primary UI)

Central visualization of all aircraft.

Features:

• Real-time aircraft movement (simulated)
• Color-coded classification
• Non-conformant indicator (red overlay or highlight)

I. Aircraft Detail Panel

On click, display:

• Authorization: Yes / No
• Aircraft Identity: None / Software / Hardware
• External Correlation: Yes / No
• Conformance: Conformant / Non-Conformant
• Classification (derived)

6. Demo Flow

The system must support the following narrative:

7. Non-Functional Requirements

Performance

• Smooth real-time map updates (simulated acceptable)
• Low latency classification updates

Simplicity

• No unnecessary complexity
• Minimal UI surface area

Reliability (for Demo)

• Deterministic behavior (no randomness in outcomes)
• Pre-scriptable scenarios preferred

8. Out of Scope

9. Key Message to Convey

10. Success Criteria

The demo is successful if:

• Viewers understand the difference between Unknown, Limited Information, Known, and Verified
• The role of authorization is clear and central
• Identity strength is clearly differentiated
• Non-conformance is immediately visible and intuitive
• The system feels credible, not theoretical
• A field user (law enforcement) can determine drone authorization status without any flight management access