Reliable Robotics: Certifying Autonomous Flight for Cargo Aviation
How a Mountain View startup is navigating the FAA’s certification maze to retrofit autonomy onto an already-certified aircraft
Reliable Robotics has been flying autonomous cargo missions with a retrofitted Cessna 208 Caravan since 2019. They have accumulated thousands of flight hours and completed FAA-witnessed remote operations. The company secured a Part 135 air carrier certificate in 2023. By conventional startup metrics, they are executing well.
What rarely gets discussed with appropriate precision is how technically and regulatorily difficult what they are attempting actually is. Certifying an autonomous flight system for commercial cargo operations is not a software problem with an aviation wrapper. It is a full-stack systems engineering challenge that sits at the intersection of legacy airworthiness frameworks, novel automation categories for which FAA guidance is still being written, and the operational realities of cargo aviation networks that do not tolerate unpredictable availability.
Understanding what Reliable Robotics is actually doing — and what it costs them to do it — requires understanding the specific certification path they have chosen and why the alternatives were worse.
The Aircraft They Chose, and Why That Choice Has Consequences
The Cessna 208 Caravan is not an accidental selection. The 208 is a rugged, proven single-turboprop utility aircraft with over 2,500 airframes produced since 1984. It holds FAA type certification under a Part 23 framework, it is widely operated in cargo configurations, it has a mature maintenance ecosystem, and its operational envelope — short-field capable, versatile, economical — maps cleanly onto the regional cargo routes that represent the addressable near-term market for autonomous freight.
The Caravan also has a characteristic that is both asset and liability: it was designed for a human pilot, in the seat, with hands on controls. Every subsystem in the aircraft — the Garmin G1000 avionics suite in modernized variants, the PT6A engine, the hydraulically actuated flaps, the pneumatic de-ice — was certified as part of a human-in-the-loop system. The type certificate (TC) documents assumptions about human intervention, human monitoring, and human authority that are baked into the original airworthiness baseline.
The moment you propose to remove the human from the cockpit and replace their function with an autonomous system, every one of those embedded assumptions becomes a certification question that must be explicitly re-examined.
STC vs. New TC: Why the Path Choice Matters Enormously
Reliable Robotics is pursuing certification via Supplemental Type Certificate (STC) rather than applying for a new type certificate for an autonomous aircraft. The STC path means they are treating their autonomous flight system as a modification to the existing 208 type design. The FAA’s regulatory basis for the modification must be consistent with — or explicitly deviate from — the original TC’s certification basis.
This is pragmatically sensible. A new TC for an autonomous aircraft would require Reliable Robotics to establish an entirely new certification basis, potentially under FAA’s evolving Special Class regulations for novel aircraft, with no existing precedent for the certification plan. That path could take a decade.
The STC path is faster in principle but creates a specific and underappreciated problem: the interface between what the original TC owns and what the STC owns is not clean. The original Cessna 208 TC defines requirements for flight characteristics, structural limits, propulsion system operation, and cockpit environment that were validated with a human pilot as part of the system. The STC must now define, with engineering rigor, which of those requirements are unchanged, which are affected by the autonomous modification, and which new requirements are introduced by the autonomous system.
This is not a paperwork problem. It is a requirements engineering problem of the first order.
The Interface Problem: Where Legacy Meets Autonomous
Consider a concrete example. The original 208 certification basis includes requirements for pilot workload during normal and abnormal operations — requirements derived from human factors analysis. Those requirements informed cockpit layout, control forces, and alert thresholds. An autonomous system does not have workload in the human sense, but it has analogous constraints: computational load, sensor fusion latency, decision algorithm response time, failure mode detection and response time.
Reliable Robotics must characterize the mapping between the original human-pilot assumptions and their autonomous system’s actual behavior — and they must do this at a level of precision the FAA will accept as demonstrating equivalent safety. Where the mapping is imperfect, they must either show that the deviation is conservative (i.e., the autonomous system exceeds the original human requirement) or obtain a specific deviation with a compensating means of compliance.
Multiply this analysis across every subsystem that the original TC touched with human-in-the-loop assumptions, and the scope of the interface characterization problem becomes clear.
The systems engineering discipline required here is bidirectional traceability between two requirements trees that were never designed to speak to each other: the original TC requirements and the autonomous system requirements that Reliable Robotics is generating. The failure to maintain this traceability rigorously — to know at every point which legacy requirement is affected by which autonomous system design decision — is not just an organizational risk. It is a certification risk. The FAA will ask for this traceability, and gaps in the answer will stop the program.
Regulatory Parallel-Path: Engineering While the Rules Are Being Written
The FAA has been working on regulatory frameworks for highly automated aircraft since at least 2020, with publications including AC 23-29 on automation in Part 23 airplanes and ongoing work under the Aviation Rulemaking Advisory Committee (ARAC) on highly automated systems. The fundamental problem for a company like Reliable Robotics is that these frameworks are still evolving. They are not certifying against a finished regulatory target. They are certifying against a moving one.
This creates a practical dynamic that is unusual in most engineering domains: the regulatory basis for portions of their certification is being negotiated in real time, through a combination of formal issue papers with the FAA, participation in industry working groups, and precedent-setting discussions around specific technical questions for which no guidance material yet exists.
The question of what constitutes an acceptable means of compliance for an autonomous system’s failure mode and effects analysis, for example, does not have a clean answer in existing AC or advisory material. Reliable Robotics is, in practical terms, helping to write that answer — not by lobbying, but by doing the engineering work and presenting it to the FAA in enough detail that the agency can evaluate it and, eventually, accept or modify it.
This parallel-path dynamic has costs. Engineering decisions that seem locally reasonable at one point in the program may need to be revisited when the regulatory negotiation produces a different answer than anticipated. Requirements churn of this type is one of the primary sources of schedule risk in certification programs, and it is structurally unavoidable in Reliable Robotics’ position as an early mover.
The Safety Case Architecture
The core of any aviation certification is the safety case: a structured argument, supported by evidence, that the system meets the required level of safety for its operational category. For a commercial cargo aircraft, the relevant target is the quantitative failure rate requirements in the certification basis — for catastrophic failure conditions, on the order of 10⁻⁹ per flight hour.
For an autonomous system, the safety case has additional structural challenges that are not present in conventional certification. Human pilots are not explicitly modeled in traditional safety analyses — their judgment is treated as a given, and the certification basis reflects decades of operational data about pilot performance across the fleet. Remove the pilot and replace them with software and sensors, and you must now explicitly model the behavior of the autonomous system in every failure mode, including correlated failure modes that do not appear in single-point failure trees.
Common-cause failures, in particular, require careful architectural analysis. An autonomous system that relies on a common sensor suite for navigation, traffic awareness, and engine monitoring has correlated failure exposure that a traditional aircraft with a human pilot monitoring multiple independent indicators does not. Reliable Robotics’ published technical work indicates they have invested heavily in architectural redundancy — redundant flight computers, independent sensor paths, deterministic fallback modes — specifically to address the common-cause failure concern.
The remote monitoring infrastructure also becomes part of the safety case in a way that has no clean precedent. When a remotely operated aircraft encounters an abnormal condition, the human controller in the loop is not in the cockpit. Their situational awareness is limited by datalink latency, display fidelity, and the quality of the monitoring system. This means the monitoring system itself must be part of the airworthiness argument, creating a certification scope that extends well beyond the aircraft.
Cargo First: The Operational Logic
Reliable Robotics’ focus on cargo aviation is not merely a market choice — it is a safety case choice. Cargo operations eliminate the passenger safety dimension, which simplifies the public risk analysis for overflights. Cargo routes in the U.S. cargo network — particularly feeder routes serving regional distribution hubs — are more predictable in their operational profiles than charter or on-demand passenger operations. Predictable profiles are easier to bound in a safety analysis.
The operational model also matters. Reliable Robotics’ approach involves remote operators monitoring multiple aircraft simultaneously from ground control stations, with intervention capability but not continuous manual control. This is a scalability model that only makes economic sense if the per-aircraft workload is low — which requires that the autonomous system handles the vast majority of operational decision-making without remote operator input. The certification challenge is demonstrating that the system is safe when operating in that normal mode, not just when a remote operator is actively engaged.
What Comes Next, and What It Costs
Reliable Robotics has not published a specific certification timeline, which is consistent with the reality of programs in active regulatory negotiation. FAA certification programs of this novelty routinely extend beyond initial estimates as issue papers accumulate and technical positions require revision.
The company’s resource intensity is worth acknowledging plainly. Certification programs at this level of complexity require sustained investment in safety engineering, regulatory affairs, test infrastructure, and the organizational patience to maintain rigor across a multi-year program timeline. The team they have assembled — drawing from NASA, SpaceX, and established aerospace — reflects an understanding that this is not a domain where you can shortcut the engineering.
The precedent value of what Reliable Robotics is building is also substantial and underappreciated by outside observers. The regulatory positions they establish, the means of compliance they negotiate, and the safety case architecture they develop will shape how autonomous cargo aviation — and eventually autonomous passenger aviation — gets certified in the United States. That is not a secondary benefit of the program. For the industry, it may be the primary one.
Honest Assessment
Reliable Robotics is doing serious, consequential engineering work in a domain that demands it. Their strategy — STC retrofit of a proven airframe, cargo-first market entry, remote operations model, rigorous regulatory engagement — is coherent and well-reasoned given the constraints of the environment.
The risks are also real. Regulatory timelines for novel certification programs slip. The parallel-path dynamic of certifying while the regulatory framework evolves creates unavoidable requirements instability. The interface characterization between legacy TC requirements and new autonomous system requirements is the hardest sustained engineering problem on the program, and managing it with the rigor that both good engineering and FAA review demand requires organizational discipline that is difficult to maintain across a multi-year timeline.
If they get it right, they will not just have certified an autonomous cargo aircraft. They will have built the certification scaffolding that makes the next autonomous aircraft program substantially faster. That is the real prize, and it is worth the difficulty of the path.