Part 2 of a series on aviation safety, technology, and autonomy. Part 1 covered the history of aviation safety.

The most common question I get about aviation autonomy is some version of: "What about autopilot? Doesn't it already do everything?"

It doesn't, despite the clearly very effective naming. But it's a completely reasonable question, because aviation hasn't given anyone a vocabulary for what autopilot is, what it isn't, and what comes next.

The automotive world solved part of this naming problem in 2014. When the automotive industry adopted the J3016 Society of Automotive Engineers (SAE) levels, it forced a discussion and eventual clarification of the autonomy definitions for cars. It gave the industry a common vocabulary, separated driver assistance from true self-driving, and moved the regulatory and technical conversation forward.

Aviation Needs Its Own Levels

Aviation never got the same treatment, so people default to automotive assumptions without accounting for aviation's differences. Aviation operates under a distinct set of regulatory, certification, operational, and other technical constraints, many of which are significantly more complex than those in the automotive industry.

One note before we go further: the levels I'll lay out later in this piece borrow SAE's numbering, not its definitions. A car's Level 2 is actively steering, but while an aviation autopilot has been flying aircraft for over a century, it would still be considered Level 1. Control automation is mostly a solved problem in aviation; the open frontier is cognition. Cars needed levels for the hands. Aviation needs them for the head.

Automation vs. Autonomy

Some debate exists about the distinction between these two terms, but the consensus is that automation follows strict rules, while autonomy handles reasoning and probability. Automation, for example, is a microwave; you open the door, and the light goes on. You close the door, and the light goes off. You enter a cook time, push start, and the microwave runs for that exact amount of time. The machine makes no decisions or decision support; if you enter the time incorrectly, it will burn your popcorn. It lacks contextual understanding of your actions or intent. You set an action, and that action is completed.

The advantage of automation is that it can often perform routine tasks better than a human (a calculator, holding a heading on an autopilot, an elevator). Still, it fails to handle the complexity and unpredictability of the real world. A human elevator operator may be able to operate the elevator safely even if not all positioning sensors are functioning, but an automated elevator likely cannot.

Autonomy incorporates factors such as probability and reasoning through contextual inputs to handle complexity and incorporate judgment. In aviation, the mental framework for sound systematic thinking is known as Aeronautical Decision Making (ADM). When I discuss autonomy, I'm imagining a world where technology can provide reliable ADM.

In the present day, reasoning, ADM, and probability in aircraft are exclusively handled by human aircrew; outside of aviation, they are handled through technologies such as artificial intelligence, machine learning, and deep learning, not just decision trees and checklists. A decision tree is prohibitively difficult to write for your day tomorrow or your drive to work. What if the road is closed? What if it is flooded? What if you get a flat tire? Each of these events is unplanned and requires additional context to make the correct decision. The real world is complex and sometimes cruel to prior assumptions.

Aviation, in particular, is a highly dynamic environment where pilots are constantly weighing incomplete information, changing conditions, aircraft state, mission priorities, and the actions of others in the system. A decision tree cannot accomplish that kind of processing. It requires systems that can incorporate context, reason under uncertainty, and support or make decisions in ways that traditional automation cannot. For now, humans monitor the simple systems and handle all of the complexity themselves; ATC audio, for example, goes to the pilots and nowhere else.

Decision Tempo: Seconds vs. Milliseconds

Another key difference between automotive and aviation autonomy is the decision tempo in each environment. In aviation, except for takeoff and landing, most events occur over tens of seconds or longer. Most situations won't require an immediate response; contrast that with your time in a car, especially in a city or at high speeds on a highway.

This difference creates a totally different environment for how autonomy can be useful. In a car, human driver decision support is complicated by bringing the driver back to the situation and giving them enough information to act on a relevant timeline. If you're driving at 70 MPH on the interstate and a car swerves into your lane, you need to act immediately. That short window between event and required action is why L2/L3 systems have been difficult in automotive, where humans are expected to actively monitor the situation to manage this tight timeline. In aviation, longer windows, combined with the domain's other complexities, create a better environment for L2/L3 autonomy to be a much more beneficial technology for aviators.

So Where Do Today's Systems Sit?

Back to autopilot. Autopilot, autothrottle, Garmin's Autoland, Boeing MCAS, and many other similar systems all fall on the automation side of the line: fully traceable software rules, minimal complexity, and little to no concept of 'correctness'. That's by design, and it is the only way to obtain FAA approvals under the current software regulatory frameworks (DAL/DO-178). Handling complexity is what the crew is for (or, in the case of Autoland, emergency use only, with the expectation that everyone else gets out of the way). MCAS, the Boeing 737 MAX flight-control system implicated in two fatal crashes, is the sharpest illustration of that boundary: fed erroneous sensor data, the rule-following system repeatedly commanded the aircraft nose-down, with no contextual understanding that anything was wrong.

Still, a level-of-autonomy framework for aviation would be useful. The key question is:

How much of the pilot's role has shifted from the human to the machine?

That is the primary axis. Here is how I would define the levels.

Level 0: Manual Flight

No meaningful pilot automation. Purely manual flying.

This is the baseline. The human flies the aircraft and manages the mission. There may be trim, basic warnings, or narrow aids, but no real automation of the pilot's job. In professional flying, this is almost exclusively used in training to prove pilots can still do it if needed. On a recent airline flight, the autopilot failed, and the crew declared an emergency and returned to the departure airport.

Level 1: Standard Automation (Pilot In-the-Loop)

Level 1 is the modern industry standard.

This includes three-axis autopilot, autothrottles, FADEC (engine control), flight management systems, glass cockpit avionics, and similar systems. These tools are often highly capable and highly reliable. Their focus is workload reduction, improving precision, and automating important parts of the flight.

However, they remain on the automation side of the line we drew earlier; strictly rule-based. They execute predefined logic well, but they do not reason through open-ended operational complexity. They are closer to having a microwave than having an additional crewmate. You choose the mode, provide the inputs, and supervise the result.

That is not a criticism. Level 1 automation is enormously valuable. But it is still fundamentally automation, not autonomy.

Level 2: Open-Loop Pilot Assistant (Pilot In-the-Loop)

Level 2 is where reasoning enters the system, and with it, the shift from automation to autonomy.

An open-loop pilot assistant can observe aircraft data, pull in additional sensors and contextual data, process locally, and present relevant information and recommendations to the pilot through a pilot interface device.

The keyword here is "open": the pilot assistant can identify trends, detect issues, prioritize information, and recommend a course of action, but the operator still takes action and closes the loop. An L2 assistant serves as a powerful advisor, better equipping the crew to accomplish their tasks. Instead of executing predefined modes and handling simple tasks, it participates in the cognitive side of flying while naturally preserving the pilot's and crew's authority and workflow.

Level 3: Closed-Loop Pilot Assistant (Pilot On-the-Loop)

Level 3 is when the pilot assistant advances that reasoning and stops being just an advisor, becoming a more active participant in aircraft operation and beginning to close parts of the decision loop on its own.

A closed-loop pilot assistant can not only identify issues, prioritize information, and recommend a course of action, but it can also perform certain defined actions on the operator's behalf, with pilot approval. The system is still bound, and the human remains in command, but the system is no longer limited to observation and recommendation alone.

That may sound like a modest step up from Level 2, but it's a meaningful one. Once a system is allowed to act on the aircraft, even in a narrow and well-defined way, the stakes change. The integration and certification efforts rise sharply as the system interfaces more directly with avionics, aircraft systems, flight controls, and other electronics. Questions about failure modes, authority oversight, and system behavior become even more important.

Level 4: Restricted AI Pilot

Level 4 is another meaningful step; the system moves from assistant to restricted AI pilot. In nearly all situations, I would expect this pilot to be accompanied by fully qualified human pilots. The remaining failure rate would be too high to justify, aside from highly attritable military missions.

A Level 4 system can serve as the pilot, but only within a defined set of missions, environments, and operating conditions. Those restrictions can take many forms: specific routes, certain weather conditions, daytime-only operations, particular airports, limited airspace, or other assumptions.

This concept of defined operating boundaries is called the Operational Design Domain (ODD), the set of conditions a system is designed, tested, and trusted to handle. Automotive autonomy teams shrink their ODD aggressively to manage complexity: fixed routes, good weather, avoiding tunnels and roundabouts. If there is doubt, confusion, or the ODD has been exceeded, you can pull over and stop. Aviation has far less control over its ODD, with one immediate, obvious difference: once an aircraft has taken off, it is committed to landing somewhere, and there are no guarantees the external environment will cooperate. We've all seen a forecast for a sunny day turn into a mid-day thunderstorm, especially on the time horizon of long commercial flights. It's also why the FAA generally constrains experimental autonomy programs to daytime, clear weather, and unpopulated geographical boxes. These controls reduce risk, but also reduce exposure to exactly the adverse conditions autonomy needs to learn to handle.

So Level 4 is the aviation equivalent of autonomy within an ODD, and Waymo is the closest automotive analogy. Within its envelope, the system can perform the function of a pilot. Once conditions move outside that envelope, the system's authority ends, and it must hand control back to a human or execute a defined contingency. For a two-pilot aircraft, this capability may function as a copilot for certain portions of a mission. For a single-seater, this could unlock more opportunities for capability during busy times like an emergency, divert, or mission change. It could also enable limited unmanned aviation or remote human operation.

Level 5: General AI Pilot

Level 5 is the final version of pilot autonomy: an all-operating-domain AI pilot.

A Level 5 system can perform the full role of the pilot across all missions, environments, operating domains, and aircraft states currently handled by human aviators. It is not limited to a constrained operating envelope or a narrow set of assumptions. The system can manage the full range of real-world aviation complexity, and potentially operate beyond human capability in some areas.

This is not just "no pilot on board" in the narrowest sense. It is a machine that can truly replace the pilot function across the full range of real-world aviation. That is an extremely high bar, and it is much more difficult to achieve than many people acknowledge. It is also far beyond what most people mean when they casually describe a system as autonomous.

Right now, the data, technology, regulations, and public acceptance aren't in place for commercial operations at Level 4 or 5 in aviation autonomy.

Automation Becomes Autonomy Between Levels 1 and 2

As you move up the levels, the nature of the system changes, and the line between automation and autonomy sits between Levels 1 and 2.

Level 1 is firmly in the world of rule-based automation, the microwave. It is traceable, testable, and well-understood. It follows pre-defined logic predictably and reliably, but it does not reason through ambiguity, context, or real-world complexity.

Level 2 is the first level that reasons. It incorporates context and probability and forms judgments, but the loop stays open; the operator evaluates the recommendation and acts.

Level 3 advances that reasoning and begins to close parts of the loop itself, performing actions on the operator's behalf with approval. The reasoning is present at both levels; what changes is how much of the decision loop the machine is trusted to close.

By Levels 4 and 5, the machine holds the full pilot role. Systems that operate under uncertainty incorporate additional context and make or support judgments in situations that cannot be fully boiled down to decision trees or checklists. That makes them less traceable and less predictable than pure rule-based code, but it is also the only way to handle the kind of complexity a real pilot handles every day. It also means that, for most aircraft, a major hardware retrofit is necessary. For Cruise to convert a Chevy Bolt electric vehicle (EV) into an autonomous vehicle (AV), they had to add all of the orange hardware below. You can imagine how much additional hardware this could necessitate in aircraft, especially older aircraft before modern digital integration.

A Single Autonomy Level Is Only Part of the Concept

It's worth closing with a warning about how this framework gets used.

It's tempting to treat the numbers like a score; higher is always better, Level 4 beats Level 2, and Level 5 always wins. That is not what this framework is for.

These levels describe the degree of autonomy in a system, and how much of the pilot's role has shifted from the human to the machine. They do not describe how effective the system is within that level, how much value a specific application of autonomy creates, or the tangible aid a system can deliver to a crew. In aviation, all of these things matter because the gap between a "system that technically sits at Level 4" and a "system that utilizes Level 4 autonomy to successfully complete a mission" can be enormous.

That idea is the next step in thinking through this problem space, and it's arguably the more important one. That's what I plan to write about next; in the next piece, I'll lay out the second axis: capability within levels.