The Hidden Systems Engineering Crisis in Defense Hypersonics Programs

When the Army’s Long-Range Hypersonic Weapon (LRHW) slipped its initial delivery schedule, and when the Air Force’s AGM-183A Air-Launched Rapid Response Weapon (ARRW) failed its first three boost-glide flight tests before eventual program cancellation in 2023, the public narrative centered on the physics. Hypersonic flight is hard. Sustained Mach 5+ flight through the atmosphere creates thermal environments that destroy materials, plasma sheaths that break communications, and guidance challenges that strain the limits of inertial navigation. All of that is true.

What the public narrative missed — and what repeated GAO assessments have documented in careful, bureaucratic language — is that the physics was not the primary failure mode. The primary failure mode was systems engineering. Specifically: how requirements were written, how they propagated across disciplines and contractor boundaries, how they were verified, and how they were managed when the inevitable surprises in a frontier technology program forced changes.

This is a story about documents that couldn’t keep up with discoveries, about interfaces specified before the physics was understood, and about verification plans built on top of requirements that were never stable enough to verify against. It is also a story about what a small number of programs are doing differently — and what those practices reveal about what modern systems engineering for high-TRL, high-risk defense programs actually requires.

What the GAO Has Actually Been Saying

The Government Accountability Office publishes an annual assessment of major defense acquisition programs. Reading the hypersonics sections across the 2021, 2022, 2023, and 2024 editions reveals a consistent pattern that deserves to be named plainly.

The 2022 GAO Hypersonics report (Hypersonic Weapons: DOD Should Apply Leading Practices to Acquisition of Demonstrators) identified that most U.S. hypersonic programs entered System Development and Demonstration without completing foundational knowledge that best practices say should precede that milestone. Specifically, it called out that requirements were being baselined before the technology knowledge needed to write defensible requirements had been established.

This is the central contradiction in the management of frontier technology programs. Program offices face congressional pressure to demonstrate progress. Progress is measured in acquisition milestones. Milestones require baselined requirements. So requirements get baselined. Then the test program generates data that contradicts the baseline. The program is now in the position of managing a delta between the contractual reality (the baselined requirements document) and the engineering reality (what the physics actually requires).

In classical DOORS-based requirements management, this delta is handled through a formal change control process. An engineer identifies the discrepancy, files an Engineering Change Proposal, a board reviews it, and the document is updated. In a mature, well-understood technology domain, this works. The changes are bounded and infrequent.

In a hypersonics program, changes are not bounded and not infrequent. The 2023 GAO assessment of HAWC (Hypersonic Air-breathing Weapon Concept) noted that interdependency between subsystem requirements made change control an amplification mechanism rather than a stabilization mechanism. A change to an aerothermal requirement didn’t require updating one document section — it required cascading updates across propulsion interfaces, thermal protection system margins, guidance & control assumptions, and structural loads. In a document-centric system, each of those updates required its own change request, its own review, its own version. The change control process was consuming engineering bandwidth that should have been directed at solving the technical problems.

The Multidisciplinary Coupling Problem

To understand why hypersonics is uniquely hostile to conventional requirements management, it helps to be specific about the physics.

In a conventional missile or aircraft, the major engineering disciplines — aerodynamics, propulsion, structures, guidance — interact, but the interactions are relatively weak and well-characterized. You can specify an interface between the aerodynamics group and the structures group, hold that interface reasonably stable, and have both groups work in parallel without constant re-negotiation.

In a hypersonic glide vehicle or scramjet-powered cruise missile, the coupling between disciplines is tight and nonlinear. The aerodynamic shape determines the thermal environment. The thermal environment determines what materials are feasible for the outer mold line. The feasible materials have different emissivity profiles, which changes the thermal environment. The thermal environment affects the structural margins. The structural margins determine how much the vehicle can flex. Flex changes the aerodynamic shape. That changed shape feeds back into the thermal environment.

This is not a simplified description. This is the actual engineering loop that programs work through, and it means that a requirement written for the thermal protection system cannot be cleanly separated from a requirement written for aerodynamic performance. They are coupled. A change to one is implicitly a change to the other.

Requirements documents — even very good ones — are linear artifacts. They have sections, and the sections have numbers, and the numbers create the illusion of separability. When the engineering domain is not separable, the document structure is not just inconvenient — it is actively misleading. Engineers reading siloed sections of a requirements document for a hypersonic system may not realize that the requirements they are working against are already inconsistent with requirements being worked in a different section by a different team.

The ARRW post-mortem analysis, while never officially published in a single government document, can be reconstructed from program office statements, Congressional testimony, and contract modification records. The pattern that emerges is consistent with what systems engineers working on the program have described in open forums: guidance and control requirements were written against an assumed vehicle state that the vehicle never actually achieved. The requirements were not wrong in isolation — they were wrong relative to the as-built aerothermal performance. And the traceability chain that should have connected those requirements did not exist in a form that would have surfaced the inconsistency before the first flight test.

What the Programs That Are Working Are Doing Differently

Not all hypersonics programs are in crisis. The Conventional Prompt Strike (CPS) program, jointly developed by the Navy and Army, has moved more steadily toward fielding than most of its contemporaries. HAWC, despite schedule challenges, produced meaningful flight test successes. The Hypersonic Attack Cruise Missile (HACM), being developed by Raytheon under an Air Force contract, has maintained a more disciplined requirements posture than ARRW did.

The common thread across programs that are managing better is not that they have better requirements documents. It is that they are treating requirements as connected, living engineering data rather than as contractual text.

In practical terms, this means several things.

Model-based interfaces, not text-based interfaces. Programs that are managing well have invested in interface control documents that are generated from or synchronized with simulation models. When the thermal analysis updates, the interface control document updates. The requirement text is a representation of the model state, not a standalone artifact. This matters because it means the cascade effects of a change are visible and computable, not hidden in a web of document cross-references that no one person has reviewed in its entirety.

Explicit traceability to physical constraints. The best programs maintain explicit links between requirements and the physical phenomena that motivate them. A requirement on thermal protection system surface temperature is not just a number — it is a number with a trace to the aerothermal analysis that produced it, and metadata indicating the confidence level of that analysis and the test data that supports it. When new test data comes in, the program office can immediately identify which requirements are built on analyses that are now superseded.

Verification planning as a first-class engineering activity. In programs that are struggling, verification planning is treated as a documentation activity that follows requirements writing. In programs that are succeeding, it is treated as a constraint on requirements writing. If you cannot describe how you will verify a requirement — what test article, what facility, what measurement, what acceptance criteria — that is a signal that the requirement is not written at the right level of maturity to be baselined. This sounds obvious. It is practiced far less often than it sounds.

Cross-domain review structures. The programs making the most progress have established formal review mechanisms where requirements changes are reviewed by representatives from all affected disciplines simultaneously, not sequentially. Sequential review in a tightly coupled system means that by the time the last discipline signs off, the first discipline’s conditions may have changed. Simultaneous review surfaces coupling conflicts in real time.

The Government-Contractor Boundary Problem

One of the factors that makes hypersonics requirements management specifically difficult — and that doesn’t receive enough analytical attention — is the government-contractor boundary itself.

Defense hypersonics programs are typically structured with a government program office that owns the system-level requirements and a prime contractor (or multiple contractors in competitive demonstrator programs) that owns the subsystem requirements. The interface between those two requirement levels is a contractual artifact as much as an engineering artifact.

When the physics requires a change to a subsystem requirement, the prime contractor can implement that change internally. When it requires a change to a system-level requirement owned by the government, the process is slower, more formal, and more expensive. This creates an incentive structure where prime contractors attempt to solve problems within their subsystem requirements space rather than surfacing them to the government as system-level issues. Problems that should be managed at the system level get temporarily masked at the subsystem level. They tend to resurface at integration and test, where they are much more expensive to resolve.

The fix is not primarily a technical fix — it is a data-sharing and tooling fix. When government program offices and prime contractors are working in different requirements management systems with no automated synchronization, the government cannot see the state of contractor requirements in real time. By the time a formal data delivery brings the requirements data to the government side, the information may already be months old. In a fast-moving test program, that latency is not acceptable.

What Modern Tooling Can and Cannot Fix

It would be convenient to conclude that adopting a modern requirements management platform solves the problems described above. That is not quite right, but it is closer to right than the defense acquisition community has generally been willing to acknowledge.

The structural problems — requirements being baselined before technology knowledge is sufficient, government-contractor data separation, verification planning treated as documentation rather than engineering — are process and culture problems. A tool cannot fix a process that the organization is not committed to following.

What modern graph-based, AI-native requirements tools can fix is the mechanical burden that makes good process impractical. When managing requirements in a tool like IBM DOORS or even DOORS Next, the effort required to maintain consistent traceability across a large, coupled requirement set is genuinely prohibitive. Engineers who understand that they should trace a changed thermal protection requirement to every dependent requirement will often not do it completely, because the tool makes it slow and error-prone. The gap between knowing what good practice requires and being able to execute it at scale is a tool gap.

Tools like Flow Engineering, which are built on a graph data model rather than a document model, make the coupling between requirements a first-class data structure rather than something that has to be manually maintained through cross-references. When a requirement changes, the graph immediately surfaces everything connected to it. Impact analysis, which in a document-based system might require days of manual tracing across multiple documents, becomes a query. That matters practically — it means engineers can explore “what breaks if I change this requirement?” in real time during a design review, rather than scheduling a separate analysis activity that competes for bandwidth with the actual engineering work.

Flow Engineering’s specific fit for defense hypersonics is its treatment of requirements as nodes in a connected model where relationships carry semantic meaning — not just “A traces to B” but “A is constrained by B” or “A is verified by C under these conditions.” That semantic richness is what makes cascade analysis meaningful rather than just a list of linked items to review.

The tool is not a substitute for the human judgment required to write requirements at the right level of maturity, connect them to the right physical constraints, or structure a verification program appropriately. No tool is. But removing the mechanical barriers to good practice changes the economics of doing it, and in programs where engineering bandwidth is the scarcest resource, that matters.

What Transfers to Other Programs

The failures and partial successes in hypersonics requirements management are not unique to hypersonics. They are most visible in hypersonics because the stakes are high, the physics is unforgiving, and the government has published enough assessment data to reconstruct what happened. But the same dynamics appear in any program working at the edge of technology readiness: advanced directed energy systems, high-powered microwave weapons, autonomous undersea vehicles, next-generation space launch systems.

The transferable lessons are specific.

Requirements written against technology that is not yet understood are not engineering constraints — they are aspirational targets dressed in engineering language. Treating them as contractual baselines before the supporting knowledge exists creates a structural debt that will be paid at integration and test.

In tightly coupled physical systems, the unit of requirements management is not the individual requirement — it is the requirement and all of its dependencies. Any process or tool that allows engineers to manage requirements in isolation is hiding the complexity of the system rather than managing it.

Verification planning is not a late-stage activity. It is a continuous check on whether requirements are written at an appropriate level of specificity and against a sufficient knowledge base to be verifiable. If it cannot be verified with available or reasonably projected means, it is not a requirement that should be baselined.

And government-contractor data separation in requirements management is a programmatic risk, not an administrative preference. Programs that want to avoid late-program surprises need shared situational awareness of requirements state across the organizational boundary, updated in something closer to real time than formal data delivery cycles allow.

The hypersonics crisis is real, and it will not be resolved by better physics. The physics is being solved, methodically and expensively, by talented engineers in government labs, prime contractors, and university programs across the country. What is not being solved at the same pace is the organizational and tooling infrastructure for managing what those engineers learn as it becomes requirements — and for keeping those requirements connected, consistent, and verifiable as the knowledge evolves.

That is the crisis, and it is one the defense systems engineering community has the tools to address.