The U.S. Air Force's updated Airworthiness (AW) risk guidance opens a door. Because a MIL-HDBK-516 non-compliance is now weighed by its actual flight-safety consequence rather than treated as a risk on its face, programs that think about architecture early can meaningfully reduce what they have to certify and carry as AW risk. There is some immediate relief in the change — but the larger, more durable prize is using it to shape the architecture from the start of a program, where the savings compound.
For the system integrator, that can translate into actual cost avoided: less software forced to the highest assurance level, fewer non-compliances that rise to formal AW risks, and reusable evidence that narrows the safety case. The safety-critical foundation still earns its assurance the usual way — and that is exactly what unlocks the savings everywhere above it.
What The Air Force Changed
The memo restates the DoDI 5030.61 definition of airworthiness — the property of an air-system configuration to safely attain, sustain, and complete flight within approved usage limits — and makes that definition the test. AnA non-compliance with an applicable MIL-HDBK-516 criterion still indicates a potential hazard, but an assessment is required to determine if it results in an AW hazard. A compliance gap is no longer the end of the analysis; the credible flight-safety consequence is.
In practice, the interim guidance lets programs track only Catastrophic and Critical hazards as AW hazards; exclude the cost of damaged or malfunctioning mission systems and other equipment from the consequence determination; and treat hazards below 10⁻⁷ per flight hour, or qualitatively "very unlikely," as not producing an AW risk. Where it conflicts with AWB-150B, the memo takes precedence while the bulletin is updated.
The Bigger Opportunity: Decide The Architecture Early
It helps to be clear about what the memo does and does not touch. What stays the same are the DO-178C objectives, the applicable MIL-HDBK-516 criteria, and the assurance evidence for any component the aircraft's safety depends on. What changes is everything built around that foundation? Far from a limitation, that is the lever: when the trusted foundation is strong, the integrator can be lighter everywhere else.
And this is where timing matters. Containment that is designed in at architecture definition is scope the integrator never has to argue about later — and cost never incurred. Retrofitting isolation into a tightly coupled design after the fact is where programs lose time and money. The guidance rewards the teams that make the architecture decision first.
The earlier a program commits to a strong separation architecture, the more of the system it can keep out of the highest-assurance, highest-cost domain — and the fewer non-compliances that ever-become AW risks to assess and accept.
The Mechanism: Partitioning That Shrinks Certification Scope
This is not a new certification idea; the guidance simply makes it more valuable. Under DO-178C, a software level (DAL A–E) is driven by the severity of the failure condition the software can contribute to. When functions of different criticality share resources without robust partitioning, the lower-criticality software has to be raised toward the highest level of any function it could affect — because nothing bounds its influence. Every level of rigor applied to software that did not truly need it is a non-recurring cost.
Robust partitioning changes that. Spatial and temporal isolation with demonstrated freedom from interference — the properties a separation kernel and ARINC 653 provide — let each partition be developed and assured to its own level, provided the partitioning mechanism itself is assured to the highest level it protects. Every partition you can keep at a lower level is verification effort, and cost; you do not have to spend at DAL A.
The updated guidance adds a second of opportunity to the first. DAL decomposition limits how much software must be built to the highest level. Consequence filtering means that even a residual non-compliance, if the architecture shows it cannot yield a Catastrophic or Critical flight-safety consequence, need not be carried as an AW risk. Chosen early, the two compounds — and both rest on rigorous assurance of the foundation, which is where the investment belongs.
Architecture Breaks The Causal Chain
A modern military platform layers flight-critical software, Linux, mission and AI workloads, networking, and third-party components — often on shared compute. In a tightly coupled design, a defect in one component forces the program to reason whether it can reach everything else, dragging a broad slice of the platform into the Airworthiness argument. A high-assurance separation layer changes the shape of that argument.
Worked example. A Linux-hosted mission or AI workload hits a resource-exhaustion condition or an errant DMA transaction. On an undifferentiated stack sharing compute with flight-critical software, the integrator must consider whether that fault can starve, delay, or corrupt the flight-critical function — pulling much of the platform into the AW case. Over LynxSecure, the same fault is confined to its partition: spatial and temporal isolation and device/DMA mediation keep it from touching the flight-critical partition's memory, timing, or I/O. The failure is real and still gets managed — but the causal chain to a Catastrophic or Critical flight-safety consequence is broken. Designed in from the start, that containment is scope the integrator never has to argue, and cost it never incurs.
The question the integrator gets to ask shifts from "Can every component meet the highest assurance level?" to "Can a lower-assurance component fail without crossing the trusted boundary and creating a Critical or Catastrophic flight-safety consequence?" Strong separation evidence is what answers it — and answers it more cheaply the earlier it is built in.
How The Guidance Rewards An Architecture-First Approach
Each change in the memo lines up with a specific property of a separation architecture — most of all when it is chosen early:
What It Means For The System Integrator
The payoff is a more focused, and less expensive, problem. Instead of treating every technical gap as something that requires AW risk acceptance, the questions become targeted: What is the actual failure of consequence? Can it escape its partition? Can it affect a safety-critical service, or the timing and resources of flight-critical functions depend on? Can it reach an unauthorized device or corrupt safety-critical memory or communications? When strong separation evidence answers those questions, the scope of the Airworthiness problem narrows — the non-compliance may still be documented and managed, but it no longer automatically becomes a formal AW risk to carry.
For the infrastructure supplier, the message is complementary: the assurance of a trusted product is not something to reduce — it is what the integrator relies on to keep failures from crossing safety boundaries. Built rigorously, verified, configuration-controlled, and documented with its assumptions and limitations, that foundation is the thing that makes everyone else's savings possible.
Let us look at it early. Talk to the Lynx team — ideally at architecture definition — about using MOSA.ic and the LynxSecure separation kernel to design out certification scope and Airworthiness risk before they are baked in, along with the separation and assurance evidence that supports the case.
