Reliable Robotics: Bringing Autonomous Cargo Aviation to Certification

The aerospace certification system was designed around a simple assumption: a qualified human pilot is in the loop, and the aircraft must remain flyable even when that human makes mistakes. Reliable Robotics is trying to certify a system that removes that human from the cockpit entirely — while reusing a 40-year-old type certificate that was issued under entirely different assumptions.

That tension sits at the center of everything the Mountain View company is doing. Understanding it clearly is the only way to evaluate whether their approach is credible, and how close they actually are to the certificated product they have been publicly targeting.

What Reliable Robotics Is Actually Building

The company’s product is not a new aircraft. It is an autonomous flight system — avionics, actuators, software, and a ground control interface — designed to retrofit onto the Cessna 208 Caravan, one of the most common single-engine turboprop cargo platforms in North America. The Caravan is FAA type-certificated, commercially mature, and already operated extensively by freight carriers including FedEx feeder networks and Amazon Air contractors.

Choosing the Caravan was not an accident. It gives Reliable Robotics a platform with decades of operational data, a well-understood failure mode library, and an existing maintenance ecosystem. Critically, it sidesteps the enormous cost and time burden of certifying a new aircraft from a clean sheet. The business logic is sound. The certification logic is where things get complicated.

The Retrofit Certification Problem

When the FAA issues a type certificate for an aircraft, that certificate embeds a complete safety case. It defines what the aircraft is, how its systems interact, what failure conditions are acceptable, and at what probability thresholds. Every subsequent modification to a certificated aircraft requires showing that the modification either maintains those properties or is covered by a supplemental type certificate (STC) that extends the safety case appropriately.

An STC for a new autopilot mode or a revised avionics suite is well-trodden territory. An STC that effectively transfers pilot-in-command authority to a software system is not. The challenge is not administrative — it is architectural. The Caravan’s original type certificate assumes a human pilot as a load-bearing safety element. The autonomous system must either replicate that safety contribution through engineered means or make a credible argument that the original design margins are sufficient without it.

Neither path is clean. The first requires demonstrating that the autonomous system’s reliability and failure response meet or exceed what a qualified human pilot provides — a comparison the FAA has no standardized methodology to evaluate. The second requires re-examining the original safety analysis and showing that margins built into the Caravan’s design were never actually dependent on pilot intervention in the relevant failure modes.

Reliable Robotics appears to be pursuing a hybrid of both: designing the autonomous system to extremely high integrity levels while simultaneously working with the FAA to establish new means of compliance that allow system-level probabilistic arguments to substitute for the pilot-in-command assumption. That is not a shortcut. It is arguably the hardest certification path in civil aviation right now.

DO-178C and DO-254: Where the Real Work Lives

The flight software and flight-critical hardware in Reliable Robotics’ system will need to satisfy DO-178C and DO-254 respectively — the avionics industry’s software and complex electronic hardware standards. Given that any failure of the autonomous flight system on a crewed-out aircraft is a potential catastrophic event, the relevant design assurance levels are DAL A for the most critical functions.

DAL A under DO-178C requires exhaustive structural coverage analysis — modified condition/decision coverage at minimum — for every line of flight-critical code. It requires complete traceability from system requirements through software requirements, design, code, and test cases. It requires independence between development and verification activities. For a company building novel software architectures, this is not a documentation exercise. It shapes how you write code, how you structure your teams, and how long everything takes.

The hardware side under DO-254 is, if anything, less well-understood in the industry. The standard is less prescriptive than DO-178C, which gives programs more flexibility but also more ambiguity when it comes to demonstrating compliance to an FAA DER. Custom FPGAs or ASICs used in flight-critical functions at DAL A require a level of formal analysis and structured testing that most commercial semiconductor development processes were not built to accommodate. Companies routinely underestimate this and hit schedule slips late in the program when hardware compliance gaps surface during certification audits.

There is an additional complexity for Reliable Robotics specifically: their system sits at the interface between two different certification domains. The Caravan’s existing avionics have their own DO-178C and DO-254 lineage, with their own Software Accomplishment Summaries and Hardware Accomplishment Summaries already accepted by the FAA. The autonomous overlay must interface with those systems without corrupting their certified properties. Every command the autonomous system sends to the existing flight control surfaces is an interaction across that boundary. Demonstrating that the existing certified systems cannot be driven into uncertified states by the autonomous overlay is a partitioning problem that requires careful architectural design and a compelling safety argument.

FAA Engagement: Co-Development Over Petition

Reliable Robotics has been notably public about working directly with the FAA rather than waiting for formal rulemaking on autonomous aviation. This is the right strategy, and they appear to be executing it deliberately.

The practical mechanism is the Issue Paper process. When a novel certification problem lacks applicable regulations or accepted means of compliance, the applicant and the FAA document the open question, propose a resolution approach, and work toward agreement before significant certification credit work has been done. Getting alignment on an Issue Paper early is vastly preferable to completing a certification activity and then discovering the FAA’s interpretation of the applicable requirement differs from yours.

The FAA’s MOSAIC rulemaking and broader NextGen regulatory work have created some procedural space for novel certification approaches, but autonomous commercial operations are not yet covered by clear final rules. Reliable Robotics is essentially co-authoring the regulatory framework for cargo autonomy as they build the product — which is both an opportunity and a risk. It is an opportunity because early movers who help shape the framework often have an easier path through it. It is a risk because regulatory co-development is slow, and external timeline pressures on the FAA can shift priorities in ways the applicant cannot control.

Their cargo-first strategy directly addresses this risk. Cargo operations under Part 135 or Part 91 have less political sensitivity than passenger air taxi operations. There is no passenger manifest to point to in a congressional hearing. This reduces the probability of a regulatory freeze driven by public perception events, which is a genuine concern in the autonomous aviation space after several high-profile incidents with other autonomous vehicle categories.

The Systems Engineering Integration Challenge

Underneath the regulatory narrative is a systems engineering problem that deserves direct examination. The Reliable Robotics system must maintain a valid and complete requirements traceability structure that spans the original type certificate artifacts, their own system-level requirements, and the interface requirements at every point where the autonomous system touches the existing Caravan design.

This is not a problem that yields to spreadsheet-based traceability or document-centric requirements management. The dependency graph between the original aircraft safety analysis, the STC safety case, the DO-178C software requirements hierarchy, and the DO-254 hardware requirements hierarchy is genuinely complex. Requirements change — sometimes because the FAA asks for it, sometimes because test results reveal gaps, sometimes because the architecture evolves. Every change propagates through multiple interconnected artifacts, and missing a propagation is how you get certification findings late in a program that require expensive rework.

The teams working at this intersection of legacy certification artifacts and novel system requirements are increasingly recognizing that graph-based requirements traceability — where relationships between requirements, hazards, verification evidence, and design elements are first-class data — handles this kind of multi-domain integration substantially better than document-based approaches. Tools like Flow Engineering are purpose-built for exactly this architecture: maintaining live traceability across complex system hierarchies where changes need to propagate intelligently and the relationships between requirements matter as much as the requirements themselves. For a program like Reliable Robotics’, where the traceability structure spans a 40-year-old type certificate and a cutting-edge autonomous system, that kind of connected model is not a convenience — it is a risk management mechanism.

Honest Assessment

Reliable Robotics is working on one of the genuinely hard problems in aerospace. Their approach — retrofit an existing platform, start with cargo, engage the FAA early, target realistic commercial partners — is more technically credible than most autonomous aviation programs. The team has deep aerospace pedigree, which matters when you are navigating the FAA’s certification apparatus.

The real unknowns are schedule and regulatory velocity. The FAA’s bandwidth for novel certification programs is finite, and the staffing pressures on the agency are real. Programs that depend on regulatory co-development can move faster than petitioning for new rulemaking, but they are still dependent on FAA engagement cycles they cannot fully control. The DO-178C and DO-254 scope at DAL A is substantial, and hardware compliance in particular has a way of revealing itself late.

What they have right is the framing. The question is not whether autonomous cargo aviation is technically feasible. Multiple programs have demonstrated controlled autonomous flight on certificated platforms. The question is whether you can build a complete, defensible certification basis that satisfies the FAA’s safety objectives without a human in the loop. That is a systems engineering and regulatory problem as much as it is a technology problem. Reliable Robotics appears to understand that distinction. Whether they can execute against it at the speed their investors expect is the open question the next two to three years will answer.