Reliable Robotics: Certifying Autonomous Aviation in a Certification Framework Not Designed for It

Reliable Robotics is trying to certify something the FAA has never certified before: a fully autonomous cargo aircraft operating in the national airspace without a pilot on board. The company has selected existing type-certificated platforms — starting with the Cessna 208 Caravan — and is building a remote-piloting and autonomous flight system on top of them. That choice sounds pragmatic. In practice, it creates a certification architecture of considerable complexity.

The FAA’s existing framework was built around a central assumption: a trained human is present in the cockpit, making decisions, catching failures, and serving as the final layer of the safety system. Remove that human, and every standard in the regulatory stack needs to be re-examined. DO-178C governs airborne software. ARP4754A governs the development of civil aircraft and systems. Neither document contains the word “autonomous” in any operationally meaningful way. The FAA knows this. Reliable Robotics knows this. The question is what they do about it together.

The Retrofit Strategy and Its Logic

Reliable’s decision to start with the Caravan is not arbitrary. The Cessna 208B Grand Caravan has a type certificate, an enormous global fleet, decades of operational data, and a well-understood failure mode profile. It is used extensively in cargo operations, particularly in remote and island-hop environments where automation has obvious economic value. Starting from a certified platform means Reliable does not have to prove the airframe, the powerplant, or the basic avionics systems from scratch. Those battles are already won.

The engineering organization is structured around this premise. Reliable’s systems engineering function is focused primarily on the autonomous system as a supplemental type certificate (STC) addition — the Caravan remains a Caravan, and the autonomous capability is added on top of it. This framing has regulatory advantages. It preserves the base type certificate, which carries enormous embedded certification credit. It narrows the initial certification scope to the delta: the hardware and software being added.

But the narrowing is somewhat illusory. When you add an autonomous flight control and decision-making system to an aircraft, you are not simply adding a new avionics box. You are changing the functional hazard profile of the entire aircraft. Under ARP4754A, that means the safety assessment process — the Functional Hazard Assessment (FHA), the System Safety Assessment (SSA), and the Common Cause Analysis (CCA) — must be revisited for any system whose behavior is affected by or affects the new addition. In a fly-by-wire-adjacent autonomous system installed on a legacy platform, that scope expands quickly.

The Special Conditions Problem

The FAA’s primary instrument for handling certification of genuinely novel technology is the special conditions process, codified under 14 CFR Part 21.16. When an aircraft includes novel or unusual design features not adequately covered by existing airworthiness standards, the FAA issues special conditions to fill the gap. Reliable has been engaged in this process, and the FAA has issued special conditions related to the autonomous system’s remote pilot station, communication link integrity, and autonomous decision-making architecture.

Special conditions are powerful but expensive. Each one must be negotiated between the applicant and the FAA’s Aircraft Certification Service on a case-by-case basis. There is no template, no published playbook, and no binding precedent from prior decisions. A special condition issued to Reliable for communication link loss behavior does not bind the FAA to issue the same condition to a competitor — or even to Reliable’s next platform. The regulatory infrastructure is being built in real time, one aircraft program at a time.

This creates an asymmetric information problem for Reliable’s engineering organization. The company must invest in the safety case before the FAA has fully committed to what that safety case needs to demonstrate. Requirements are negotiated iteratively, which means the systems engineering effort cannot simply be front-loaded. Engineers are writing requirements, developing verification plans, and producing safety artifacts for standards that are still being drafted in parallel. That is not a criticism of Reliable’s process. It is a structural feature of operating at the regulatory frontier.

DO-178C Applied to Autonomous Systems

DO-178C defines the software lifecycle process for airborne software and provides the framework for assigning Design Assurance Levels (DALs) based on the severity of failure conditions. A DAL A failure condition is catastrophic — loss of aircraft. A DAL B condition is hazardous. The assignment drives the rigor of the development process, including requirements coverage, independence of verification, and the depth of structural coverage analysis required.

The autonomous flight management and decision-making software at the core of Reliable’s system almost certainly carries DAL A classification for its most critical functions. That is not unusual for flight control software. What is unusual is the nature of the software itself.

DO-178C was designed for deterministic systems with explicit requirements that can be traced to source code and verified structurally. Machine learning components — even lightweight, highly constrained ones — do not decompose cleanly into that model. Reliable has been public about the fact that their autonomous system is not a neural network making real-time flight decisions. The autonomous logic is rules-based, bounded, and designed to be verifiable under existing standards. That is a deliberate engineering choice, not a capability limitation. It is the correct choice for a company that needs FAA certification in the near term rather than a theoretical path toward it in the indefinite future.

The implication is that Reliable’s autonomy is conservative by design. The system is built to handle the scenarios it can certify, not all scenarios that might be encountered. When the system reaches the boundary of its certified operating envelope, the response is deterministic: revert to remote pilot control or execute a pre-certified contingency procedure. This is a tractable model for DO-178C. It is also a model that requires exceptionally careful requirements engineering, because the boundaries of autonomous authority — where the system acts alone versus where it defers — must themselves be specified, verified, and safety-assessed.

ARP4754A and the Dual-Certification Tension

ARP4754A provides guidance on the development process for aircraft and aircraft systems, with emphasis on requirements capture, safety assessment integration, and verification at the system level. It is the connective tissue between the aircraft-level safety objectives and the component-level development standards like DO-178C.

For Reliable’s retrofit approach, ARP4754A creates a structural tension that deserves direct examination. The Caravan’s existing certification was conducted under the safety assessment methods current at the time. Adding a new system requires Reliable to demonstrate that the autonomous system’s failure modes do not introduce new catastrophic or hazardous failure conditions — but doing so rigorously means conducting a new system safety assessment that necessarily references and re-examines portions of the original aircraft’s safety analysis. That analysis is embodied in the type certificate holder’s (Textron Aviation’s) design data, which Reliable does not own and to which they do not have unlimited access.

This is not an insurmountable problem, but it is a real one. The STC process has mechanisms for working with type certificate holders, and Textron has been a publicly acknowledged partner in the Reliable Robotics program. But the engineering coordination required — aligning two organizations’ safety artifact libraries, managing configuration control across separate design authority boundaries, and ensuring that the combined aircraft-plus-autonomous-system FHA captures failure interactions that neither organization could have anticipated independently — is substantial. It demands a systems engineering function that can reason about the whole system even when the design authority over components of that system is distributed.

The Epistemic Challenge: Demonstrating Safety Without Historical Data

The deepest challenge in certifying an autonomous aviation system is not procedural. It is epistemic. The FAA’s safety case methodology is grounded in historical accident data, operational experience, and failure rate statistics accumulated over decades of aviation. For autonomous cargo aircraft operating beyond visual line of sight, there is no operational history. There are no accident statistics. There are no near-miss databases. The failure modes of a remote communication link under contested electromagnetic conditions, or the behavioral profile of an autonomous system encountering an unanticipated sensor combination, cannot be characterized from experience. They must be derived analytically.

This pushes Reliable’s safety engineering heavily toward formal methods, simulation-based verification, and probabilistic safety analysis conducted without empirical anchors. The FAA’s guidance on acceptable means of compliance for such methods is still evolving. ASTM F3269, which addresses risk-based methods for flight termination systems in unmanned aircraft, offers some applicable framing, but it was not written for manned cargo aircraft certification and does not directly map to Part 23 airworthiness standards.

What Reliable is doing, in practical terms, is building the safety case argument structure — the claims, the evidence, and the inference links between them — while simultaneously negotiating with the FAA about which evidence types are acceptable. This is goal-based safety certification, a model more familiar in European aerospace regulation under CS-25 and EASA’s special conditions regime than in FAA Part 23 practice. The FAA is learning it as Reliable pushes.

What the Engineering Organization Looks Like Under These Constraints

Reliable Robotics is not a large organization by aerospace prime standards. The company has operated with a team of roughly one hundred engineers, a size that forces deliberate prioritization of certification investment. The systems engineering function cannot pursue every possible compliance path simultaneously. The company must make early architectural decisions that constrain the certification approach — designing the autonomous system to fit into DO-178C rather than designing the system first and finding a certification path afterward.

That discipline has visible consequences in the product. The autonomous system’s scope is tightly bounded. The operational design domain — the envelope within which the system operates autonomously — is conservatively defined. The contingency behaviors are deterministic and pre-certified. This is not the autonomous aviation that research papers describe. It is autonomous aviation that can actually be certified.

The engineering organization also carries a documentation and traceability burden that is unusually heavy for a company of its size. Special conditions proceedings generate requirements. FAA issue papers generate requirements. Safety assessment findings generate requirements. Each of these feeds back into the requirements baseline, which must be maintained with sufficient rigor to support both ongoing verification and the eventual certification basis review. Managing that requirements baseline — keeping it consistent, traceable, and current as the regulatory negotiation evolves — is itself a systems engineering challenge of the first order.

An Honest Assessment

Reliable Robotics is doing something genuinely difficult and doing it methodically. The retrofit strategy is intelligent: it reduces the certification surface area for the airframe while keeping the technical problem focused on the novel system. The decision to build rule-based, deterministic autonomy rather than machine-learning-based decision systems reflects a clear-eyed understanding of what is certifiable in the near term.

The risks are real. Special conditions negotiations can stall. FAA resources for novel certification projects are finite. The absence of operational data for failure rate substantiation remains a genuine technical gap. The dual-certification complexity of the STC approach will generate coordination overhead that grows with every revision cycle.

But the regulatory infrastructure that Reliable is helping build — the special conditions precedents, the means of compliance for autonomous decision-making boundaries, the safety assessment methods for systems without operational history — will benefit every autonomous aviation program that follows. That is not a secondary outcome. It is part of the value the company creates whether or not any individual certificate is issued on schedule.

The certification framework was not designed for autonomous aviation. Reliable Robotics is in the process of designing it, one negotiated special condition at a time.