Reliable Robotics: Certifying Autonomous Flight Without a Clean Sheet

Mountain View-based Reliable Robotics has spent the better part of the last decade doing something that sounds straightforward until you look at it closely: making existing cargo aircraft fly themselves. The company’s lead platform is the Cessna 208 Caravan, a single-engine turboprop that has been moving people and freight since 1984. Reliable is not designing a new aircraft. It is inserting a certified autonomous flight system into an airframe that predates digital flight control by a generation, under an FAA regulatory framework not written with machine autonomy in mind.

That combination — novel system, legacy platform, novel regulatory question — defines the company’s engineering challenge more precisely than any marketing summary can.

The Certification Strategy: STCs Over Clean Sheets

Reliable’s path to commercial operations runs through the Supplemental Type Certificate process. An STC authorizes specific modifications to an already-certified aircraft without requiring the base type certificate to be re-opened. This is how avionics upgrades, engine conversions, and structural modifications have historically been approved. Reliable is using the same mechanism to approve an autonomous flight system.

The appeal is real. The Cessna 208 Caravan holds a type certificate with decades of operational history, a well-characterized failure mode database, and established maintenance infrastructure across the cargo industry. FedEx, Ameriflight, and a network of regional operators have collectively flown millions of hours on this airframe. From a certification standpoint, the aircraft itself is a known quantity. Reliable is not asking the FAA to evaluate a new airframe and a new autonomous system simultaneously.

But the STC pathway carries its own constraints. You are certifying a modification to an approved design, which means the base design is fixed. The Caravan’s flight control architecture, hydraulic and pneumatic systems, structural load paths, and avionics bus topology are not design variables Reliable can optimize around. They are givens. The autonomous system has to integrate with what is there, not with what a system architect would have specified from a blank page.

This is the central systems engineering tension: you gain regulatory efficiency by leveraging an existing type certificate, and you pay for it in architectural freedom.

What the Remote Pilot Model Actually Does

Reliable’s operational model involves a remote pilot monitoring and, when required, intervening from a ground control station — not a traditional cockpit. This is not a toy drone setup. The remote pilot holds an FAA certificate, is responsible for the flight, and operates under instrument flight rules in the national airspace system.

The remote pilot model does two things simultaneously. First, it keeps a certificated human in the command loop, which satisfies existing regulatory definitions of pilot-in-command in a way that full autonomy does not yet have a clear pathway to satisfy. Second, it allows Reliable to demonstrate, flight by flight, that the autonomous systems are performing the actual work — that the remote pilot is monitoring a system that is flying correctly, not correcting a system that would otherwise fail.

This is incremental safety case building. The FAA’s certification basis for novel autonomous functions does not yet have a single codified standard equivalent to DO-178C for software or DO-254 for complex electronic hardware, though those standards apply to components within the system. By operating with remote pilots under existing regulations while accumulating autonomous flight data, Reliable is building the operational evidence base that future rulemakings — and future STC applications for higher autonomy levels — will need.

The strategic risk is that this approach depends on the regulatory framework evolving in step with operational evidence. If rulemaking timelines slip, Reliable’s commercial model sits in an intermediate state longer than the business plan assumes.

Inserting Novel Systems Into a Certified Envelope

Consider what it actually means to automate a Caravan. The aircraft’s original design assumed a human pilot with hands and feet on direct mechanical or cable-actuated controls. The flight control surfaces are not electronically commanded at the base type certificate level. Reliable’s system has to command those surfaces through actuators it adds, interfaced through an avionics architecture it installs, without introducing failure modes that the original certification basis didn’t account for.

Every interface becomes a certification boundary. The actuator system that physically moves the controls has to meet reliability targets derived from the criticality of the function — loss of pitch control on a single-engine aircraft is catastrophic by definition, which means the requirements cascade from a probability target on the order of 10⁻⁹ per flight hour. The autonomous flight computer that commands the actuator has to meet its own reliability and software assurance requirements. The communications link between the aircraft and the ground station introduces a failure mode — loss of link — that has to be handled within the autonomous system’s own decision logic, because there is no pilot in the cockpit to take over if the datalink drops.

None of these are unsolvable problems. Reliable has demonstrated extended autonomous flight operations and has been working with the FAA’s Aircraft Certification Service through the certification process. But each of these interfaces represents a system boundary that requires exhaustive requirements definition, allocation, and traceability — and unlike a clean-sheet program, the requirements on the aircraft side of the interface come from a document (the original type certificate data sheet and its supporting analyses) that was not written to be a system-level specification for an autonomous flight control input.

The requirements engineering discipline required to work in this environment is unusually demanding. Engineers have to reverse-engineer the implied requirements embedded in the original certification basis, translate them into formal interface specifications, and then demonstrate that the new system meets those specifications without violating any assumption the original certification relied on. If the original certification assumed that control inputs would have certain force and rate characteristics because a human pilot has physical limitations, and an actuator can exceed those characteristics, the certification basis may need to be revisited even if the STC process nominally avoids opening the base type certificate.

The Dependency Graph Problem

Clean-sheet programs are hard. But they have one significant advantage: the system architecture and the requirements flow in the same direction. You define what the aircraft needs to do, allocate functions to systems, specify interfaces, and design to those specifications. The requirements tree and the design tree grow together.

Retrofit autonomy inverts this partially. You have a physical system with defined behavior, and you have to work backward to extract a formal requirements representation that is complete enough to reason about what you are modifying and what you are assuming remains unchanged. At the same time, you are designing the new autonomous system forward from a requirements baseline. The two activities have to be connected with enough precision that no gap or conflict exists at the interface.

This is a dependency graph problem. The existing aircraft subsystems, their interfaces, their certified failure modes, and their operating envelopes all form nodes in a graph. The autonomous system’s functions form another set of nodes. The STC is essentially a formal argument that the graph, including all the new edges you are adding between old and new nodes, is safe.

Managing that graph manually — in spreadsheets, Word documents, or even traditional requirements management databases organized around linear document hierarchies — creates real risk of losing edge cases. An assumption embedded in the original hydraulic system analysis might be violated by a new actuator load case. A software function in the flight management computer might depend on a sensor that is now being fed by an autonomous system rather than a human input. Tracing those dependencies requires a representation that treats requirements as a connected graph, not a list.

This is the area where modern requirements tooling built around graph-native data models earns its value in programs like Reliable’s. Tools like Flow Engineering, which organize requirements and their relationships as a traversable graph rather than a document hierarchy, are better suited to the kind of bidirectional traceability that retrofit certification demands — where you need to ask not just “what requirements does this component satisfy?” but “what components and assumptions does changing this requirement affect?”

The distinction matters operationally. In a document-centric tool, tracing the downstream impact of a revised interface specification requires manual cross-referencing across multiple documents. In a graph-native model, that query is a traversal. The difference is the difference between finding a problem before it becomes a certification finding and finding it after.

What Reliable Gets Right

Reliable’s engineering judgment in platform selection deserves credit. The Caravan is not the simplest aircraft to automate, but it is close to the best commercial choice. High operator familiarity, massive operational history, Part 135 cargo operations already happening at scale, and a customer base (regional cargo operators, feeder network carriers) that has clear economic motivation to eliminate the cost and availability constraints of single-pilot operations in thin-margin markets.

The remote pilot bridge strategy is also correctly calibrated for the regulatory environment as it exists today. Full autonomy certification requires a regulatory framework that does not yet have settled standards. The remote pilot model operates under existing Part 135 and Part 91 frameworks, with accommodations for the novel aspects handled through the STC and operations specifications process. That is a more navigable path than waiting for the FAA to promulgate entirely new autonomous aircraft regulations, which has historically happened on timescales measured in decades.

The incremental approach — demonstrate safety with remote pilots, accumulate data, build toward higher autonomy levels — reflects a genuine understanding of how the FAA builds confidence in novel systems. Regulatory confidence is not granted; it is earned through operational evidence.

The Honest Assessment

Reliable Robotics is tackling a hard problem with a coherent strategy. That does not mean the strategy is risk-free.

The STC pathway compresses time-to-market relative to a clean-sheet aircraft but imposes architectural constraints that can complicate safety case construction in ways that aren’t always visible until the program is deep into detailed design. The remote pilot model is commercially viable only if the cost structure of remote pilot operations is substantially lower than that of on-board pilots — which requires significant investment in ground control infrastructure and reliable connectivity that is not fully within Reliable’s control.

The broader commercial question — whether the regional cargo market can absorb autonomous operations fast enough to justify the certification investment — depends on factors outside the engineering organization’s hands, including insurance markets, operator readiness, and the pace of FAA rulemaking on autonomous aircraft operations more broadly.

What is not in question is the quality of the technical problem Reliable has chosen. Certifying autonomous systems within legacy aircraft type certificate frameworks is going to be a core competency for the aerospace industry for the next two decades. The pipeline of autonomous air vehicle programs is growing faster than the availability of clean airspace, clean regulatory frameworks, and clean-sheet development budgets. The skills and methods Reliable is building — reverse-engineering certification bases, managing retrofit interface requirements, building incremental safety cases under existing regulations — are transferable across platforms and will define how the industry approaches the next generation of autonomous systems integration.

That may be the most durable thing Reliable Robotics is producing: a methodology, not just an aircraft.