Writing Requirements for an Engine That Must Be Two Things at Once
The Chimera Engine’s Turbojet-to-Ramjet Transition Exposes What Requirements Management Looks Like When the Physics Change Mid-Flight
There is a category of engineering requirement that is easy to write, nearly impossible to verify, and catastrophic to get wrong. Requirements governing the transition from one physical operating regime to another — a phase change, a mode switch, a boundary crossing — sit at the intersection of the hardest problems in systems engineering. Hermeus’ Chimera engine, which must operate as a turbojet at low speeds and transition to ramjet operation above roughly Mach 3, is a near-perfect case study in that problem.
This article is not a product review or a company profile. It is an examination of a specific technical challenge: how do you write requirements for a propulsion system that must satisfy two radically different sets of physical constraints, verify those requirements when the relevant test infrastructure barely exists, and manage the traceability between them when design decisions in one regime have non-obvious consequences in the other?
What Makes Chimera Different From Ordinary Dual-Mode Problems
Most complex systems have operational modes. A flight computer has ground mode and flight mode. A fuel system has pre-ignition and post-ignition behavior. Engineers write mode-specific requirements routinely, and while it adds complexity, the modes are typically separated cleanly in time and the requirements governing each do not directly conflict.
The Chimera engine is different in a specific, important way: the transition itself is the hard part, and the transition is not instantaneous. Between roughly Mach 2 and Mach 4, the engine is neither fully in turbojet mode nor fully in ramjet mode. The turbojet core must be operating at conditions that allow it to be bypassed and isolated without destructive compressor surge. The ramjet combustion must ignite and stabilize before the turbojet contribution drops to zero. The inlet geometry must be managing airflow that is simultaneously too fast for a conventional compressor and too slow for efficient supersonic combustion. All of this happens in a flight envelope measured in seconds, at temperatures where material behavior is non-linear and sensor response times matter enormously.
From a requirements standpoint, this means there is a regime — call it the transition band — where requirements written against turbojet physics and requirements written against ramjet physics must both be satisfied simultaneously, and where the constraints they impose can actively conflict with each other.
The Requirements Writing Problem
When an engineering team sits down to write propulsion requirements for Chimera, they are working at multiple levels of abstraction simultaneously.
At the top level, there are mission requirements: the aircraft must achieve Mach 5, it must do so within a certain time-of-flight budget, it must sustain that speed for a minimum duration. These requirements come from the vehicle-level program office and flow down to the propulsion system as derived requirements — typically something like thrust-at-altitude profiles, specific impulse targets across the flight envelope, and inlet pressure recovery bounds.
The first complication is that these top-level requirements assume the propulsion system is already in steady-state at each point in the flight envelope. They say nothing about how to get from one steady state to another. The transition region does not exist in the top-level requirement set because no one at the mission level cares how the engine works — they care that it produces thrust.
This is standard practice, and it is usually fine. In conventional propulsion, the transient between operating modes is short, well-characterized, and governed by known dynamics. The challenge with Chimera-class engines is that the transition is long enough, complex enough, and physically novel enough that it cannot be treated as a brief transient to be resolved at detailed design. It is a first-class operating condition that requires its own requirement set.
Writing those transition-band requirements demands several things that are not straightforward:
Defining regime boundaries precisely. A requirement needs to state when it applies. For Chimera, the switch from turbojet to ramjet operation is not triggered by a discrete event — it is a function of Mach number, altitude, inlet total pressure, and engine core temperature simultaneously. Writing a requirement that specifies “during turbojet-to-ramjet transition” requires first agreeing on what conditions define that envelope, which itself requires analysis that may not be complete when the requirements are written.
Handling conflicting constraints. The turbojet compressor has minimum flow requirements to avoid surge. The ramjet inlet has maximum flow requirements to avoid unstart. During transition, both constraints are active, and there is a design space — inlet geometry, bypass valve schedule, fuel flow timing — where both can be satisfied, but it is narrow. Requirements that treat each mode independently will not capture this interaction. Requirements that try to capture it explicitly can become so conditional and complex that they are impossible to trace cleanly.
Separating performance requirements from design constraints. One of the fundamental errors in requirements writing on high-risk programs is encoding design decisions into requirements. For a novel engine like Chimera, there is enormous pressure to do this — the design team knows how they intend to solve the transition problem, and it is tempting to write requirements that describe that solution rather than the outcome the solution needs to achieve. The cost of this error surfaces during verification: if the requirement describes a design approach rather than a measurable outcome, you cannot verify it without building and testing that exact approach, which eliminates the flexibility to iterate.
The Verification Problem
Even if a team writes excellent transition-band requirements — outcome-focused, precisely bounded, internally consistent — they face a second problem: verifying those requirements when full-envelope testing is not accessible.
The United States has limited hypersonic ground test infrastructure. Facilities capable of sustained Mach 5 airflow at the scale of a full propulsion system are rare and expensive. The Air Force Research Laboratory’s facilities, the Arnold Engineering Development Complex, and a handful of university assets can test components and subscale models, but they cannot reproduce full-flight conditions for extended durations at the fidelity needed to verify complex behavioral requirements.
This forces a decomposition strategy that is standard in aerospace but particularly challenging for Chimera: break top-level performance requirements into sub-system and component requirements that can be verified at accessible test conditions, then argue analytically that the component-level verification, combined with simulation, is sufficient to give confidence in the top-level requirement.
This strategy works when the system is well-understood and the analytical models are validated. For the transition regime of a novel combined-cycle propulsion system, neither condition fully holds. The aerothermodynamic models for supersonic combustion initiation are good but not perfect. The compressor surge models at high-temperature inlet conditions are validated in narrow regimes. The coupled behavior of the two thermodynamic systems during handoff involves interaction effects that are genuinely not fully characterized.
The practical consequence is that verification plans for transition-band requirements carry explicit uncertainty. A well-run program acknowledges this explicitly — it maintains a live list of which requirements have high-confidence verification paths and which are dependent on analytical models with known limitations. This list should be traceable: for every transition-band requirement, the verification plan should identify the test or analysis that closes it, the confidence level of that closure, and the residual risk if the closure is incomplete.
On programs that manage this well, the traceability structure is not documentation overhead — it is a risk management tool. The requirements that lack clean verification paths become the prioritization input for limited test resources. You schedule the tests that close the highest-risk requirements first, not the tests that are easiest to run.
What This Reveals About Requirements Management Under High Technical Risk
Hermeus’ challenge with Chimera is a concentrated version of a problem that shows up across all high-TRL hypersonic and advanced propulsion programs. It reveals several things about requirements management practice that are worth naming explicitly.
Document-centric requirements management fails first at the boundaries. If requirements are maintained in documents — even well-structured documents — the relationships between requirements in different operating regimes are captured as prose or as manual cross-references. When a change is made to the inlet requirements for turbojet mode, the engineer making the change has to manually identify every requirement in ramjet mode that might be affected. In a transition-band problem, those cross-regime dependencies are numerous and non-obvious. Graph-based requirements models, where requirements are nodes and dependencies are explicit edges, surface these connections automatically. The transition band is exactly the kind of topology that breaks document-based traceability.
Derived requirements need explicit ownership. On a program like Chimera, the top-level mission requirements come from one team, the engine-level requirements come from another, and the transition-band requirements — because they do not fit cleanly into either layer — risk being orphaned. Requirements that do not have a clear owner tend not to get updated when the design evolves. They also tend not to get verified because no one has written them into a test plan. Explicitly assigning ownership to derived requirements, including the cross-regime requirements that live in the transition band, is operational discipline, not bureaucracy.
Verification strategy should be written into requirements at the time of authoring. For high-risk programs with limited test access, waiting until the verification planning phase to determine how a requirement will be closed is a mistake. By the time verification planning begins, the test campaign budget is already constrained and the design is already partially frozen. Requirements written with verification method annotations — even rough ones, like “closes by simulation with anchoring data from subscale test” — force the team to confront verification risk early, when there is still time to make design decisions that make verification tractable.
Ambiguity in transition-regime requirements is not neutral. In steady-state regime requirements, ambiguity is a quality problem — it creates rework and conflict during verification. In transition-regime requirements, ambiguity is a safety problem. If the requirement governing when the bypass valve must be closed during transition can be interpreted two ways, the two interpretations may correspond to two different design decisions, one of which causes compressor surge and one of which does not. The stakes of ambiguity go up when the physical behavior being constrained is irreversible.
Tools and Traceability in High-Risk Propulsion Programs
The tooling choices for programs like Chimera are consequential in ways that are not always visible until the program is in trouble.
Legacy requirements management platforms — IBM DOORS, Polarion, Codebeamer — are capable tools for managing large requirement sets. They have decades of aerospace pedigree and genuinely strong configuration management capabilities. The challenge for a Chimera-class problem is that they were designed around documents and hierarchical structures. The transition-band requirement problem is fundamentally a graph problem: requirements from two different operating regimes are connected by physical constraints that do not fit cleanly in a hierarchy.
More recently, tools designed explicitly around graph-based requirement models and built for the kind of cross-domain traceability that advanced propulsion demands have entered the market. Flow Engineering, which structures requirements as a connected model rather than a document hierarchy, is built around the premise that the dependencies between requirements are first-class objects, not annotations. For a program managing transition-regime requirements across thermodynamic regimes, inlet aerodynamics, mechanical systems, and control logic, that architectural choice matters. The ability to ask “which requirements are affected if I change the inlet bypass schedule” and get an automated answer rather than a manual search is not a convenience feature — it is risk management infrastructure on a program where test opportunities are finite and expensive.
The honest caveat is that graph-based tools require discipline in how requirements are authored. The traceability is only as good as the links that have been created, and creating those links requires the authoring team to have thought through the dependencies explicitly. On a novel program like Chimera, some of those dependencies will not be known when the requirements are first written. The value of the tool is not that it discovers unknown dependencies — it is that it makes known dependencies explicit and maintainable as the design evolves.
Honest Assessment
Hermeus is working on one of the genuinely hard problems in propulsion engineering. The Chimera engine’s transition regime is not a solved problem dressed up as a novel challenge — it is a real boundary-crossing problem where the physics are coupled, the test infrastructure is limited, and the requirements management discipline required to work safely through the design is substantial.
The systems engineering challenge is not whether Chimera can be made to work — the subscale demonstrations suggest it can. The challenge is building the requirements infrastructure that lets a team of engineers make design changes in one regime without inadvertently compromising requirements in another, and verify those requirements with confidence proportional to the risk of getting them wrong.
That challenge is not unique to Hermeus. It is the challenge of any program where the operating envelope crosses a physical boundary — combined-cycle propulsion, supercritical fluid systems, multi-phase thermal management, variable-geometry structures. The Chimera engine just happens to be one of the clearest and most publicly visible examples of what that challenge looks like when the physics are genuinely new.
The programs that manage it well will not necessarily be the ones with the best engineers. They will be the ones with the best requirements infrastructure.