Locate the approval before judging it
When an autonomous-aircraft announcement cites an aviation software standard, it can sound like a verdict on the whole machine. The citation deserves attention, but its scope needs to be established. Is the statement about a development process, a particular software item, an installation or an aircraft approval? Those descriptions should not be silently exchanged.
Civil aviation provides a useful analogy. FAA Advisory Circular 20-115D recognizes an acceptable route for showing compliance for the software aspects of airborne systems and equipment in type certification or technical standard order authorization. The circular is guidance, not itself a regulation. We use this civil framework to understand evidence boundaries; we are not asserting that it governs a particular military aircraft.
Assurance concerns a defined engineering claim
RTCA describes DO-178C as addressing design and product assurance for airborne software. It also publishes supplements addressing particular development approaches, including model-based development and formal methods. The presence of a familiar document number therefore does not remove the need to identify the software, its intended role and the basis of the claimed acceptance.
The FAA circular ties software assurance levels to failure-condition severity through the system safety process. Our reading is that the surrounding aircraft context matters: the significance of a software function depends partly on what follows if it behaves incorrectly. A supplier's statement that it follows a standard is useful background. Evidence of an authority's acceptance for a stated application is a different, more specific claim.
Learning introduces another evidence question
The FAA's 2024 AI safety-assurance roadmap distinguishes a learned system, whose resulting algorithm remains under designer control, from a learning system that adapts in its operating environment. The roadmap treats their safety-assurance implications separately. It is a dated strategy document, not a blanket approval of either approach or a statement about an unnamed aircraft.
EASA's March 2024 AI concept paper likewise discusses learning assurance and explainability. Its published scope covers applications enhancing human capabilities and systems making decisions under human oversight. These sources illustrate why a claim about conventional software development cannot, by itself, answer every question about a learned model. Our follow-up would be: which model behavior was assessed, for which inputs and conditions, and with what stated limits?
An update is part of the assurance story
FAA AC 00-69 offers public best-practice information on software change-impact analysis. Its examples extend beyond edited code to hardware interfaces, development tools, configuration data and software requirements. It also calls attention to effects beyond the life-cycle information directly modified. This is complementary best-practice information, not a universal rule that every change requires the same amount of work.
For reporting purposes, that makes version information valuable. A result obtained for one configuration should not become an undated quality label attached to every later release. If a developer announces a substantial update, we would ask what was reassessed and what earlier evidence remains applicable. The answer may be reassuring. The announcement alone cannot supply it.
Read the boundary as useful information
Our practical interpretation is to read software assurance as a structured contribution to a wider safety argument. It can explain why confidence in specified software behavior is justified. It does not establish, merely through a standard's name, every property of the aircraft, the suitability of every operating environment or the authorization of every use.
A stronger article would name the approving authority when applicable, distinguish a developer's assertion from an approval, identify the software configuration and state the function covered. Where the public record supplies only a standard reference, that is what we should report. This avoids both dismissing difficult assurance work as paperwork and inflating a bounded engineering achievement into a universal certificate of autonomous judgment.
An explanatory civil-aviation analogy reviewed 26 September 2026, not certification advice or a military compliance assessment. FAA circulars and the 2024 roadmap were publicly accessible. DO-178C's paid full text was not consulted; RTCA's public summary and FAA guidance support only the claims stated here. The EASA source is the dated March 2024 concept paper, not a claim that its guidance is the latest complete regulatory framework. Clarification, 8 October 2026: AC 00-69 is described as complementary best-practice information, matching its stated purpose.
Read the evidence.
- 01AC 20-115D: Airborne Software Development AssuranceFederal Aviation Administration · 21 Jul 2017
- 02
- 03Roadmap for Artificial Intelligence Safety Assurance, Version IFederal Aviation Administration · 23 Jul 2024
- 04Artificial Intelligence Concept Paper Issue 2: Guidance for Level 1 and 2 Machine-Learning ApplicationsEuropean Union Aviation Safety Agency · 6 Mar 2024
- 05AC 00-69: Best Practices for Airborne Software Development AssuranceFederal Aviation Administration · 21 Jul 2017