BVLOS drone operations: who authorized the flight the remote pilot never saw?

Think of the remote pilot in command the way you think of a captain. One aircraft, one person, one clear line of responsibility. Now imagine that captain responsible for forty aircraft at once, none of which they can see, all of which are flying plans generated by a scheduler.

Part of Aviation and airworthiness identity

Start with the analogy, then break it

A pilot in command is responsible for the aircraft. That works because the responsibility and the control are in the same place: the person accountable is the person flying.

In a scaled drone operation those two things separate. The remote pilot in command is accountable. The flying is done by autonomy executing a mission plan produced by a scheduler against a work queue. The RPIC's role becomes supervisory, and supervision of forty simultaneous flights is a fundamentally different activity from flying one.

That is not a criticism of the model — it is the model that makes drone inspection and delivery economically viable. It does mean the record needs to catch up with it.

What makes a specific flight legal

A BVLOS flight is legal because of a combination of things, and most of them are mission-specific rather than operator-specific:

• The operating area and whether it is over people or moving vehicles.
• The altitude band and any airspace authorisation covering it.
• The aircraft's configuration and airworthiness state.
• The detect-and-avoid arrangement in force for that area.
• The contingency and lost-link plan for that specific route.
• An RPIC who is qualified and available for that flight.

Six conditions, per mission. In a fleet system they live in configuration, airspace data, aircraft state and a roster. None of them is bound together into a single thing a human confirmed.

Compute your exposure multiplier

One number frames this: missions per RPIC per shift.

Operations scaling past the third row without changing their record model are accumulating an exposure that will be discovered by an investigation rather than by an audit.

The Mission Authorization Receipt

The RPIC signs an envelope, not a flight. The autonomy stack operates under it, and cannot exceed it.

{
  "type": "manav-stmt/1",
  "action": "mission_authorization",
  "render": [
    "Mission: [id]  Aircraft: [registration / serial]",
    "Area: [geofence reference]  Altitude: [floor]–[ceiling]",
    "Window: [start]–[end]",
    "Airspace authorisation: [reference]",
    "Contingency: [lost link plan reference]",
    "Conditions: [over people: yes/no] [DAA arrangement]"
  ],
  "rpic": "[credential assertion, certificate number]",
  "delegation": { "depth": 0, "notAfter": "[window end]" }
}

The important property is the bound. The autonomy stack holds a delegation valid only inside that envelope. A mission plan that drifts outside it — because a scheduler recalculated, or a geofence was edited — produces no valid authorisation, and the flight does not launch.

Mid-mission revocation

The second property worth building deliberately. If the RPIC needs to stop a flight — an airspace change, a weather deterioration, a report from the ground — revocation should be a signed act that propagates in well under a second, and should itself be recorded.

This matters because the decision to terminate a flight is exactly as consequential as the decision to authorise it, and today it is a button press attributed to a console.

A note on rulemaking timing

BVLOS rulemaking was still settling at the time of writing, so nothing here should be read as designing to a specific rule text. The design targets the concepts that are stable across every proposal and every international framework: a named responsible person, a defined operating envelope, and airspace authorisation. Those will survive whatever the final rule says.

What this does not do

It does not provide airspace authorisation, detect-and-avoid capability, or airworthiness. It does not make one person capable of supervising forty flights. It records, verifiably, which human authorised which envelope — which is the question an investigation opens with and which no current system answers.

What the authorisation should carry

Objections and honest limits

“One signature per flight does not scale to hundreds.” Then use a bounded delegation: this pilot authorises this mission class, in this airspace, within these parameters, for this shift. The chain still terminates at a person and the throughput survives.

“The system already logs all of this.” It logs it. The question is whether the pilot's accountability is bound to those parameters, so that a change after assignment invalidates the authorisation.

Binding mission authorisation

1. Decide the unit: flight or shift. Per-flight for high-consequence operations; a bounded shift delegation otherwise.
2. Render the envelope, not the plan. Airspace, altitude, payload, contingency — the parameters the pilot is accountable for.
3. Bind and recompute before launch. A parameter change after authorisation refuses.
4. Keep the receipt with the flight log. So an investigation is a retrieval.

Terms used here

BVLOS

Beyond visual line of sight: operations where the remote pilot cannot see the aircraft, enabling one-to-many operation.

Remote PIC

The remote pilot in command, the individual on whom regulatory responsibility for a flight rests.

Bounded delegation

A signed grant covering a class of missions within stated parameters and a stated period.

Frequently asked questions

Does the RPIC have to sign every flight? They sign an envelope, which may cover many flights within a defined area and window. The envelope is the unit of human authorisation; the flights are execution within it.

What happens if a mission plan changes after authorisation? If the change stays inside the envelope, it proceeds. If it exits the envelope, there is no valid authorisation and the flight does not launch until a fresh signature is obtained.

Does this slow down operations? Envelope signing happens at shift start or at mission-batch creation, not per flight, so the real-time path is untouched.

Is this required by rule? No. It exceeds current requirements and is proposed on operational and evidentiary grounds.

Does every flight need a signature? Not necessarily. A bounded shift delegation — this mission class, this airspace, these parameters — keeps the chain intact at scale.

What should the authorisation cover? Airspace and authorisation reference, route and altitude envelope, payload, and the contingency plan.

Why recompute before launch? So a parameter changed after the pilot authorised the mission stops the flight rather than flying under a stale authorisation.

Sources and further reading

• FAA — unmanned aircraft systems rules and resources
• UAS traffic management standards and airspace authorisation frameworks.
• FAA — regulations and policies