Every decision a delivery drone makes, on the record.

Live simulation

A flight that writes its own record.

Hub 4 to drop point D-17, 5.1 km. Each decision becomes a record that carries the hash of the one before it. Every few records the aircraft seals the newest batch into a Merkle root and anchors it to the shared ledger. Select any record and edit its explanation to see what verification catches.

The framework

Six layers between a sensor reading and a verifiable record.

Proof of Flight wraps an existing autonomy stack. The AI still flies the aircraft. The framework sets the limits it flies within and records why it did what it did.

1. 01

   Aware

   Real-time flight awareness

   Fuses ADS-B In, Remote ID broadcasts, UTM flight intents, geofences, weather and onboard vision into one picture of the airspace around the aircraft, refreshed several times a second.

   Rule

   Every decision cites the inputs it saw.

   Writes

   inputs digest · sources · sensor health
2. 02

   Decide

   The AI pilot proposes

   Navigation and perception models score candidate actions (continue, reroute, climb, descend, hold, divert, land, lower) and propose the best one.

   Rule

   Every action names the exact model build that chose it.

   Writes

   model build hash · ranked options · confidence
3. 03

   Guard

   Deterministic rules dispose

   A safety envelope written as plain rules checks each proposal against geofences, separation minima, energy reserve and wind limits. It can veto the model. The model can't override it.

   Rule

   Rules outrank the model, and every veto is recorded.

   Writes

   each check · threshold · pass, fail or escalate
4. 04

   Explain

   Reasons a person can read

   Each decision carries reason codes from a published catalogue and a plain-language sentence built from them. Below a confidence threshold, the aircraft holds and hands the decision to a remote pilot.

   Rule

   No action without a reason code. No silent handoffs.

   Writes

   reason codes · explanation · human status
5. 05

   Anchor

   Tamper-evident by construction

   The aircraft hashes each record together with the hash of the one before it and signs it. Every few seconds it sends the Merkle root of the newest batch to a ledger run jointly by the operator, regulator, insurer and UAS service supplier.

   Rule

   Hashes go on the ledger. Raw data and personal data stay off it.

   Writes

   prev hash · record hash · signature · anchor
6. 06

   Verify

   Checkable without trusting the operator

   Anyone with access can replay a flight, recompute every hash and compare the roots with the ledger. A customer gets one record and a short Merkle proof instead of the whole flight.

   Rule

   Verification needs the data and the ledger, not the operator's word.

   Writes

   verification events: who checked what, and when

Designed to sit alongside Remote ID (14 CFR Part 89), UTM interoperability (ASTM F3548) and the FAA's pending Part 108 BVLOS rule. It adds a record. It doesn't replace any of them.

Ledger design

Hashes on the chain. Flight data stays with its owner.

A flight record is only useful if it can be shared without leaking a customer's address or an operator's model. The ledger holds commitments. The data behind them stays encrypted with the operator and is disclosed per request.

Who checks what

One flight record, five readers.

Each reader gets what their role needs and checks it against the same anchored roots.

Open questions

What the concept doesn't solve yet.