Engineering at Mach 5: What Hermeus Is Demanding from Systems Engineering

Hermeus wants to fly passengers from New York to London in 90 minutes. That ambition sits at the intersection of genuine technical possibility and some of the most brutal engineering constraints in aerospace. The Atlanta-based company is pursuing hypersonic flight — Mach 5 and above — through a staged demonstrator program, with the Quarterhorse unmanned aircraft as the near-term milestone and the Halcyon passenger concept as the long-range goal.

The company has moved quickly by aerospace standards. Quarterhorse is built around a turbine-based combined cycle (TBCC) engine — a propulsion architecture that uses a modified jet engine at low speeds and transitions to a ramjet mode at high Mach numbers. Getting that transition right, at the right altitude, under thermal loads that would destroy conventional aluminum structure, is the central engineering challenge. It is also a systems engineering problem of a kind that existing tooling handles poorly.

What Hypersonic Development Actually Requires

Subsonic and even supersonic aircraft are designed against well-understood flight envelopes. There is decades of test data, validated simulation models, and a community of engineers who have seen these problems before. Requirements written for a commercial transport or a fighter jet are grounded in heritage — prior programs that established what works, what margins are needed, and where the models can be trusted.

Hypersonic development has almost none of that. The number of aircraft that have flown sustained, powered hypersonic flight in a recoverable configuration is very small. The SR-71 flew fast but not at Mach 5+. The X-51A flew briefly and was not recovered. There is no equivalent of the thousands of flight hours that inform a normal certification program.

This matters for requirements because requirements are claims about system behavior. When you write a thermal protection requirement, you are asserting that a particular surface temperature will not be exceeded under a particular flight profile. That assertion rests on aerothermal models, material property data, and assumptions about trajectory. In subsonic aerospace, most of those inputs are well-validated. In hypersonic flight, many of them carry substantial uncertainty. The models are less mature. Material behavior at sustained high temperature and high dynamic pressure is less characterized. The flight profile itself may need to shift as test data arrives.

Writing requirements that are honest about this uncertainty — and building a traceability structure that will survive when those requirements change — is a different discipline than standard aerospace requirements management.

The TBCC Problem

The turbine-based combined cycle architecture Hermeus is pursuing compounds this complexity. A TBCC system must perform as a turbine engine from takeoff through roughly Mach 3 to 4, then transition to ramjet operation for the hypersonic cruise phase. Each mode has different airflow requirements, different thermal loads, and different stability margins. The transition between modes — closing off the turbine flowpath while opening the ramjet — happens in a narrow speed range where both modes are marginal.

From a systems engineering perspective, this means a single propulsion subsystem has requirements that span radically different operating regimes, with a critical transient between them. Requirements for the turbine mode must not conflict with requirements for the ramjet mode. The transition logic must be specified tightly enough to be testable, but the test environment for full-scale TBCC transition at altitude does not exist as a ground facility. You cannot fully replicate Mach 3.5 at 80,000 feet in a test cell.

This is where the document-based requirements model — the Excel spreadsheet of shall statements, the static PDF requirement document — becomes genuinely dangerous. A shall statement that says “the propulsion system shall transition from turbine to ramjet mode within X seconds” looks complete on paper. But that requirement connects to assumptions about inlet dynamics, fuel scheduling, structural thermal state, and flight path angle. If any of those assumptions change — because a test reveals something unexpected — the requirement may need to change too, along with every downstream verification activity tied to it.

If those connections are maintained in documents rather than in a live model, finding all the affected items is a manual process. On a program with the complexity of Quarterhorse, manual is a way of missing things.

Requirements for Systems You Cannot Fully Test

The verification challenge at Mach 5 deserves specific attention because it forces a discipline that most requirements processes avoid: being explicit about what you know and what you don’t.

In conventional aerospace development, verification methods are relatively straightforward to assign. Analysis covers what testing cannot practically address. Testing covers what simulation cannot be trusted on. The methods are well-understood because the physics are well-understood.

Hypersonic development requires a more careful epistemology. When you assign “analysis” as the verification method for a thermal requirement, you are asserting that your aerothermal model is accurate enough to stand in for a test. That assertion should itself be a documented claim, with traceability to the model validation data that supports it. If the model was validated at Mach 4 and you are operating at Mach 5.5, the extrapolation is an assumption, and that assumption should be visible in the requirements structure.

Programs that manage this well tend to use what some systems engineers call assumption-backed requirements — requirements that are explicitly linked to the assumptions that make them credible, so that when test data challenges an assumption, the downstream requirements come up for review automatically rather than being discovered missing during a mishap investigation.

This is not how most requirements tools work. Most tools track requirements and trace them to tests. They do not have a native concept of an assumption node — a documented belief about system behavior that sits between a physical model and a shall statement.

What Modern Tooling Needs to Provide

The requirements challenges at Hermeus are not unique to Hermeus. Any hypersonic program faces them, as do complex space systems and autonomous platforms operating in novel environments. They represent a class of problem that the industry has been slow to address in tooling.

What these programs need from requirements tools:

Graph-based traceability, not document-based. Requirements are not isolated statements. They are nodes in a network of design decisions, assumptions, verification activities, and test results. Tools that model requirements as rows in a spreadsheet or paragraphs in a Word document make it difficult to navigate those dependencies. Tools that maintain a live graph — where you can traverse from a requirement to the assumptions it rests on, to the tests that validate those assumptions, to the design parameters it constrains — give engineers the visibility they need to manage change.

Living requirements that survive test campaigns. A hypersonic demonstrator program like Quarterhorse will produce data that invalidates some early requirements. That is not failure; that is the purpose of a demonstrator. Requirements infrastructure needs to support requirements that update as knowledge grows, with full audit trails of what changed, when, and on what basis. Static documents do not do this well.

First-principles requirement generation. When requirements are derived from physics and system models rather than copied from prior programs, there is less risk of importing inappropriate heritage. At Mach 5+, a requirement derived from supersonic heritage may be wrong not because someone made an error, but because the underlying physics are genuinely different.

Tools like Flow Engineering have been built around graph-based traceability and AI-assisted requirement generation from system models — an architecture that fits this problem class better than legacy document-based platforms. Whether such tools are deployed on hypersonic programs today is a separate question, but the architectural alignment is clear. Programs like Hermeus’s represent exactly the challenge that motivated moving away from static requirement documents toward live, connected models.

The Honest Assessment

Hermeus is attempting something genuinely hard. Turbine-based combined cycle propulsion has never been demonstrated at scale in an operational aircraft. Sustained hypersonic cruise in a recoverable, reusable vehicle is at the edge of what has been proven. The Quarterhorse program is a serious attempt to generate the flight test heritage the industry needs, and the company’s engineering team has the credentials to take it seriously.

What the Hermeus program illustrates for the broader aerospace industry is that requirements practices developed for subsonic and low-supersonic aircraft are under-specified for the hypersonic regime. The thinness of margins, the novelty of the flight environment, and the limited availability of ground test validation all push toward a requirements model that is more dynamic, more connected, and more explicit about uncertainty than most programs currently employ.

The question for any systems engineering organization facing novel operating regimes is whether their tooling and processes can handle requirements that must be written under uncertainty and revised as knowledge accumulates — or whether they are building the next program on infrastructure designed for problems they already solved.

Hermeus is forcing that question in public. That is part of what makes it worth watching.