Hermeus: Engineering Mach 5 Aircraft with Digital-First Methods

What Hypersonic Development Actually Cost Before

The last time the United States developed a production-intent aircraft capable of sustained Mach 5 flight, it took roughly two decades and a classified budget. The SR-71 program ran from the late 1950s through its first operational flight in 1966, and even that vehicle—extraordinary as it remains—operated at the lower edge of what aerothermodynamics defines as hypersonic. True Mach 5+ sustained flight is a different category of problem. Materials behave differently. Propulsion physics change fundamentally. The systems integration challenges compound faster than the Mach number suggests.

Hermeus, founded in 2018 and headquartered in Atlanta, is attempting to compress that timeline by an order of magnitude. Their stated goal is a Mach 5 passenger aircraft, with a defense variant—Quarterhorse, now succeeded by the Darkhorse program—as the near-term development vehicle. Their approach is not primarily aerodynamic innovation or materials science breakthrough, though both are involved. The distinguishing characteristic of the Hermeus engineering model is organizational and methodological: they are building a digital-first development organization and betting that compressed iteration cycles, run in parallel with hardware campaigns, can do in years what the aerospace primes have done in decades.

Whether that bet pays off is an open question. What is already clear is that the engineering challenges they are navigating are among the most complex in the industry.

The TBCC Problem

The Hermeus propulsion architecture is called turbine-based combined cycle, or TBCC. The concept is not new—DARPA and the Air Force Research Laboratory have studied it for decades—but nobody has built a TBCC system that flies at production scale.

The basic principle: at low speeds, a modified gas turbine engine provides thrust. At approximately Mach 3 to Mach 3.5, the vehicle transitions to a ramjet or scramjet mode, where the engine’s compressor is bypassed and incoming air is compressed by the vehicle’s forward speed alone. The turbine must survive that transition without being destroyed by the thermal and pressure environment the ramjet mode creates.

The transition point is the single most dangerous moment in the flight envelope. At Mach 3+, incoming air stagnation temperatures approach or exceed the tolerance limits of turbine inlet components designed for subsonic or low-supersonic operation. The bypass duct must open. The turbine must be protected or allowed to spool down in a controlled fashion. The vehicle must maintain thrust continuity through the mode change, or it loses speed, which means it cannot sustain the ram pressure it needs, which means it cannot complete the transition.

This is not a problem you can solve in a simulation alone. The fluid-thermal-structural interactions during transition involve boundary conditions that are difficult to model with confidence. Wind tunnels cannot perfectly replicate the combined effect of real air chemistry at altitude, thermal soak, and the specific inlet geometry of a production vehicle. Ground test facilities can approximate, but flight is the only truth.

Hermeus’s approach to this problem has been to build incrementally. The Quarterhorse program used a modified GE J85 engine as the turbine core and demonstrated low-speed flight operations. Darkhorse extends the performance envelope. Each vehicle is instrumented heavily, and the data feeds back into the models that drive the next design iteration. The cycle is fast by aerospace standards—not because individual tests move faster, but because the organization is structured to extract learning from each test and act on it immediately.

The Thermal-Structural-Propulsion Integration Problem

Hypersonic flight generates aerodynamic heating that is qualitatively different from supersonic flight. At Mach 5, stagnation temperatures on leading edges exceed 1,000°C. Titanium, which handles the SR-71 envelope reasonably well, begins to lose structural integrity in the most exposed locations. The vehicle skin must either be actively cooled, made from exotic high-temperature alloys or composites, or designed with enough standoff mass to act as a thermal buffer for the flight duration.

Each of those choices propagates consequences. Active cooling means plumbing, pumps, and a thermal management system that adds weight, complexity, and failure modes. High-temperature materials—silicon carbide composites, carbon-carbon structures, refractory metal alloys—are expensive to manufacture, difficult to inspect, and have failure modes that are different from conventional metallic structures. Thermal buffering adds mass that reduces payload fraction and changes the vehicle’s inertial characteristics in ways that affect controllability.

None of these domains—thermal, structural, propulsion—can be optimized independently. The choice of leading edge material affects the aerodynamic shaping that affects inlet performance that affects the mode transition that affects the thermal load that drove the material choice in the first place. This is a coupled design problem of high dimensionality.

For a traditional aerospace prime, the standard response to this coupling is organizational: create functional teams for structures, propulsion, and thermal, and manage interfaces through formal requirements. The requirements are documented. The interface control documents define what one subsystem must deliver to the next. The process works, but it is slow, because every time a parameter changes in one domain, the interface documents must be revised, reviewed, and approved before the downstream teams can act on the new constraint.

Hermeus’s digital-first model is an attempt to make that coupling computationally explicit rather than organizationally managed. The goal is not to eliminate requirements—hypersonic development without rigorous requirements is not a shortcut, it is a crash—but to make the requirements live in a shared model that updates as the design evolves, rather than in documents that lag the design by weeks.

Requirements Management at the Domain Boundary

The systems engineering challenge that defines Hermeus’s toolchain decisions is this: how do you maintain traceability across requirements that are stated in different physical languages?

A propulsion requirement might read: inlet total pressure recovery shall exceed 0.85 at Mach 3.5 at the transition initiation point. A structural requirement might read: leading edge temperature shall not exceed 850°C during sustained Mach 4.5 cruise. A thermal management requirement might read: coolant flow rate shall be sufficient to maintain inlet lip temperature below 700°C during a 30-minute design mission.

These three requirements are deeply coupled. The inlet geometry that achieves the pressure recovery requirement affects the leading edge geometry that determines the thermal load that determines whether the temperature requirement is met. But they are written by different engineers in different languages—aerodynamicists, structural analysts, thermodynamicists—and historically managed in separate requirement trees that connect only at formal review gates.

The companies that have built requirements management infrastructure for aerospace programs—IBM DOORS and DOORS Next, Jama Connect, Polarion, Codebeamer, Innoslate—all handle this problem differently, and all with meaningful limitations in the hypersonic context. DOORS, which remains the dominant tool in defense programs by installed base, has deep organizational penetration at Air Force primes. Its strength is auditability and its weakness is exactly this: it is a document-oriented system, and documents do not capture the parametric relationships between requirements in a hypersonic design space. You can link a propulsion requirement to a structural requirement in DOORS, but the link is a text pointer, not a computational relationship.

Jama Connect and Codebeamer handle this better from a collaboration and traceability standpoint, but they are still primarily document-and-text systems extended with connectivity features. They are the right tools for many aerospace programs—mature platforms with complex supplier chains and regulatory traceability demands where the document paradigm aligns with contractual reality.

For a small, vertically integrated team moving fast through a highly coupled design space, tools like Flow Engineering represent a different model. Flow Engineering, built specifically for hardware and systems engineering teams, treats requirements as nodes in a graph rather than lines in a document. Relationships between requirements—including parametric dependencies, not just traces—are first-class objects in the data model. That matters when your thermal, structural, and propulsion requirements are not just related by compliance but are actively co-constrained by the physics of the vehicle. Whether Hermeus specifically uses Flow Engineering is not publicly documented, but the problem their engineering model faces is precisely the one that graph-based, AI-assisted requirements tools are designed to address.

The AFRL Partnership: A Configuration Without Clean Precedent

Hermeus’s relationship with the Air Force Research Laboratory and the broader Air Force customer is unusual in defense acquisition history. AFRL is simultaneously a technology development partner—funding early-stage vehicle programs, providing test infrastructure, sharing research data—and a potential customer for operational systems. The Air Force, through organizations like AFWERX and the Rapid Capabilities Office, has supported Hermeus with OTAs (Other Transaction Authority agreements) that move faster than traditional FAR-based contracts.

This matters for systems engineering because the requirements that drive a development vehicle are not the same as the requirements that will drive an operational system. Darkhorse is a technology demonstrator with Air Force funding, but the eventual operational system—if it reaches that stage—will need to satisfy a much more complete set of operational, maintenance, reliability, and support requirements that have not been fully defined yet.

The typical defense acquisition path would define operational requirements first, then develop technology. Hermeus is running that in reverse: develop the technology first, prove the performance envelope, and define the full operational requirements once the performance space is understood. This is not an unusual model for high-risk technology programs—it is essentially the approach DARPA uses—but it creates a requirements management challenge that is qualitatively different from a traditional program.

The requirements baseline is intentionally incomplete. The traceability structure needs to accommodate requirements that are partially defined, under negotiation, or known to be placeholders pending flight test data. Traditional requirements tools, built around the assumption that requirements are specified before design begins, handle this poorly. It requires a toolchain that can represent requirements maturity, flag assumptions explicitly, and propagate uncertainty through the requirement tree when assumptions change.

What’s Actually Happening vs. the Hype

Hermeus generates significant press coverage, much of it focused on the Mach 5 passenger aircraft vision: London to New York in 90 minutes. That framing is not dishonest, but it compresses decades of development into a marketing slide. The near-term reality is more grounded.

What Hermeus has actually demonstrated: a TBCC engine operating on the ground, low-speed flight of the Quarterhorse vehicle, and an organizational model capable of designing, building, and flying hardware on timescales that traditional defense contractors cannot match. These are real accomplishments. The organizational capability is arguably more valuable than any specific hardware result, because it is the capability that enables the iteration the program requires.

What remains undemonstrated: the mode transition at Mach 3+, sustained Mach 5 flight, thermal management at the full performance point, and vehicle controllability in the high-dynamic-pressure portion of the envelope. These are the hard parts. They are also the parts for which there is no substitute for flight data. No simulation, however high-fidelity, resolves the uncertainty in the TBCC transition dynamics with the confidence a production program requires.

The honest assessment is that Hermeus is exactly where a well-run high-risk technology development program should be at this stage: they have demonstrated the organizational model, they have demonstrated some key components, and they are approaching the first tests that will actually tell them whether the core technical concept works as predicted. That is a genuinely good position. It is also a long way from a certified aircraft.

Practical Implications for the Industry

The Hermeus model, if it succeeds, has implications beyond hypersonic development. The combination of small teams, compressed iteration cycles, digital-first toolchains, and government partnership structures that align incentives toward technical progress rather than compliance is a template that other high-risk aerospace development efforts are watching carefully.

The systems engineering implication is specific: the traditional model of requirements-first, design-second, test-last breaks down when the design space is fundamentally uncertain and the requirements cannot be fully specified without test data. Programs operating in that regime—hypersonic vehicles, next-generation nuclear systems, novel spacecraft architectures—need requirements toolchains that are built for living baselines, not frozen documents. The industry is still in the early stages of building those tools, and the programs that will drive their development are programs exactly like Hermeus.

What Hermeus builds in the next three to five years will be technically interesting regardless of whether the Mach 5 passenger aircraft becomes a commercial product. The data from Darkhorse flight tests, the validated models of TBCC mode transition, and the organizational methods that compressed the development cycle are valuable outputs independent of the end system. AFRL understands this. The Air Force is not funding Hermeus because they expect a passenger aircraft. They are funding it because the underlying technology and methods have operational value, and the fastest way to develop that value is to let a small team run fast.

That is a bet the aerospace establishment has been slow to make. Hermeus is the test case.