How Hypersonic Programs Are Challenging Conventional V-Model Development

The V-model works well when you understand your physics. You decompose requirements at the top, allocate them down to subsystems, and climb back up the right side through a structured verification campaign. The underlying assumption is that by the time you write a requirement, you know enough about the operational environment to make it measurable and achievable. Hypersonic programs systematically violate that assumption.

Above Mach 5, and certainly above Mach 10, the engineering environment produces phenomena that outpace validated simulation tools by meaningful margins. Boundary layer transition on a slender body at Mach 15. Thermochemical non-equilibrium in shock layers. Ablative material response coupled to aerodynamic shaping. Real-gas effects on control surface effectiveness. These are not edge cases that can be conservatively bounded with a 20% margin. They are regime-defining behaviors that determine whether a vehicle survives its trajectory — and the models that describe them carry compounding uncertainty stacked on compounding uncertainty. When your baseline simulation is wrong in ways you cannot fully characterize, writing a precise, verifiable requirement is not a documentation problem. It is a first-principles physics problem.

The Validation Gap Is Structural, Not Temporary

Ground test infrastructure for hypersonic regimes is scarce, aging, and incomplete. The United States operates a handful of hypersonic wind tunnels capable of sustained testing above Mach 10 — facilities like the AEDC Hypervelocity Wind Tunnel 9 at White Oak and the Arnold Engineering Development Complex in Tennessee — but these cannot fully replicate the coupled thermal-structural-aerodynamic environment of free flight. A wind tunnel at Mach 12 gives you aerodynamic coefficients. It does not give you the coupled material response of a carbon-carbon leading edge absorbing 10 megawatts per square meter over 400 seconds while the vehicle flexes under aerodynamic load and the control system fights a guidance law running on radiation-hardened hardware with 50-millisecond latency.

Each of those physics domains has its own simulation community, its own validation datasets, and its own uncertainty budget. The problem is that in a real hypersonic vehicle, they are not independent. Thermal deformation changes aerodynamic coefficients. Aerodynamic heating drives material ablation. Ablation changes vehicle shape. Shape change shifts center of pressure. Center of pressure shift interacts with the guidance law. None of the domain-specific simulators were validated against the coupled regime, because the coupled regime can only be tested in flight.

This is what Lockheed Martin Skunk Works engineers working on programs like the SR-72 demonstrator concept and associated hypersonic research vehicles confront directly. The Skunk Works tradition of rapid, hardware-driven iteration exists precisely because Kelly Johnson understood that for truly novel flight regimes, the airplane teaches you things the aerodynamicists could not. But modern acquisition frameworks and cost structures make informal iteration difficult. Programs are expected to arrive at Milestone B with a stable requirements baseline. For hypersonic systems, that baseline is partly fiction — informed fiction, well-engineered fiction, but fiction nonetheless.

How Raytheon and DARPA Are Managing Requirements Under Uncertainty

Raytheon’s hypersonic programs — including work on the Hypersonic Attack Cruise Missile (HACM) and contributions to the Air-Launched Rapid Response Weapon (ARRW) program — face the requirements problem from the integration and producibility side. The challenge is not just defining performance requirements at the system level. It is allocating those requirements to components that are being developed simultaneously, by suppliers who are also operating at the edge of their simulation confidence.

The thermal protection system supplier needs a heat flux requirement from the aerodynamicist. The aerodynamicist needs an outer mold line from the structures team. The structures team needs a thermal deformation envelope from the TPS team. In a conventional sequential development process, this circularity is resolved by iteration through analysis — run the aero, hand off to structures, run thermal, loop back to aero, repeat until converged. In a hypersonic program where each analysis cycle takes weeks and the simulation tools are known to diverge from reality at the edges, that iterative loop can produce a false sense of convergence. The models agree with each other. They may not agree with the vehicle.

DARPA’s approach through programs like Hypersonic Air-breathing Weapon Concept (HAWC) and the Glide Breaker program reflects a deliberate philosophy: treat early flight tests as requirements discovery events, not verification events. This is a significant conceptual shift. In conventional V-model execution, flight tests are on the right side of the V — they confirm that you built what you designed. DARPA explicitly funds flight tests that are on the left side, or in the middle: tests where the primary output is not a compliance data point but a physics dataset that revises your understanding of what requirements were actually achievable.

This is technically sound but organizationally disruptive. Program offices that are managing cost, schedule, and contractor accountability need requirements to be stable so that change can be controlled. DARPA’s approach accepts deliberate requirements instability as the cost of operating at the frontier. The tension between those two philosophies does not disappear when a DARPA program transitions to a service acquisition program. It gets harder.

Verification Planning When Tests Are Scarce

When a ground test in a relevant facility costs several million dollars and a flight test costs anywhere from $50 million to well above $100 million depending on platform and range support, the conventional approach of building a flat requirements traceability matrix and assigning a verification method to each requirement becomes untenable. Not because the RTM is wrong in concept, but because it treats all requirements as roughly equivalent in terms of verification burden.

In a hypersonic program, they are not equivalent. A requirement for seeker electromagnetic compatibility can be verified on a bench. A requirement for terminal maneuver accuracy at Mach 10 after a 1,200-second glide phase in a thermally degraded aeroshell can be verified only in flight, and imperfectly even then. These two requirements do not belong in the same flat list with equivalent verification planning assumptions.

What programs are learning to do instead is build a risk-stratified verification architecture. Requirements are categorized not just by decomposition level but by verification achievability — specifically, by the gap between current simulation confidence and required verification confidence, weighted by the consequence of being wrong. Requirements that sit in well-validated simulation domains with high physical confidence get conventional verification plans. Requirements that sit at the edge of the validated domain, where simulation and physical reality have historically diverged, are flagged for what some program engineers call “verification under uncertainty” — a deliberately qualified compliance posture that explicitly documents what the verification evidence does and does not demonstrate.

This is not a standard feature of most legacy requirements management tools. IBM DOORS and DOORS Next handle traceability and baseline control well, and for programs with stable physics in validated domains, they remain serviceable. Jama Connect and Polarion have made genuine progress on cross-discipline linking and workflow management. But none of these tools were designed around the concept that a requirement’s verification method might change — not due to scope change, but due to physics discovery. When a flight test returns data showing that your thermal model was systematically optimistic by 18%, the downstream requirement revision is not a change request in the conventional sense. It is a requirements re-derivation event, and it affects potentially dozens of dependent requirements simultaneously.

Graph-Connected Requirements for Uncertain Domains

The structural weakness of document-based or flat-database requirements approaches in hypersonic programs is that interdependency is invisible until something breaks. A thermal requirement that was derived from an aerothermal simulation that was calibrated to ground test data from a geometry that has since been updated — that chain of derivation either exists explicitly in the requirements structure or it does not. If it does not, the revision cycle after a physics surprise is a manual archaeology project: tracing which requirements were derived from which assumptions, identifying what must change, and ensuring that the changes propagate without gaps.

Graph-based requirements models, where requirements are nodes and derivation relationships are explicit edges, make that propagation structure visible before the surprise. When the aero model updates, an engineer can immediately see which requirements were derived from that model and which verification plans assumed its outputs. That is not a minor convenience — on a program where each flight test consumes a significant fraction of the annual verification budget, knowing exactly what changed and what it touched is operationally critical.

Flow Engineering’s graph-based requirements model was designed around this kind of connected traceability. Rather than storing requirements in documents or flat databases, the platform represents every requirement, assumption, verification activity, and model reference as a node in a connected graph. When an upstream physics parameter changes — say, the aerothermal heating coefficient in the peak heating corridor — the system surfaces every downstream requirement and verification activity that carries that dependency. For hypersonic programs specifically, where physics updates mid-program are not exceptions but expected events, this kind of explicit dependency mapping changes the cost of a requirements revision from “multi-week trace analysis” to “structured propagation review.” The platform’s AI-assisted analysis layer also helps identify requirement sets that are under-constrained or that carry conflicting derivation assumptions — the kind of internal inconsistency that accumulates silently in document-based systems until a flight test makes it visible.

The Honest Assessment

Hypersonic development programs are not going to solve their requirements challenges purely through better tooling. The fundamental problem is physical: the environments are extreme, the coupling between physics domains is tight, and the experimental infrastructure to validate simulations of those coupled environments barely exists. No requirements management platform resolves thermochemical non-equilibrium uncertainty.

What better tooling can do is reduce the organizational cost of the physics uncertainty that will inevitably arrive. Programs that enter the flight test phase with clear, machine-navigable dependency maps between requirements, simulations, and verification evidence are in a fundamentally better position when a test reveals something unexpected. They can trace impact quickly, scope the revision accurately, and brief program leadership with confidence about what changed and what did not. Programs running flat RTMs in document-based tools are doing that same work manually, under time pressure, with incomplete institutional memory about why a given requirement was written the way it was.

The V-model will not disappear from hypersonic programs. Acquisition frameworks are built around it, and it provides necessary structure for program accountability. But the leading programs are learning to operate a modified version of it — one where the left side of the V is explicitly probabilistic, requirements carry derivation provenance, and the right side of the V is structured to feed physics learning back to the left. That is a harder process to manage than conventional systems engineering. It requires tools and practices that were built for uncertainty, not tools that assume the physics was settled before the program started.