Trust Ladder and the Identity Matrix

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

1. Why a Ladder, Not a Score

ATOMx does not produce a probabilistic trust score. It resolves a deterministic level on an ordered ladder. Each level is reached by satisfying a fixed combination of identity inputs across three independent axes; the same inputs always produce the same level.

The ladder serves two purposes. The first is operational — an authority watch-floor user must read the airspace at a glance, and a five-color signal does that. The second is strategic — the existence of intermediate levels (orange, yellow) gives partially-cooperative operators a visible upgrade path off legacy systems. Removing them would collapse the migration story.

“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

2. The Three Identity Axes

Three independent ordinals feed the ladder. Each axis is evaluated independently; the level is resolved from the combination.

Each axis has its own provenance and its own failure modes. They are addressed in dedicated pages:

• Pilot identity provenance and non-repudiation: Pilot Identity
• Aircraft identity provenance and hardware anchoring: Aircraft Hardware Identity
• Flight authorization binding: Authorization Package

3. The Five Trust Levels

Some internal artifacts use purple for L5 and green for L4. The current product convention (locked Apr 8, 2026) is blue = software-verified, green = hardware-verified. See Origins and Decisions §3.6.

4. How a Level Resolves

The level is not the average or minimum of the three axes. Each level requires a specific combination:

Color is determined by the level — never by the axis values. L4 is always 🔵 blue; L5 is always 🟢 green. If you see them swapped in the matrix, that is a bug.

4.1 The Flight × Pilot × Drone Matrix

Footnotes

* HW-anchored drone with Weakly-Verified (FTN-only) pilot caps at L4 — L5 requires a Strongly-Verified pilot for non-repudiation. See Pilot Identity §4.

† Drone identity caps the level. L4 requires software-anchored drone identity; without it, even a verified flight authorization and a strongly-verified pilot resolve to L3.

‡ Pilot identity caps the level. L4 requires verified pilot identity; FTN-only is Weakly Verified, which holds the level at L3 until paired with login.gov-grade proofing.

— Empty cells indicate combinations that are not realistic in practice — e.g., a drone with SW or HW cryptographic identity broadcasting in flight without any filed flight intent. Such cases are treated as anomalies if observed.

5. What Degrades a Level

A level is not permanent for the duration of a flight. Inputs that once satisfied a tier may be revoked, fail validation mid-flight, or become time-degraded. The full set of degradation triggers is in Threat Model; the headline cases:

Accessibility note. The five-color signal is paired with the L1–L5 numeric label and the named state (“Detected”, “Declared”, etc.) in every operator surface, so colorblind users do not depend on hue alone.

6. Conformance Is an Independent Overlay

Trust level and conformance are separate state machines. A green aircraft that briefly clips its approved-operation boundary stays green and pulses a red conformance overlay. The trust level does not flicker. This is the signal-to-noise property described in Trust Model §4.

Conformance only applies at L3 and above. L1 and L2 cannot be “non-conformant” because they have no operational intent to deviate from. See Origins and Decisions §3.9.

7. Demo Scenarios

The five canonical verification scenarios — locked Apr 3, 2026 and demonstrated Apr 14 — exercise the full ladder. They are documented in Origins and Decisions §5.

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.