Reliable Robotics and the Autonomous Retrofit Problem
Certifying novel autonomy on legacy airframes is one of the hardest systems engineering problems in aerospace today
Autonomous flight has two credible paths to commercial operation. The first is the clean-sheet approach: design an aircraft from scratch with autonomy as a native capability, certify the whole system together, and avoid the burden of reconciling decisions made before autonomy was a design consideration. The second is the retrofit approach: take an aircraft that is already type-certificated, operationally trusted, and commercially deployed, and add autonomous systems through a Supplemental Type Certificate. The clean-sheet path is theoretically cleaner but operationally slow and commercially risky. The retrofit path is faster to market but creates a specific class of systems engineering problem that the aviation industry has never fully solved at scale.
Reliable Robotics, based in Mountain View, California, has chosen the retrofit path. Their lead platform is the Cessna 208 Caravan — a single-turboprop workhorse used extensively in regional cargo, bush operations, and feeder routes. The Caravan has over three decades of operational history, a large installed fleet, and an FAA type certificate that encodes thousands of engineering decisions made under assumptions that predate modern autonomous systems by a generation. Reliable’s task is to make that aircraft fly without a human on board, certifiably, under Part 135 commercial operations, without invalidating what the original type certificate guarantees.
That is a genuinely difficult problem. What follows is an analysis of why.
The Commercial Logic of Retrofitting Certified Aircraft
Before examining the engineering challenge, it is worth being precise about why the retrofit path is attractive. The Cessna 208 Caravan is not an arbitrary choice. It is already approved for cargo operations. It already has a large operator base familiar with its maintenance and dispatch characteristics. The supply chain for airframe and engine components is mature. Insurance underwriters have decades of loss data. And critically, the FAA has a deep institutional familiarity with the Caravan that does not exist for any novel platform.
From a certification timeline perspective, starting with a known airframe means the baseline airworthiness case is already established. Reliable does not need to prove that the Caravan can fly — the FAA has already agreed that it can. What Reliable needs to prove is that their autonomous systems do not compromise that baseline, and that the modified aircraft meets an acceptable level of safety for uncrewed operations.
That framing sounds like it reduces the certification burden. In some dimensions it does. In others, it makes it harder.
What a Supplemental Type Certificate Actually Requires
A Supplemental Type Certificate is not a minor modification approval. For a system as architecturally significant as autonomous flight control, an STC is a full engineering effort with its own certification basis, its own compliance documentation, and its own set of interface requirements with the original type design.
The STC applicant — in this case, Reliable Robotics — must define the modification, establish a certification basis with the FAA through a Project Specific Certification Plan, and demonstrate that the modification either does not affect the areas covered by the original TC, or that any effects are analyzed and acceptable. For conventional modifications — upgraded avionics, new cargo interior configurations, different engine variants — this is a well-understood process. For a modification that replaces the pilot entirely with an autonomous control system, the process is far more complex because the modification touches nearly every system on the aircraft.
The flight control system, the electrical architecture, the autopilot, the communications stack, the navigation and surveillance systems, the engine management interfaces — all of these have defined behaviors and operating envelopes in the original type design. An autonomous flight system that commands all of them must demonstrate compatibility at every interface. It must also demonstrate that failure modes introduced by the new system do not propagate into the certified baseline in ways that were not analyzed in the original aircraft’s Functional Hazard Assessment.
Reliable has reportedly structured their FAA engagement through a series of program letters and issue papers establishing how novel elements — particularly the autonomy stack and the remote pilot in command architecture — will be treated in the certification basis. This is standard practice for novel technology, but it means that significant portions of the certification path are being negotiated and written in parallel with the engineering work, not inherited from existing regulations.
The Interface Problem
The deepest technical challenge in Reliable’s program is not the autonomy stack in isolation. Modern autonomous flight algorithms, computer vision for terrain and traffic awareness, and remote command architectures are difficult engineering problems, but they are problems the industry has substantial tooling and experience to address. The hard problem is the interface between the autonomous system and the legacy aircraft.
The Caravan was designed with a human pilot as the explicit integration point. The pilot reads instruments, interprets warnings, exercises judgment across ambiguous states, and actuates controls. The aircraft’s systems are not designed to be commanded by software in real time — they are designed to present information to a human who then decides what to do. The autopilot that exists on the Caravan is a flight director and hold-mode system, not an authority-complete flight management system. The engine management system was designed for human interaction. The electrical system’s load management was designed assuming a human will respond to warning lights.
Reliable’s autonomous system must serve as a software proxy for all of that human judgment. That requires a layer of interface logic — sometimes called a vehicle interface layer or abstraction layer — that translates between the behavioral language of the autonomy stack and the physical and electrical interface language of the original aircraft systems. Every input and output in this interface layer is a certification surface. Every assumption encoded in it is a requirement that must be traced, tested, and verified.
This is where legacy avionics standards and emerging autonomous systems guidance collide in practice. DO-178C, the software standard for airborne systems, provides a rigorous framework for verifying that software does what its requirements say. DO-254 covers the hardware side. ARP4754A provides the systems engineering process framework that sits above them. These standards assume that you can decompose a system into well-defined functions, allocate requirements to hardware and software items, and verify each item against its requirements in a structured way.
The autonomy stack does not fit neatly into that model. Machine learning components, in particular, are difficult to verify using traditional requirements-based testing because their behavior is not fully captured by explicit requirements — it emerges from training data and model architecture. The FAA’s BEYOND program and various international working groups have been developing guidance for certifying machine learning in aviation, but that guidance is not yet mature or stable. Reliable is working in an environment where the regulatory expectations for some of their most novel components are still being defined.
Managing Requirements Across Two Regulatory Worlds
For a program like Reliable’s, requirements management is not primarily a documentation discipline. It is an architectural discipline. The structure of the requirements hierarchy encodes decisions about how the autonomous system relates to the original type design, and those decisions have direct regulatory consequences.
At the top of the hierarchy is a set of system-level safety objectives derived from the STC certification basis and the applicable operating rules. These objectives must be decomposed into allocated requirements for each subsystem — the autonomy stack, the vehicle interface layer, the communications architecture, the ground control infrastructure. Each allocated requirement must be traceable upward to a safety objective and downward to a verification activity.
The complication is that the requirements exist in two different regulatory contexts simultaneously. Requirements governing the interface with the original aircraft systems must be consistent with the assumptions and limitations encoded in the original TC data. If the Caravan’s fuel system has a defined operating envelope under the original TC, Reliable’s autonomy stack cannot command it in ways that exceed that envelope — and the requirement not to do so must be explicit, traceable, and verified. At the same time, requirements governing the autonomous decision-making logic must satisfy whatever emerging guidance the FAA establishes for autonomous systems, which may use different frameworks, different safety assessment methodologies, and different levels of design assurance.
Programs that try to manage these two requirement sets in separate documents — a legacy-compliance requirements set and an autonomy requirements set — often discover late in the program that the two sets make inconsistent assumptions about shared system states. The vehicle interface layer becomes a zone of requirement ambiguity where neither framework applies cleanly. Resolving that ambiguity after the architecture is built is expensive. Resolving it before requires a degree of integrated requirements management that document-based tools handle poorly, because document-based tools do not naturally capture the dependency relationships between requirements in different domains.
The Operational Architecture and Remote Pilot Question
One element of Reliable’s approach that has significant systems engineering implications is the remote pilot in command concept. Rather than fully uncrewed autonomous operation with no human in the loop, Reliable’s initial commercial model involves a remote pilot who monitors operations and can intervene. The aircraft can fly itself, but a qualified human is available to assume command.
This architecture is strategically intelligent from a certification standpoint — it provides a supervisory function that the FAA can treat as a safety layer analogous to the human pilot’s judgment function, which reduces the autonomous system’s required level of design assurance for some functions. But it creates its own requirement surface. The remote pilot interface — the ground control station, the command and control datalink, the situational awareness displays — must itself meet airworthiness requirements. The datalink must be characterized for latency and reliability. The handoff protocol between autonomous operation and remote pilot control must be defined, verified, and trained to.
Every element of that architecture generates requirements that must be managed alongside the aircraft-level and autonomy-level requirements. The system boundary for certification is not the aircraft skin — it extends to the ground station and the communications infrastructure.
An Honest Assessment of Where This Leads
Reliable Robotics is attempting something that has no direct precedent. There are precedents for uncrewed aircraft — military UAVs have been certified under various frameworks, and small UAS operations under Part 107 are routine. There are precedents for highly automated transport aircraft — modern airliners have extensive automation. But certifying a retrofit autonomous system on a type-certificated general aviation aircraft for commercial Part 135 cargo operations, with a remote pilot architecture, against a certification basis that is being jointly developed with the FAA in real time, is a novel combination of challenges.
The commercial case is real. Regional cargo demand is strong, the pilot shortage is structural, and the Caravan’s operating economics improve significantly without crew costs. If Reliable can certify this system and operate it safely, the template is applicable to other aircraft types and other operators.
The certification path is long and the requirements engineering burden is substantial. The interface between legacy and novel is not just a technical problem — it is an epistemological one. The original TC encodes knowledge about the Caravan that is partially implicit, partially buried in decades of service experience, and partially captured in documents that were not written with programmatic traceability in mind. Making that knowledge explicit, current, and machine-readable enough to interface with a modern autonomy certification effort is itself a significant engineering undertaking.
Reliable’s bet is that the commercial advantage of starting with a certified airframe outweighs the complexity of that interface burden. Based on what is publicly known about their FAA engagement and their technical progress, they appear to be executing that bet more rigorously than most. Whether the regulatory environment matures fast enough to support their timeline is a question that no amount of good systems engineering can fully answer.
Hardware AI Review covers AI tools and systems engineering practice for hardware and aerospace engineering teams. We do not take positions on company valuations or investment merit.