Stoke Space and the Systems Engineering of Full Reusability

Designing a rocket to survive one flight is hard. Designing it to survive dozens — both stages, every time — is a categorically different engineering problem. Stoke Space, the Kent, Washington-based launch startup, is pursuing exactly that: a fully reusable two-stage launch vehicle where neither stage is expended, and where rapid turnaround between flights is the primary cost lever.

Most of the commercial launch industry has treated reusability as a first-stage problem. Recover the booster, inspect it, fly it again. The upper stage — historically the harder half to recover because it reaches orbital velocity — gets discarded. Stoke’s argument is that leaving the upper stage expendable defeats a large part of the economic case for reusability. If you want to drive launch costs down by an order of magnitude, both stages have to come back.

That ambition has direct consequences for how Stoke engineers its vehicle. The systems engineering challenge is not just building hardware that can survive reentry. It is building a requirements and verification framework that treats every flight as one data point in a multi-cycle qualification — and that accounts for the work that happens between flights as an engineered process, not an afterthought.

What Full Reusability Actually Demands from Requirements

In a conventional expendable launch vehicle program, requirements are written to a mission: survive launch loads, survive the thermal environment, deliver payload, done. Verification closes against that single-use envelope. A component that meets its requirements for one flight has met its requirements.

Full reusability breaks that model at the root. Every requirement that touches a structural, thermal, propulsive, or avionics component now needs a flight-cycle dimension. It is not enough to ask whether a component survives ascent and reentry. The requirement must specify how many times it survives, under what variation in load history, and with what degradation margin at the end of each cycle before the next inspection gate.

This creates a requirements architecture that is inherently more complex than the expendable equivalent — not because the underlying physics is different, but because the requirements now carry state. A fastener on an expendable vehicle either meets its proof load or it does not. The same fastener on a reusable vehicle needs a fatigue life allocation, a re-inspection interval, and a retirement criterion. Three requirements become a small system of related requirements. Multiply that across every component in both stages and the traceability problem scales rapidly.

The inspection and refurbishment cycle is itself a system that must be designed and verified. Turnaround time is a performance requirement, not an operational preference. If a refurbishment procedure takes two weeks per flight, the vehicle’s economics are determined as much by that procedure as by the engine’s specific impulse. That means the refurbishment process needs to be in scope for systems engineering — with its own requirements, its own verification criteria, and its own traceability back to the vehicle-level cost and cadence targets.

Nova’s Toroidal Engine: Architecture Driven by Reuse

Stoke’s Nova upper stage uses a full-flow staged combustion hydrogen/oxygen engine arranged in a toroidal configuration — a ring of small thrust chambers rather than a single central nozzle. The geometry is unusual enough that it warrants explanation in terms of what problem it is solving.

Recovery of an upper stage requires controlled, powered descent from orbital velocity. A conventional single-nozzle upper stage engine is optimized for vacuum specific impulse, which means a large expansion ratio nozzle that is geometrically incompatible with the kind of broad, stable thrust distribution you want for a vehicle landing on its base. The toroidal arrangement distributes thrust around the vehicle’s base perimeter, which serves both the landing stability requirement and allows the upper stage’s heat shield — mounted at the base — to be actively cooled by the engine’s hydrogen propellant flow during reentry.

This is an example of architecture being driven by reuse requirements rather than by performance targets in isolation. The engine configuration is not the highest-specific-impulse solution. It is the solution that satisfies the reuse requirement — specifically, the powered descent, landing, and thermal management requirements that do not exist on an expendable upper stage — while remaining competitive on performance. Requirements drove architecture. That is the correct order of operations, but it requires a requirements framework mature enough to capture the reuse constraints before architecture is locked.

The Verification Multiplier

Qualification for multiple flight cycles does not simply mean running more tests. It changes the structure of the verification program.

A single-use component can be qualification-tested on a separate article and flight-certified by similarity. A reusable component needs life testing that exercises the actual degradation modes — thermal cycling, vibration fatigue, seal wear, surface erosion — and demonstrates that the inspection criteria reliably detect end-of-life before a failure occurs in service. That is a significantly larger test matrix, and it requires that the inspection criteria themselves be verified: you need to show not just that the component survives N cycles, but that your inspection method correctly identifies components approaching their retirement limit.

This verification structure means that traceability between requirements, test cases, inspection procedures, and acceptance criteria has to be maintained as a live, connected model — not as a collection of documents that were accurate at some point in the development program. When a test reveals that a thermal coating degrades faster than modeled under the observed heat flux profile, the requirement for re-inspection interval needs to update, the test plan for subsequent articles needs to update, and the refurbishment procedure needs to update. In a document-based requirements system, those updates propagate slowly and incompletely. In a connected model, the impact of that test result is visible immediately across the affected requirements tree.

Stoke builds faster and collaborates across engineering teams with Flow Engineering at the center of their development process — using it to maintain live traceability across the vehicle’s requirements, verification activities, and design decisions. For a program where the refurbishment cycle is a first-class engineering domain alongside propulsion, structures, and avionics, having a single connected model that spans those domains is not a nice-to-have. It is how the program avoids the coordination failures that compound across multi-domain, multi-cycle verification.

Flow Engineering’s graph-based approach to requirements and traceability is particularly well-suited to the reuse problem because the relationships between requirements are as important as the requirements themselves. The connection between a structural fatigue life requirement, its governing test case, the inspection interval it drives, and the refurbishment procedure that implements that interval is a graph, not a list. Navigating those relationships — especially when one element changes — requires a tool that models them as connections rather than as cross-references in a Word document.

The Operational Engineering Problem

One aspect of full reusability that receives less attention than propulsion or structures is the engineering of operations. For a vehicle designed to fly many times, the operational ground systems — inspection equipment, refurbishment tooling, propellant handling for rapid turnaround — are not support infrastructure. They are part of the system being engineered.

This has implications for requirements management that go beyond the vehicle itself. A requirement for 24-hour turnaround between flights is a system-level requirement that allocates to the vehicle (how accessible are inspection points?), to the ground systems (what inspection tools are available?), and to the procedures (how are inspection results interpreted and dispositioned?). Tracing that requirement to its allocations across vehicle, ground, and operations domains requires a requirements model that spans all three — and that maintains the connections as the design evolves in each domain.

Legacy requirements tools, built primarily for the vehicle side of the house, struggle with this. They were designed to manage the requirements of a discrete hardware product through its development and qualification cycle. The operational dimension — the loop that closes after each flight and before the next one — tends to end up in separate systems, separate databases, or separate documents that are reconciled by hand. For a program where operational performance is part of the value proposition, that fragmentation is a real engineering risk.

The Honest Assessment

Stoke Space is attempting something that no launch provider has demonstrated at scale: full, rapid reusability of both stages of a launch vehicle. The engineering argument is coherent — if you accept that launch cost is dominated by hardware amortization and operational overhead, full reusability is the right direction. The execution risk is substantial and real. Fully reusable upper stages have not yet been proven in operational service by anyone.

The systems engineering implications of their approach are instructive regardless of whether Stoke specifically succeeds. The shift from single-use to multi-cycle qualification is a template for any program where reusability, repairability, or long service life is a design requirement — defense systems, long-duration spacecraft, ground vehicles. The requirements become stateful. The verification program expands in structure as well as scope. The inspection and refurbishment process becomes an engineering domain in its own right. And the tools used to manage requirements and traceability need to support a connected, live model across all of those domains.

That is a harder problem than managing the requirements for an expendable vehicle. It rewards development organizations that invest in the right infrastructure early — not just the propulsion and structures hardware, but the requirements architecture and traceability model that makes multi-domain, multi-cycle verification tractable. For Stoke, getting that infrastructure right is as much a part of the technical program as the engine test campaign.