Why We Design Aviation Autonomy Around Scenarios, Not Features

By Tommy Griffith It is easy to describe an autonomy system as a list of capabilities.

Perception. Navigation. Planning. Communications. Taxi. Takeoff. Landing.

But aircraft do not operate as a collection of independent features.

They operate through scenarios.

An aircraft receives a clearance. It begins taxiing. The clearance changes. It approaches a runway. Another aircraft occupies it. Communications become ambiguous. A sensor degrades. The mission continues.

What matters is not simply whether each individual capability works.

What matters is whether the system behaves correctly as the situation evolves.

That is why we design aviation autonomy around operational scenarios rather than feature lists.

A scenario requires multiple parts of the autonomy stack to work together. Perception informs localization. Communications change mission state. Mission state changes planning. Planning creates constraints for guidance. Guidance determines what information needs to be presented to a pilot or acted upon by the aircraft.

The interfaces between those capabilities are often where the hardest problems appear.

Consider something as simple as taxiing to a runway.

The system may need to understand an ATC clearance, associate it with airport geometry, determine the intended route, track aircraft progress along that route, recognize runway crossings and hold-short constraints, handle amendments from ATC, and determine what guidance remains valid as the situation changes.

None of those behaviors can be fully understood in isolation.

Working through the scenario exposes the relationships between them.

Scenario-driven development also changes how we think about system requirements.

Instead of asking only:

Can the system understand an ATC clearance?

We can ask:

What should happen when ATC changes that clearance while the aircraft is already moving?

Instead of asking:

Can the system detect a runway?

We can ask:

How should runway perception affect guidance when localization confidence begins to degrade during an approach?

Those questions often surface architectural decisions that feature-level requirements miss.

They also create a natural foundation for verification.

A scenario can be exercised repeatedly in simulation, recorded data, hardware-in-the-loop environments, and ultimately flight testing. As individual components evolve, the same operational behavior can continue to be evaluated end to end.

In practice, this gives us a common thread from system architecture and requirements through implementation, integration, and test.

For aviation autonomy, that matters.

The goal is not a collection of impressive capabilities.

The goal is a system that can move through real operational situations coherently, predictably, and safely.

That starts with designing around the mission, not the feature list.