{
 "slug": "mission-authorization-receipt",
 "topic_id": "TOPIC-141",
 "cluster": "Aviation, MRO & Aerospace Airworthiness Identity",
 "tier": "Tier B",
 "title": "BVLOS drone operations: who authorized the flight the remote pilot never saw?",
 "summary": "Beyond-visual-line-of-sight rules enable one-to-many operations. Regulation places responsibility on a remote pilot in command; scaled operations put one human in charge of dozens of simultaneous autonomous missions.",
 "lede": "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.",
 "date": "2024-02-11",
 "category": "Vertical",
 "author_id": "priya-venkatraman",
 "tags": [
  "BVLOS",
  "drone operations",
  "Part 107",
  "remote pilot in command",
  "UAS",
  "autonomy"
 ],
 "image_title": "Mission Authorization Receipt",
 "schema": "Article",
 "key_takeaways": [
  "Regulation assigns responsibility to a person. Fleet software assigns execution to a scheduler. Nothing binds the person to the specific mission envelope that made a flight legal.",
  "The exposure multiplier is missions per RPIC per shift. Most operations have never computed it.",
  "A mission authorization receipt gives the RPIC a signed envelope — geography, altitude band, time window, contingency plan — and bounds the autonomy stack to it."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Start with the analogy, then break it"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "One-to-many operations, one responsible person per flight",
   "caption": "The regulatory model and the operating model diverge, and the record sits with the operating model.",
   "nodes": [
    {
     "label": "Mission scheduled",
     "note": "by a system"
    },
    {
     "label": "Parameters resolved",
     "note": "route, payload, airspace"
    },
    {
     "label": "Remote PIC assigned",
     "note": "one of several dozen",
     "bad": true
    },
    {
     "label": "Flight executes",
     "note": "authorisation = a queue entry",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "What makes a specific flight legal"
  },
  {
   "type": "p",
   "html": "A BVLOS flight is legal because of a combination of things, and most of them are mission-specific rather than operator-specific:"
  },
  {
   "type": "ul",
   "items": [
    "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."
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Compute your exposure multiplier"
  },
  {
   "type": "p",
   "html": "One number frames this: missions per RPIC per shift."
  },
  {
   "type": "table",
   "head": [
    "Missions per RPIC per shift",
    "What supervision can realistically mean",
    "Record adequacy"
   ],
   "rows": [
    [
     "1–3",
     "Direct monitoring of each flight",
     "Roster attribution is adequate"
    ],
    [
     "4–10",
     "Monitoring by exception",
     "Roster attribution is thin"
    ],
    [
     "11–30",
     "Queue management",
     "Roster attribution is not evidence"
    ],
    [
     "Over 30",
     "Fleet operations",
     "The concept of per-flight command needs a different artefact"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "The Mission Authorization Receipt"
  },
  {
   "type": "p",
   "html": "The RPIC signs an envelope, not a flight. The autonomy stack operates under it, and cannot exceed it."
  },
  {
   "type": "code",
   "text": "{\n  \"type\": \"manav-stmt/1\",\n  \"action\": \"mission_authorization\",\n  \"render\": [\n    \"Mission: [id]  Aircraft: [registration / serial]\",\n    \"Area: [geofence reference]  Altitude: [floor]–[ceiling]\",\n    \"Window: [start]–[end]\",\n    \"Airspace authorisation: [reference]\",\n    \"Contingency: [lost link plan reference]\",\n    \"Conditions: [over people: yes/no] [DAA arrangement]\"\n  ],\n  \"rpic\": \"[credential assertion, certificate number]\",\n  \"delegation\": { \"depth\": 0, \"notAfter\": \"[window end]\" }\n}"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Mid-mission revocation"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "A note on rulemaking timing"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "What this does not do"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "What the authorisation should carry"
  },
  {
   "type": "table",
   "caption": "Elements a responsible pilot is accountable for",
   "head": [
    "Element",
    "Why it belongs in the signature"
   ],
   "rows": [
    [
     "Airspace and authorisation reference",
     "The legal basis for the operation"
    ],
    [
     "Route and altitude envelope",
     "What was actually authorised"
    ],
    [
     "Payload and configuration",
     "Changes the risk profile"
    ],
    [
     "Contingency and lost-link plan",
     "The pilot's responsibility if anything goes wrong"
    ],
    [
     "Named remote PIC",
     "The person the rule attaches to"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“One signature per flight does not scale to hundreds.”</strong> 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."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“The system already logs all of this.”</strong> 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."
  }
 ],
 "faq": [
  {
   "q": "Does the RPIC have to sign every flight?",
   "a": "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."
  },
  {
   "q": "What happens if a mission plan changes after authorisation?",
   "a": "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."
  },
  {
   "q": "Does this slow down operations?",
   "a": "Envelope signing happens at shift start or at mission-batch creation, not per flight, so the real-time path is untouched."
  },
  {
   "q": "Is this required by rule?",
   "a": "No. It exceeds current requirements and is proposed on operational and evidentiary grounds."
  },
  {
   "q": "Does every flight need a signature?",
   "a": "Not necessarily. A bounded shift delegation — this mission class, this airspace, these parameters — keeps the chain intact at scale."
  },
  {
   "q": "What should the authorisation cover?",
   "a": "Airspace and authorisation reference, route and altitude envelope, payload, and the contingency plan."
  },
  {
   "q": "Why recompute before launch?",
   "a": "So a parameter changed after the pilot authorised the mission stops the flight rather than flying under a stale authorisation."
  }
 ],
 "sources": [
  {
   "t": "FAA — unmanned aircraft systems rules and resources",
   "u": "https://www.faa.gov/uas"
  },
  {
   "t": "UAS traffic management standards and airspace authorisation frameworks."
  },
  {
   "t": "FAA — regulations and policies",
   "u": "https://www.faa.gov/regulations_policies"
  }
 ],
 "related": [
  {
   "slug": "fleet-command-authorization",
   "title": "Who told 40,000 inverters to curtail?",
   "category": "Vertical"
  },
  {
   "slug": "delegation-depth-policy",
   "title": "Agent-to-agent delegation depth",
   "category": "Developer"
  },
  {
   "slug": "operational-control-receipt",
   "title": "The dispatch release and the MEL deferral",
   "category": "Vertical"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Mission%20Authorization%20Receipt/1200_630/blog.jpg",
 "wordcount": 969,
 "url": "/blog/mission-authorization-receipt.html",
 "reading_time": "4 min read",
 "seo_title": "BVLOS drone operations: who authorized the flight?",
 "meta_description": "BVLOS rules enable one-to-many drone operations. Regulation places responsibility on a remote pilot who may never have seen the specific flight.",
 "hub": {
  "slug": "topics/airworthiness-identity",
  "title": "Aviation and airworthiness identity"
 },
 "answer": "Formally, a remote pilot in command. Operationally, a scheduling system dispatching many flights, where regulation places responsibility on one person per flight and scaled operations put one person over dozens. The authorisation record is a job in a queue.",
 "answer_q": "Who authorises a BVLOS flight the remote pilot never saw?",
 "glossary": [
  {
   "term": "BVLOS",
   "def": "Beyond visual line of sight: operations where the remote pilot cannot see the aircraft, enabling one-to-many operation."
  },
  {
   "term": "Remote PIC",
   "def": "The remote pilot in command, the individual on whom regulatory responsibility for a flight rests."
  },
  {
   "term": "Bounded delegation",
   "def": "A signed grant covering a class of missions within stated parameters and a stated period."
  }
 ],
 "checklist": {
  "title": "Binding mission authorisation",
  "id": "bind",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Decide the unit: flight or shift.",
    "text": "Per-flight for high-consequence operations; a bounded shift delegation otherwise."
   },
   {
    "name": "Render the envelope, not the plan.",
    "text": "Airspace, altitude, payload, contingency — the parameters the pilot is accountable for."
   },
   {
    "name": "Bind and recompute before launch.",
    "text": "A parameter change after authorisation refuses."
   },
   {
    "name": "Keep the receipt with the flight log.",
    "text": "So an investigation is a retrieval."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds an airworthiness or operational signature to the exact record it certifies, on a credential under one individual's sole control, and produces a receipt an auditor or a regulator can verify years later without access to the operator's systems.",
  "href": "../docs.html",
  "label": "See signature binding"
 }
}