Aviation certification is the most demanding software assurance regime in commercial practice, and the reason machine learning does not fit into it is specific rather than cultural. The objectives were written around a chain of evidence from requirement to line of code, and a learned model has no such chain.
There is no AI certification basis
Type certification of an aircraft or an appliance runs through 14 C.F.R. Part 21, with airworthiness standards in Parts 23, 25, 27 and 29 depending on the category. Nothing in any of them mentions artificial intelligence, and there is no rule you can point at that says a learned component is prohibited. What exists instead is a set of accepted means of compliance, and none of them accommodates one.
Where the existing standards do not cover a novel feature, Part 21 has machinery: the FAA can issue special conditions under § 21.16 setting additional requirements for a particular design, and applicants and the agency negotiate the certification basis project by project through issue papers. That machinery is how AI components have been handled to date — individually, at considerable cost, and without producing a general rule. An applicant asking “what do I have to show?” gets an answer for their project and not a published standard.
This is a description of a regulatory landscape, not legal or certification advice. Certification bases are established with the FAA for a specific project, and nothing here substitutes for that engagement or for the advice of a designated engineering representative.
The objectives a learned model cannot meet
Airborne software is approved against RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, which the FAA recognises as an acceptable means of compliance through Advisory Circular 20-115D. DO-178C assigns a design assurance level from A to E based on the severity of a failure condition, and sets objectives that scale with it. Four of those objectives are the specific obstacle.
- Bidirectional requirements traceability. Every requirement must trace to code and every line of code must trace to a requirement. In a trained network, the behaviour is in the weights, and no weight traces to a requirement. There is nothing to point at.
- Requirements-based test coverage. Tests are derived from requirements, and adequacy is judged against them. Where the intended behaviour is defined by a dataset rather than by written requirements, the notion of a requirements-based test case has no clean referent.
- Structural coverage analysis. At Level A, DO-178C requires modified condition/decision coverage — demonstrating that each condition independently affects the outcome. A dense network has no branches in the sense the objective means, so achieving the metric is either trivial or meaningless depending on how you map it.
- No unintended function and no dead code. The applicant must show the software does nothing beyond its requirements. A model generalises by construction, which is to say it produces outputs for inputs nobody specified. That property is the reason to use it and the reason it cannot satisfy this objective.
DO-178C already has supplements for other development styles — DO-331 for model-based development, DO-332 for object-oriented technology, DO-333 for formal methods, DO-330 for tool qualification. The absence of an equivalent supplement for machine learning is the gap, and it is a gap in method rather than in willingness.
One consequence shapes every current architecture: models are frozen. Whatever else is unresolved, an airborne component that continues to learn in service has no assurance story at all, because the article certified is not the article flying. Systems in the field use a fixed set of weights, with any update handled as a software change through the normal configuration control process.
What the 2024 roadmap commits to
In July 2024 the FAA published its Roadmap for Artificial Intelligence Safety Assurance, Version 1. A roadmap is a statement of how the agency intends to approach a problem. It is not guidance material, it establishes no means of compliance, and an applicant cannot cite it as one.
Its useful content is structural. It takes an incremental, use-case-driven approach rather than attempting a general AI rule; it organises applications by how much authority the system holds and how severe a failure would be, so that advisory functions with a pilot in the loop are addressed before authority-holding ones; it commits to alignment with EASA and with international standards work rather than to a separate American method; and it covers non-airborne applications — air traffic decision support, maintenance, certification workflows — which sit under different approval processes and are in several respects further ahead, because a failure has different consequences.
The European regulator has been more explicit sooner. EASA published an AI roadmap and a concept paper offering guidance for what it terms Level 1 and Level 2 machine learning applications — assistance to humans, and human-machine collaboration — introducing a “learning assurance” process alongside conventional development assurance, often drawn as a W-shaped lifecycle in which data management and model training carry their own verification activities. Reading it is the fastest way to see the shape a future means of compliance is likely to take, whichever authority publishes one.
The standards work under way
The joint SAE G-34 and EUROCAE WG-114 committee is developing the process standard intended to become the accepted means of compliance for aeronautical products implementing AI. The pattern to expect is the familiar one in this industry: the committee publishes, the authorities recognise the publication through advisory material, and only then does an applicant have something to comply with. That sequence takes years, and the recognition step is the one that turns a document into a certification path.
Anyone building for this market should treat the general-purpose AI management standards as complementary rather than as a substitute. An ISO/IEC 42001 certificate demonstrates an organisational management system, and the NIST AI Risk Management Framework organises risk practice. Neither is evidence of airworthiness, and presenting one as though it were will not survive contact with a certification office.
What is genuinely unresolved
The honest answer to “how will learned components be certified?” is that nobody knows yet, and the specific open questions are these.
- What replaces structural coverage. Candidate metrics based on neuron activation or on input-space coverage exist in the literature, and none has the property that made structural coverage useful: a defensible claim that untested behaviour has been bounded.
- How dataset adequacy is demonstrated. If the training and validation data define the intended function, the evidence must show the data represents the operational domain completely enough. Completeness of a data set against a real-world domain is not something the discipline knows how to prove.
- Whether runtime monitoring can substitute for assurance of the model. Wrapping a learned component in a deterministic safety monitor that can be certified conventionally is the most promising architecture available, but it requires the monitor to be able to recognise a bad output, which for many interesting functions is as hard as producing a good one.
- How human oversight is credited. Advisory systems are approved partly on the basis that a pilot will catch errors. Automation bias is well documented in human factors research, and how much credit oversight deserves is contested rather than settled.
None of this is an argument that AI will not be certified. It is an argument that the timeline belongs to the standards committees rather than to model capability, and that a programme plan assuming otherwise is planning against the wrong constraint.
Top comments (0)