Boom Supersonic: Requirements Engineering for a Clean-Sheet Commercial Supersonic Aircraft

When Boom Supersonic describes Overture as a clean-sheet design, the word clean-sheet carries more engineering weight than marketing intent. There is no prior commercial supersonic transport program to inherit a requirements baseline from. Concorde’s certification basis is not transferable. The Boeing 2707 never flew. The Tu-144 operated under Soviet airworthiness frameworks irrelevant to FAA Part 25. Boom is, in nearly every meaningful sense, building the regulatory and systems engineering architecture for commercial supersonic flight from scratch — while simultaneously designing and building the aircraft.

That combination creates a requirements environment of unusual complexity, and understanding how it is structured tells you something important about both the program’s risks and its engineering maturity.

What Makes Supersonic Requirements Different

Every commercial aircraft development program is a requirements management problem. The interaction between airframe, propulsion, avionics, structures, and systems always generates more dependencies than any team initially anticipates. But supersonic transport amplifies those interactions in specific, predictable ways.

Aerodynamic-structural coupling is acute. At Mach 1.7 — Overture’s target cruise speed — aerodynamic heating, wave drag, and sonic boom pressure signatures create loading cases that simply do not appear in subsonic design spaces. A structural requirement to limit fuselage skin temperatures drives material selection, which drives manufacturing processes, which drives weight, which feeds back into aerodynamic performance margins. At subsonic speeds, these loops close with manageable iteration. At supersonic cruise, they are tighter, faster, and more sensitive to assumption drift.

Propulsion requirements are multi-directional. Overture’s engine requirements are not just about thrust and fuel burn. They must simultaneously satisfy FAA Part 25 takeoff and climb performance standards, ICAO Annex 16 Chapter 14 noise standards at airports (which were not written with supersonic transports in mind), overwater sonic boom acceptability criteria from the FAA’s recent rulemaking work, and the emissions constraints that increasingly govern aircraft operating economics and regulatory access. A requirement that improves specific fuel consumption at cruise may degrade noise margin at takeoff. A requirement that reduces NOx emissions affects combustor design, which affects operability margins, which affects engine-aircraft integration. These are not independent requirement sets.

Certification basis negotiation is itself a program deliverable. For a conventional narrowbody or widebody aircraft, the FAA certification basis is well-established. The applicant negotiates special conditions for novel features, but the foundation is stable. For Overture, Boom is working with the FAA to establish the certification basis for a new vehicle category. That process generates requirements — in the form of special conditions, equivalent level of safety findings, and issue papers — that arrive on a timeline Boom does not fully control. Managing design development against a certification basis that is still being defined is a class of requirements volatility that most programs do not face.

ARP4754A and DO-178C in a Novel Configuration

ARP4754A — the SAE aerospace recommended practice for development of civil aircraft and systems — provides the process framework that connects aircraft-level requirements to system-level design assurance. DO-178C governs software development for airborne systems. Both were written with conventional aircraft configurations as the implicit reference case. Neither is inapplicable to Overture. Both require careful interpretation.

ARP4754A’s aircraft function development process assumes that safety assessment and functional hazard analysis can be conducted against a relatively stable aircraft-level functional architecture. For Overture, the aircraft-level architecture is still being refined during the same period when system-level development assurance processes need to be established. The program must essentially conduct preliminary aircraft safety assessment (PASA) and functional hazard analysis (FHA) work while major architectural decisions are still live. This is not unusual for early-stage programs, but it means the traceability chain from aircraft-level safety objectives to system design requirements is under active revision for a longer period than a derivative aircraft program.

The practical implication is that requirements baselines established early in the program will undergo structured change as safety assessment work matures. Boom’s engineering teams need change management discipline built into their requirements process from the start — not retrofitted when the first major safety assessment output triggers a cascade of derived requirements.

DO-178C is less architecturally sensitive than ARP4754A, but it imposes development assurance levels (DALs) that propagate from functional hazard analysis results. For a novel aircraft, the DAL assignments for avionics and flight control software cannot be finalized until the FHA is sufficiently mature. Programs that begin software development before DAL assignments are stable face expensive rework. For a commercially-funded program with finite capital, that is not a theoretical risk.

What a Clean-Sheet Requirements Structure Looks Like

Commercial aircraft programs operating under ARP4754A/AS9100 frameworks typically organize requirements across several levels: aircraft-level requirements (ALR), system requirements, subsystem requirements, and component-level specifications. Traceability runs bidirectionally — downward through allocation, upward through verification.

For Overture, that structure is real but more complex in three specific dimensions.

The certification requirements layer is unusually thick. In addition to FAA Part 25 airworthiness standards, Overture must comply with or obtain relief from ICAO Annex 16 noise standards (both subsonic airport operations and the emerging overland supersonic flight framework), ICAO Annex 16 Volume II emissions standards, FAA’s developing overwater supersonic flight rule (14 CFR Part 91 subpart I revisions), and the bilateral aviation safety agreement (BASA) requirements for European EASA validation. Each of these represents a requirements source that is partially external to the program’s control and partially subject to ongoing regulatory development. Mapping these external requirements into the internal requirements hierarchy — and maintaining that mapping as regulations evolve — is a non-trivial program function.

Performance requirements are economic requirements. Overture’s commercial model depends on achieving specific seat-mile costs at specific passenger counts and route economics. That means range, fuel burn, payload, and operating empty weight targets are not simply performance goals — they are derived requirements that flow from commercial viability analysis. If structural weight grows to close a margin in the safety assessment, and that weight growth compromises seat-mile economics, the program faces a conflict between safety-derived requirements and commercially-derived requirements that must be resolved at the aircraft level. These conflicts are not unusual in aircraft development, but they are more frequent and more consequential in supersonic transport because the performance margins are narrower.

Cross-domain requirement interactions are denser. Subsonic aircraft programs live with significant cross-domain interactions, but mature design practices and well-understood physics reduce the surprise factor. Supersonic transport involves physics — wave drag, aero-thermal effects, sonic boom propagation, engine intake dynamics at transonic acceleration — where the interaction models are less mature and the design space is less thoroughly explored. Requirements that appear independent in the early architecture can turn out to be coupled through physics effects that only emerge in detailed analysis. Managing this requires both strong configuration management of the requirements baseline and a systematic process for capturing and resolving newly discovered interactions.

Managing Traceability at This Scale

The requirements structure for a clean-sheet commercial aircraft — even a subsonic one — generates thousands of requirements across multiple levels, with traceability relationships that must be maintained through design changes, safety assessment updates, and certification basis revisions. For a supersonic transport with the additional complexity layers described above, the scale and interconnection density of that requirements network is substantially larger.

Programs that try to manage this with document-based systems — Word, Excel, PDF-linked requirement sets — accumulate traceability debt that is invisible until a design change or safety assessment update triggers a requirement to trace the impact. At that point, the manual effort to identify all downstream effects and verify that no requirement has been orphaned or contradicted is substantial. For a commercially-funded program managing capital carefully, unplanned engineering labor on requirements maintenance is a direct hit to program margin.

The industry shift toward graph-based requirements management reflects the reality that requirement relationships are inherently a network, not a hierarchy of documents. Tools that model requirements as nodes in a graph — with typed relationships between requirements, design artifacts, verification evidence, and safety assessment outputs — make impact analysis tractable at the scale supersonic aircraft programs generate.

This is the environment where modern AI-native platforms like Flow Engineering have a practical role: not as a certification tool, but as the connective layer that keeps the requirements network navigable as the program evolves. The ability to surface requirement conflicts, trace change impacts across domain boundaries, and maintain live coverage maps between certification basis items and system requirements is the kind of operational capability that distinguishes programs that manage requirements complexity from programs that are managed by it.

The Honest Assessment

Boom Supersonic is attempting something that has not been successfully done in the commercial aviation industry since the early 1970s, under a regulatory framework that is more rigorous, against environmental standards that did not exist when Concorde was certified, with a commercial funding model that imposes capital discipline unknown to national aerospace programs.

The systems engineering challenge is genuinely hard, not in the sense of being intractable but in the sense of requiring process discipline, tooling investment, and organizational rigor that must be provisioned as program infrastructure — not assembled reactively when complexity becomes visible.

The requirements management dimension of that challenge is one that is often underestimated. It is not glamorous. It does not show up in renderings or announced airline orders. But the programs that have failed in clean-sheet aircraft development — and there are many — failed in part because the gap between what was required and what was designed grew wider than the team could track. For Overture, staying inside that gap is a fundamental program competency.

Whether Boom has provisioned that competency at the scale the program requires is a question the next few years of development will answer. The engineering problem is well-defined. The question is whether the organization is structured to solve it.