Data assurance for ML in avionics: EASA learning assurance

For an ML function in an aircraft or ATM system, Issue 2 places an emphasis on data management aspects and learning processes. This page stays with what Issue 2 and the MLEAP research pages say. It does not invent a data-set size, a completeness metric, or an FAA adoption of the W-shaped process.

Status as of 14 October 2026: Issue 2 is still the published guidance (6 March 2024). The library page for EASA Artificial Intelligence Concept Paper — Proposed Issue 3 is still titled Proposed Issue 3, with publication date 03/06/2026. We found no published Issue 03 on that listing. EUROCAE still lists ED-324 as Draft with Target Publication Date: 31/12/2026; ER-027 is still Published 31/12/2024. A vendor mapping of data-quality checks to draft ARP6983 sections is on the Re:In listing; that mapping is not a published AMC.

Learning assurance is an extension, not a replacement

EASA published Issue 2 on 6 March 2024. The news item refines guidance for Level 1 and provides comprehensive guidance for Level 2. The PDF proposes a new concept of learning assurance to extend the traditional development assurance. The goal is confidence that the trained models can generalise with an adequate performance on unseen operational data, and that the ML models are robust in all foreseeable conditions.

The paper says the design-level layers that rely on learning need significant adaptations or changes to the existing development assurance methods, and that assurance should be oriented towards the correctness and completeness/representativeness of the data or scenarios used during development, plus the learning and its verification. Issue 2 does not constitute final detailed guidance. See the EASA explainer and EASA AI Concept Paper levels explained.

The W-shaped process and the three data sets

Issue 2 illustrates learning assurance as a W-shaped cycle that adapts the typical development assurance V-cycle to ML concepts, running with the traditional V-cycle for non-ML constituents. It places an emphasis on data management aspects and learning processes and bases learning assurance on three separate and independent data sets for training, validation and testing.

The paper also says a precise definition of the ConOps is needed to ensure that sufficient and representative data is collected for the data sets that are used for training, validation and testing purposes.

Operational design domain as a data-quality prerequisite

EASA introduces an operational domain at system level and an ODD at AI/ML constituent level to provide constraints and requirements on the data used during learning, implementation, or inference. The ODD provides a framework for the selection, collection, preparation of the data during the learning phase, as well as the monitoring of the data in operations. A correct and complete definition of the ODD is a prerequisite to an adequate level of quality of the data sets.

Issue 2 also tells applicants to analyse and mitigate the effect of exposure to input data outside of the AI-based (sub)system OD or the AI/ML constituent ODD. Those are the official data-boundary words. This page does not add a numeric coverage threshold.

Issue 2 covers supervised and unsupervised learning, but not other types such as reinforcement learning.

What MLEAP adds (research, not AMC)

EASA’s Machine Learning Application Approval (MLEAP) project was initiated by EASA and funded under Horizon Europe to identify concrete means of compliance with the learning assurance objectives. The official page lists three technical topics: guarantees on machine learning model generalisation, guarantees on data completeness and representativeness, and guarantees on algorithm and model robustness.

Task 1 is methods and tools for the assessment of completeness and representativeness of data sets (training, validation, and test). The executive summary of the final report says that task focuses on data quality verification and a selection grid of methods for a complete and representative data set, including quality and volume assessment, preparation, and processing and independent data and learning verification.

The project page says MLEAP ran 05/2022 to 05/2024 and that the official citation is MLEAP Consortium, EASA Research – Machine Learning Application Approval (MLEAP) Final Report, May 2024. MLEAP is closed research. The page does not call the final report Acceptable Means of Compliance.

What this is not

Issue 2 is not final detailed guidance. It is not a US FAA rule. The FAA has said EASA’s work helped inform the FAA roadmap; that is influence, not adoption. See Does the FAA certify AI today?.

Analysis, not sourced fact: a data-assurance package that only reports model accuracy, without an ODD, without three independent sets, and without a completeness/representativeness argument, does not match the structure EASA describes. How a specific project shows those objectives is between the applicant and the authority.

The glossary collects the official terms. For how this sits next to DO-178C and DO-330, see How to map an AI model to DO-178C / DO-330 tool qualification.

Questions

Is EASA learning assurance a published means of compliance?

Issue 2 presents a first set of objectives and does not constitute final detailed guidance. MLEAP is a research project aimed at identifying means of compliance, not a published AMC.

What data sets does Issue 2 name?

Three separate and independent data sets for training, validation and testing. The paper does not, in the passages we cite, specify a required volume.

Does a complete ODD by itself satisfy learning assurance?

No. EASA calls a correct and complete definition of the ODD a prerequisite to data-set quality. Learning assurance still includes the learning process and verification that the model generalise[s] … on unseen operational data.