How Autonomous Is a Drone? A Six-Part Test for Automation and Authority

What the primary record establishes

The strongest sources answer different questions. Keeping their roles separate prevents a research definition from being mistaken for a rule or a regulatory responsibility from being mistaken for a complete autonomy model.

FAA guidance: In the US Part 107 context, section 5.2.3 of FAA Advisory Circular 107-2A describes an automated operation in which a remote pilot enters a flight plan and onboard components make flight-control inputs. The guidance says the remote pilot in command must retain the ability to change routing or altitude, command an immediate landing, or otherwise direct the aircraft through manual or automated commands. The advisory circular is nonbinding guidance, not a rule or legal interpretation.

Current regulation: 14 CFR 107.19 separately makes the remote pilot in command directly responsible for the operation, requires compliance with applicable regulations, and requires the ability to direct the small unmanned aircraft. Those are current Part 107 responsibilities. They do not define every possible autonomous system or settle how another jurisdiction, approval basis, or future operating concept allocates authority.

Attributed research position: A 2017 NASA conference paper, Autonomy and Automation, prepared for an ICAO Remotely Piloted Aircraft Systems Panel meeting, proposed describing automation by the particular system, task, context, and relevant dimensions. It also proposed avoiding the term autonomy for automated functions on remotely piloted aircraft. That is a useful task-specific framing, but this article does not represent the proposal as an adopted ICAO definition.

Historical government framework: NIST's September 2004 Autonomy Levels for Unmanned Systems terminology Version 1.1 treated autonomy as multidimensional. Its framework considered mission complexity, environmental difficulty, and human interaction, and noted that autonomy designations could apply to tasks below the mission level. NIST's current ALFUS program page lists a later Version 2.0 and warns that the page is no longer updated and may be out of date. The durable lesson is context, not a current universal level number.

These records support three conclusions. Automation can perform substantial flight-control and mission-sequencing work. Human responsibility can remain in place even when control inputs originate onboard. Autonomy should be described at the level of a specific decision and context. None of the records supports calling an entire UAS autonomous because it follows waypoints, returns after a link interruption, or includes software marketed as AI.

Use the function as the unit of analysis

An aircraft-level label compresses too many different functions. A typical system can close stabilization loops, estimate state, follow guidance targets, sequence payload actions, detect hazards, recommend a new plan, and execute a contingency. Each function can have a different source of authority and a different degree of adaptation.

The practical unit is:

named function + operating context + delegated decision + transition rule

Consider route behavior. Holding a commanded course is automated control. Following a preloaded waypoint list is automated execution. Presenting three alternate routes for a person to select is decision support followed by automation. Selecting one of those routes from current observations can be a bounded autonomous decision function if the selection, constraints, authority, and transition behavior are explicit. None of those descriptions alone classifies the rest of the aircraft.

This function-level view also separates flight control from mission authority. A planner may receive authority to avoid an obstacle while the operator retains authority over the destination and mission continuation. A payload scheduler may choose a trigger time without receiving authority to change the flight path. Different decisions can share software and hardware while remaining distinct in the authority map.

The decision-authority and transition test

The six-part test below is Unmanned Innovation editorial analysis synthesized from the cited regulator and research records. It is designed to expose missing requirements and evidence, not to award an autonomy level.

1. Name the exact decision

State the choice as a verb with an object and a condition. "Fly autonomously" is not testable. "Select a route around a detected obstacle while preserving the operator-approved destination" identifies a decision. So does "choose one of three approved landing areas after the primary area becomes unavailable."

Then ask whether a choice exists. A fixed response to a fixed trigger is still automation, even when it occurs without a new human command. A preprogrammed return route, timed camera trigger, altitude hold, or deterministic lost-link sequence can be sophisticated and safety-relevant without exercising delegated choice among alternatives.

2. Enumerate actions and constraints

List what the function may select, what it must reject, and what it cannot change. Relevant constraints can include a geographic boundary, destination, energy reserve, speed or altitude limit, required separation, sensor-confidence threshold, time limit, or operator prohibition. The list must also state how conflicts among constraints are resolved.

Constraints do not prove good decisions by themselves. A geofence can prevent one class of excursion while leaving route obstruction, energy, navigation integrity, or traffic unresolved. A reviewer needs to know which constraints are enforced, which are advisory, which have priority, and what happens when no permitted action remains.

3. Identify the authority holder

For each decision, identify who or what may propose, approve, select, execute, pause, override, and terminate. "Human supervised" is incomplete because those verbs can be distributed differently.

The authority statement must cover the current operation, not just the design intent. Under Part 107, the cited FAA rule governs remote-PIC responsibility and the required ability to direct the aircraft; the advisory circular illustrates the FAA's automated-operation guidance. A technical allocation cannot replace that regulatory allocation.

4. Specify every material transition

A mode label describes a state. A transition contract describes how the system enters and leaves it. For each transition, record:

• the initiating event and the component or person that detects it;
• the outgoing and incoming authority holder;
• the information presented to the receiving party;
• the allowed response time and how that budget was derived;
• the aircraft behavior while acknowledgement or action is pending;
• the commands that remain available;
• the completion acknowledgement and resulting mode; and
• the response when the transition itself does not complete.

This is where a nominally human-authorized design can fail in practice. A person cannot meaningfully take authority if the alert is ambiguous, the system state is stale, the command path is unavailable, or the remaining time is shorter than detection, comprehension, decision, and command execution. The UAS data-link role map explains why command, state telemetry, payload data, and video must be evaluated as separate information flows even when they share a radio.

5. Define degraded behavior

Name every prerequisite the function relies on, including state estimates, sensor coverage, time synchronization, maps or constraints, command and state paths, compute resources, and energy. For each prerequisite, state how loss or degradation is detected, how confidence changes, and which decisions remain permitted.

The next action can be a restricted mode, a fixed contingency, a request for human approval, transfer to another function, or termination. The correct choice is operation- and approval-specific, so this framework does not prescribe a default. It requires the transition to be visible and testable.

Return-to-home illustrates the distinction. A fixed return command can be an automated contingency. If a function evaluates several landing or routing options using current state, that selection may exercise bounded decision authority. Neither label proves that the route, home point, navigation source, energy margin, communications behavior, or surrounding hazards make the outcome acceptable.

6. Match evidence to the claim

Evidence should cover the decision and every consequential transition, not just successful nominal execution. At minimum, the claim-to-evidence map should distinguish:

Test volume alone is not the claim. The record should connect requirements, analysis, scenarios, configurations, results, unresolved anomalies, runtime monitoring, and operational limits. A demonstration of one route or one fault injection cannot establish coverage of an unspecified decision space.

Human authority must be operationally usable

Human-in-the-loop, on-the-loop, and out-of-the-loop labels can describe broad interaction patterns, but they do not specify who decides each action or how a handoff works. The 2017 NASA paper discussed these terms while arguing for task- and context-specific descriptions. The more useful review asks what a particular person can know and do at the moment authority changes.

A 2018 NASA contractor report identified challenges created by adaptive or nondeterministic behavior, possible divergence between the system's state awareness and the human's, and dynamic transfer of authority. It also noted that responses must occur on a timescale appropriate to the system and environment. These are attributed research findings, not a rule for small UAS.

A valid handoff claim therefore needs evidence for the whole human-machine path. That includes detection, alert salience, mode and authority indication, the information needed to form an accurate picture, decision time, command availability, command acknowledgement, and the system's behavior during the gap. Merely displaying an override control establishes interface presence, not effective supervisory control.

NASA's 2025 technical memorandum on human-machine teaming in aviation frames novel role allocations as a whole-team research problem. Its abstract calls for evidence about holistic team performance, human resilience to unforeseen hazards, assurance of enabling components, and clear, timely, accurate communication. Editorial inference: a system claim that credits a human as a safety mitigation should include the human, interface, communication path, and time budget inside the assurance boundary.

Degraded modes are transitions, not feature names

"Fail-safe," "lost-link protection," and "graceful degradation" are conclusions that require a defined hazard and evidence. They are not properties established by naming a mode.

Use a transition record for each required input:

These examples are architecture questions, not flight procedures. Their values and acceptable responses must come from the actual system, operation, hazard analysis, manufacturer information, and applicable approval basis.

The transition also needs a destination. "Autonomy disengaged" says what stopped but not what controls the aircraft next. A defensible record names the receiving function or person, the interim aircraft behavior, available state information, and what happens if the receiver cannot accept authority.

Assurance follows the authority boundary

An automated sequence with fixed inputs and outputs can often be reviewed against a bounded set of states. A function that selects new actions from live observations expands the relevant state and decision space. A function that adapts its policy or contains nondeterministic components can raise further verification and validation questions. That does not make adaptation unsafe by definition. It means the evidence burden must match the behavior actually claimed.

The 2018 contractor report treats increasingly autonomous systems as a multidimensional challenge affecting safety-assurance methods, architecture, and verification and validation. It does not supply a certification shortcut. For this editorial test, a credible evidence package answers four separate questions:

1. Specification: Are the delegated choices, constraints, transitions, and prohibited states explicit?
2. Implementation: Is there evidence that the function enforces that specification in the identified configuration?
3. Integration: Do sensors, estimators, communications, interfaces, and flight controls preserve the assumptions the decision function needs?
4. Operation: Are the context, human roles, monitoring, maintenance, and approval consistent with the tested boundary?

Evidence for one layer cannot silently answer another. A planner simulation does not establish sensor validity. A successful flight does not prove all boundary transitions. A technical capability does not grant regulatory authority. The related explainer on Remote ID, detect-and-avoid, and UTM applies the same discipline to functions that are often grouped together even though they solve different problems.

Test common autonomy claims

The following outcomes are editorial classifications under this article's framework, not universal definitions.

"It flies a waypoint mission without stick input." The supported conclusion is automated mission execution. Ask who selected the route, whether the system can choose among alternatives, and what decisions remain after conditions change.

"It has AI obstacle avoidance." The label does not identify the authority boundary. Determine whether the function only issues a stop, recommends an alternate path, or selects and executes one. Then identify observations, constraints, confidence limits, and transitions.

"A human is always on the loop." Presence is not the same as usable authority. Identify the exact decisions the person can change, the state they receive, communication dependencies, response window, and evidence for the handoff.

"It safely returns after losing the link." A fixed lost-link sequence is automation. Safety remains conditional on detection, configuration, route, navigation integrity, energy, hazards, and the operation's rules and approvals.

"It is autonomy level 4." A number without the named framework, task, environment, human interaction, configuration, and evidence is not portable. The historical NIST work itself used multiple dimensions. Translate the number back into function-level claims before comparing systems.

Write a capability statement that can be tested

Replace the broad label with this template:

Within [context and validated inputs], [function] may select [named actions] to achieve [human-approved objective], subject to [constraints and prohibited states]. [person or function] retains authority over [decisions] and can intervene through [information and command path]. Loss or degradation of [prerequisites] triggers [transition and interim state]. The claim is supported by [requirements, analysis, scenarios, tests, monitoring, and limits].

For example, a defensible description might say that a route planner may select and revise a path to an operator-approved destination inside a defined area when specified position and obstacle inputs are valid. It might reserve destination change and mission termination to the remote pilot, identify the command and state paths, and define a fixed contingency if input confidence falls below a documented boundary. That description is hypothetical. It shows the needed fields without claiming that any product satisfies them.

Before accepting the statement, ask:

• Is the exact decision smaller than the whole mission label?
• Are all options, constraints, priorities, and prohibited states named?
• Can the system detect when required information is no longer valid?
• Is the authority holder known in nominal, transition, and degraded states?
• Can a human intervention credited by the claim occur with adequate state, command access, and time?
• Does every handoff have an acknowledgement, interim behavior, and failed transition response?
• Does the evidence cover boundaries and off-nominal cases as well as nominal demonstrations?
• Are technical capability, operating approval, and pilot responsibility kept separate?

Automation can reduce workload and improve repeatability. Bounded autonomous functions can add useful adaptability. Neither term, by itself, proves safe integration, regulatory approval, or acceptable operational risk. The defensible claim is the smallest one that states the decision, its authority boundary, every material transition, and the evidence that remains valid when the system's assumptions stop being true.