Requirements Engineering at the Edge of Physics: How Hypersonic Programs Are Rewriting the Rules

When Lockheed Martin’s Skunk Works team was developing hypersonic test vehicles in the 1960s, the engineering approach was essentially empirical: build it, fly it, measure what survived, update the design. Computational tools were primitive and wind tunnel data was sparse. The gap between what engineers knew and what the vehicle would actually encounter was enormous — and everyone knew it.

Sixty years later, the gap has narrowed considerably, but it has not closed. The United States, China, and Russia are all fielding or aggressively developing hypersonic systems — boost-glide vehicles, air-breathing cruise missiles, maneuvering re-entry vehicles — and the fundamental physics challenges that plagued 1960s programs are still present, now embedded in far more complex systems with far more demanding performance requirements. The physics has not become simpler. The simulation fidelity has improved dramatically. But the delta between what high-fidelity CFD predicts and what a Mach 10 flight environment actually produces remains material — sometimes dangerously so.

The discipline that feels this gap most acutely is not aerodynamics or materials science. It is requirements engineering.

What Makes Hypersonic Requirements Structurally Different

In conventional aerospace programs — a transport aircraft, a satellite bus, even a supersonic fighter — requirements engineering operates from a foundation of reasonably well-characterized physics. Aerodynamic coefficients can be validated in wind tunnels that replicate flight conditions with acceptable fidelity. Material behavior under thermal load is well-characterized across the operating envelope. Structural margins can be computed from first principles and validated with coupon testing. The verification methods for most requirements are mature, accepted, and repeatable.

Hypersonic programs operate in a fundamentally different epistemic environment. Three specific phenomena define that difference.

Laminar-to-turbulent transition. At hypersonic speeds, the point at which boundary layer flow transitions from laminar to turbulent is not well-predicted by existing models. The difference is not cosmetic: turbulent flow produces heat transfer rates three to five times higher than laminar flow at the same Mach number and altitude. A thermal protection system designed for a laminar-dominant trajectory and then subjected to early transition will fail. The transition location is sensitive to surface roughness, angle of attack, vehicle geometry, and atmospheric density gradients — many of which vary across a real flight trajectory. Ground test facilities cannot fully replicate the combined enthalpy, pressure, and flow history of a hypersonic flight environment. Programs can characterize transition in individual test conditions, but cannot certify transition behavior across the full trajectory envelope from ground data alone.

Ablation front modeling. Carbon-carbon and UHTC (ultra-high temperature ceramic) materials used in leading edges and nosecaps undergo thermochemical ablation during hypersonic flight. The ablation process removes material at a rate that is itself a function of surface temperature, pressure, and species concentration in the boundary layer — all of which are coupled to the evolving geometry. Ablation codes can predict recession to reasonable accuracy in simplified geometries under steady conditions. In real flight, the coupled aero-thermo-structural-ablation problem is solved with assumptions that introduce meaningful uncertainty into predicted mass loss rates, shape change, and downstream thermal and aerodynamic effects. The material that exists at the end of a flight is not the material that was specified at the beginning — and the intermediate states drive the performance.

Shock-shock interactions. Hypersonic vehicles generate strong bow shocks. When external structures — pylons, fins, control surfaces, sensor windows — interrupt or intersect the primary bow shock, localized shock-shock interactions produce heating rates that can exceed 100 times the undisturbed surface heating. These interactions are sensitive to vehicle geometry, Mach number, and angle of attack in ways that current CFD tools predict with significant variance. Test data exists for canonical geometries, but production vehicle configurations produce interaction patterns that require extrapolation from available data. A requirements structure that assumes validated heating environments for all surfaces is writing checks the simulation tools cannot cash.

Writing Requirements When the Physics Is Uncertain

Conventional requirements engineering practice asks the systems engineer to decompose system-level performance requirements into unambiguous, verifiable child requirements. The implicit contract is that each requirement can be demonstrated as satisfied or not satisfied by a defined verification method against a defined verification environment. That contract breaks when the verification environment itself is uncertain.

Hypersonic programs have developed several structural adaptations to requirements that address this reality.

Probabilistic performance envelopes instead of deterministic bounds. Rather than specifying a peak heat flux of X W/cm² at a particular trajectory point, requirements are increasingly written against a probabilistic distribution of environments. The requirement becomes: the thermal protection system shall survive the 90th percentile aerothermal environment as defined by the program’s uncertainty characterization methodology, with that characterization documented and version-controlled as a program artifact. This shifts the verification question from “did the TPS survive X?” to “did the TPS survive the credible environment range, and how do we update that range as flight data becomes available?”

Requirements with explicit model dependency flags. Some programs are tagging individual requirements with their primary physics model dependencies and the current uncertainty rating of each model. A requirement on nosecap recession, for example, might carry a flag indicating that it is derived from a specific ablation code at a specific maturity level, and that the requirement should be reviewed when that code is updated or when new flight data is available. This practice makes the requirement not just a performance statement but a living artifact tied to the epistemic state of the program.

Tiered verification acceptance criteria. Where full-envelope flight testing cannot be completed before program commitment, programs are formalizing analysis-supported acceptance as a first-class verification pathway — not as a waiver, but as an intended method. The analysis-supported pathway requires demonstration that the analysis methodology has been validated against available test data, that the extrapolation from validated cases to the flight condition is bounded, and that the risk associated with the extrapolation is formally accepted by the program authority. This turns verification from a binary closure event into a structured risk acceptance process.

The Verification Gap Is Not Closing

The United States invested heavily in hypersonic ground test infrastructure in the 1960s and 1970s — facilities like AEDC’s tunnel 9 and the Air Force Research Laboratory’s arc-jet complexes. These facilities have been modernized but not fundamentally expanded in capability. The enthalpy, pressure, and total temperature conditions achievable in ground facilities do not fully replicate the combined environment of Mach 10+ flight. Arc-jet facilities replicate heating rates but not the flow field. Ballistic ranges replicate the flow field for small-scale articles but not full-scale, high-enthalpy flight.

The consequence is structural: no hypersonic program can close all of its verification requirements through ground test alone. This was true in the 1960s and it is true today. The difference is that modern programs are expected to manage this gap explicitly rather than absorbing it implicitly into schedule and design margin.

Flight test data from developmental programs — the AGM-183A ARRW flights, the HAWC demonstrators, the CPS program — are being used not primarily as system-level pass/fail demonstrations but as physics model-updating events. Each flight produces high-value data on transition location, heating rates, material recession, and vehicle dynamics that is fed back into the simulation framework, narrowing uncertainty bounds on subsequent requirements derivations. This is requirements engineering as a feedback loop, not a front-loaded activity.

The implication for program structure is significant. Requirements that are written early in a program against a large uncertainty envelope will be revised as flight data accumulates. This is not requirements instability in the pejorative sense — it is the intended operation of a requirements structure designed to accommodate known unknowns. Programs that lack the tooling to manage requirement revision traceably, to propagate changes from updated physics models to derived requirements, and to track verification status against a moving epistemic baseline will find themselves managing an opaque and brittle requirements corpus as the program matures.

How Modern Tooling Is (and Is Not) Keeping Up

Legacy requirements management tools — IBM DOORS, Polarion, even most implementations of Jama Connect — were designed for a requirements engineering paradigm where requirements are relatively stable, verification methods are well-defined in advance, and traceability is a compliance artifact rather than a live engineering tool. They handle document management well. They handle change control workflows. They handle the administrative overhead of large requirements corpora.

What they do not handle well is the dynamic, model-dependent requirements structure that hypersonic programs actually need: requirements that carry explicit uncertainty metadata, that are traceable to specific physics models and their maturity assessments, that can be queried for “what requirements are derived from the transition model and therefore need review after the latest flight data integration?” The document-centric paradigm processes requirements as text objects. Hypersonic programs need to process requirements as nodes in a graph that connects physics assumptions, derived requirements, analysis artifacts, and verification events.

Graph-based requirements tools are better suited to this structure. Platforms like Flow Engineering, which treat requirements as nodes in a connected model rather than rows in a document, allow programs to build the kind of dependency chains that hypersonic engineering actually produces — where a single uncertainty in the transition prediction model propagates through a traceable path to a set of derived thermal requirements, which drive TPS thickness allocations, which affect mass margin, which constrain trajectory design. When the physics model matures, the impact chain is visible and navigable rather than buried in document revision histories.

The AI-native capability matters here specifically because the volume of cross-linked artifacts in a hypersonic program — physics models, CFD results, test reports, requirement versions, verification status records — exceeds what any requirements management team can curate manually. Automated dependency detection, change impact analysis, and gap identification against evolving physics baselines are not productivity features; they are functional requirements for managing a hypersonic program’s requirements corpus responsibly.

What Good Requirements Practice Looks Like in This Environment

Programs that are managing the hypersonic requirements challenge effectively share several observable practices.

They define their uncertainty characterization methodology as a program-level artifact before they write performance requirements, not as a post-hoc annotation. The methodology specifies which physics phenomena are considered high-uncertainty, what models are used to characterize each, and how model updates propagate to requirements revisions.

They separate requirements into tiers by verification pathway: requirements closeable by ground test, requirements closeable by analysis-supported methods with defined validation bounds, and requirements that can only be closed by flight test. This tiering is visible in the requirements structure, not buried in the program risk register.

They treat flight test data integration as a formal requirements engineering event, with defined processes for assessing whether accumulated flight data changes the uncertainty bounds on existing requirements and triggering review where it does.

They use their requirements tooling as a live model of the program’s epistemic state, not as a document archive. Requirements that carry uncertain-physics derivations are flagged and monitored, not filed and forgotten.

Honest Assessment

Hypersonic programs are operating at the frontier of what requirements engineering as a discipline can accommodate. The tools and methods that work for commercial aviation or even conventional military aerospace programs are necessary but not sufficient for a domain where the physics are genuinely uncertain, the test infrastructure is genuinely limited, and the penalty for requirements errors is measured in vehicle loss and program failure.

The good news is that the engineering community is developing more sophisticated approaches: probabilistic requirements structures, model-dependency tracking, analysis-supported acceptance as a formal pathway, and requirements tooling that can represent the graph structure of hypersonic program knowledge. The hard news is that adoption is uneven, and many programs are still attempting to manage fundamentally dynamic, model-dependent requirements corpora with tools built for a document-centric world.

The discipline is catching up. Whether it catches up fast enough to support the pace of hypersonic development across defense programs is one of the more consequential systems engineering questions of the current decade.