DO-178C and machine learning: where the gaps are

DO-178C was written for software whose behavior is specified by requirements and implemented by engineers. A trained neural network is specified by data and produced by an optimizer. This article lists where that mismatch shows up, using what aviation authorities and standards bodies have published.

The baseline

DO-178C is the core document for defining both design assurance and product assurance for airborne software, and FAA AC 20-115D describes it as an acceptable means, but not the only means of showing compliance for software aspects of airborne systems.

Is there an official statement that there are gaps?

Yes, in three places:

• SAE’s G-34 committee issued AIR6988, which reviews current aerospace software, hardware and system development standards used in certification and assesses whether they are compatible with a typical AI and machine-learning development approach.
• EASA’s concept paper refers to the limitations of traditional development assurance for data-driven approaches.
• The FAA roadmap says AI poses a new challenge because of the absence of engineering principles that guide the traditional engineering design process.

A tool vendor’s commentary makes the same point in plainer terms: LDRA writes that assurance traditionally comes from a cautious approach to change and traceability to requirements, and that AI/ML stands as a challenge to both. That is vendor commentary, not a regulatory statement.

The gaps, one by one

The gap descriptions below are our synthesis. Each cites the source for the underlying fact.

1. What counts as the requirements and the design

In DO-178C workflows, requirements drive design. With ML, the data defines behavior. EASA’s concept paper responds by proposing learning assurance to extend traditional development assurance, shown as a W-shaped process that adapts the V-cycle to ML concepts. A MathWorks worked example takes one possible mapping: it treats training and validation data set requirements as equivalent to software requirements that specify the behavior of the model, and says the trained model represents the software design from which source code is generated. That is one vendor’s worked example, not an accepted means of compliance.

2. Data becomes a certification artifact

EASA says learning assurance will be based on three separate and independent data sets: training, validation and test, and that a correct and complete definition of the operational design domain is a prerequisite to an adequate level of quality of the data sets. These data-centric activities are what EASA adds on top of traditional development assurance.

3. Verification is about generalization, not only requirements coverage

EASA’s MLEAP research project targets guarantees on model generalisation, data completeness and representativeness, and algorithm and model robustness. Analysis: these are evidence types that requirements-based test coverage alone does not provide.

4. Learned versus learning behavior

The FAA roadmap distinguishes learned AI, static in operation, from learning AI, dynamic in operation, noting that with learning AI it is not possible to qualify each version. EASA’s guidelines cover supervised and unsupervised learning but not reinforcement learning, and ED-324 Issue 1 is limited to non-adaptive ML in supervised mode.

5. Criticality ceilings

EASA says it will initially accept only applications where AI/ML constituents do not include IDAL A or B items for supervised learning. ED-324 Issue 1 is scoped up to IDAL C / AL 3 / SWAL 2. Neither document currently covers IDAL A or B.

6. Tool qualification is an open question

The FAA roadmap lists DO-330 among existing standards it is looking to apply and possibly extend. We did not find an official source that settles how DO-330 applies to ML training and verification toolchains, so we make no claim about it. Treat it as a question to raise with your authority. The public 12.2 / TQL criteria and what we did not find are in DO-330 tool qualification for ML toolchains.

What is being done

• FAA: project-specific issue papers and special conditions, per the roadmap.
• EASA: the concept paper and the MLEAP research.
• SAE G-34 / EUROCAE WG-114: ED-324 / ARP6983, which EUROCAE lists as a draft with a target publication date of 31 December 2026. As of 14 October 2026 the same WG-114 page still lists ER-027 (taxonomy) as published 31 December 2024, and adds further drafts: ER-43 human-factors assessment target 31 December 2026; information-security concerns target 31 December 2026; supporting information for ED-324, a reinforcement-learning gap analysis for ED-324/ARP6983, and use-case considerations, each target 30 June 2027. Those extra reports are still drafts; they are not a published means of compliance.

See the SAE G-34 / ARP6983 status article and the SAE G-34 page for current status and the DO-178C / DO-330 page for the baseline documents. For how a trained model sits next to DO-330 tool qualification, see How to map an AI model to DO-178C / DO-330 tool qualification. For structured arguments, see Building an AI assurance case (GSN/AMLAS) for certification. For tools that document robustness verification workflows for airborne use cases, see the directory.