Data sheet Revised
AI & Machine Learning in Certified Systems
Adopting AI without breaking your evidence chain, and preparing machine-learning functions for certification under guidance that is still being written.
- Standards
- DO-178C and DO-330 for AI in the lifecycle; EASA Concept Paper Issue 2 and ARP6983/ED-324 (in development) for AI in the product
- Assurance
- Readiness at any level; no accepted means of compliance exists for machine learning in airborne software today
- When to call us
- Before AI tools touch certification evidence, or before a bid that includes an ML function
- Delivery
- Mostly remote, on-site as needed
Scope
Two doors, one question: what does this do to my evidence?
AI is entering regulated engineering from two directions at once: as a productivity tool inside the lifecycle, and as airborne functionality that must itself be certified. For the first, we help teams adopt AI-assisted engineering where it genuinely helps, requirements analysis, traceability upkeep, review preparation, test generation, while keeping every certification claim traceable to a qualified, reviewable source. The honest architecture is "AI proposes, a qualified person disposes": a non-deterministic tool has no plausible DO-330 qualification path today, so the review that earns the objective stays human.
For machine-learning functions bound for the aircraft, we advise on certification readiness under the emerging guidance, the SAE G-34 / EUROCAE WG-114 work and the positions taken by the authorities, with the same discipline we apply to DO-178C: understand what evidence will be asked for, plan for it early, and never claim more than the current guidance supports.
Deliverables
Evidence you can show, whichever door you came through.
| Document | What it is | Door |
|---|---|---|
| AI-use policy | Which lifecycle activities may use AI, under which controls, and the answer when a delegate asks "was any of this AI-generated?" | Lifecycle |
| Evidence-chain review | Where AI output enters the evidence and where a qualified review re-establishes credit | Lifecycle |
| Tool strategy | Per tool: productivity aid below the evidence line, or a qualification obligation it cannot meet | Lifecycle |
| Readiness assessment | The ML function against the EASA Concept Paper's objectives and the ED-324 draft direction | Product |
| Operating domain | The operating design domain characterised, written down and argued, so "complete" data means something | Product |
| Data plan | The data set as a certification artifact: provenance, coverage of the domain, labelling, versioning, defects | Product |
The W-shaped process
Learning assurance restructures the V.
For a learned function, the data set carries the requirement, so the lifecycle gains a second descent and ascent.
- 01 Requirements and domain System requirements and the operating domain the function claims to work in.
- 02 Data management Data collected, labelled, versioned and shown to cover the domain.
- 03 Learning process Training managed as a process with controlled inputs, not an experiment.
- 04 Trained-model verification The model's performance on data it has not seen, argued statistically.
- 05 Implementation and inference verification The inference engine, conventional and certifiable, verified against the trained model.
- 06 Integration The learned core inside a conventional envelope that owns the worst case.
What transfers from DO-178C
Four answers, from fully to not at all.
- Planning, CM, problem reporting Transfers fully; standard-agnostic, and needed more here, not less.
- Requirements-based verification Transfers partially; the system-level requirements still apply, the model's internal behaviour is not specified by them.
- Traceability Reframed; traces now run to and through data sets, not only to code.
- Structural coverage and modified condition/decision coverage (MC/DC) No analogue; the artifact was never hand-written, so there is nothing equivalent to have covered.
Field notes