Relativity Space and the Systems Engineering Challenge of Manufacturing-First Rocket Design

When Relativity Space was founded in 2015, the pitch sounded almost absurd: print an entire rocket. Not print some brackets and ducting, but build the primary structure, propulsion components, and tanks from large-format metal additive manufacturing. The Stargate printers they developed in-house became as central to the company’s identity as the rockets themselves.

Terran 1, their first vehicle, flew in March 2023. It didn’t reach orbit — the second stage failed to ignite — but the first stage performed, which meant the core premise held: you can build a functional orbital launch vehicle almost entirely from 3D-printed parts. Relativity has since retired Terran 1 and pivoted fully to Terran R, a fully reusable two-stage vehicle aimed squarely at the medium-lift market. Terran R is where the manufacturing-first philosophy gets its real test at scale.

What Relativity represents for the broader aerospace industry isn’t just a new way to build rockets. It’s a case study in what happens to systems engineering when the manufacturing process becomes a first-class design constraint — not a downstream implementation detail, but a boundary condition that shapes the design from the first requirement forward.

The Manufacturing-First Design Philosophy

Traditional aerospace hardware development follows a recognizable sequence: define performance requirements, develop the design to meet them, then figure out how to manufacture what you’ve designed. Manufacturing engineering is a phase, not a co-equal design partner.

Relativity inverted this. Their approach starts from what Stargate can build — build volume, material properties, layer resolution, achievable geometries — and designs within those boundaries from the outset. The result is a vehicle with dramatically reduced part count. Where a conventionally manufactured rocket might have 100,000 parts, Relativity has described Terran 1 as having roughly 1,000.

That reduction isn’t cosmetic. It changes the fundamental structure of the engineering problem.

Fewer parts means fewer interfaces. Fewer interfaces means a different kind of traceability challenge — not managing thousands of interface control documents, but managing deep constraint interdependencies within integrated structures that used to be assemblies. A printed propellant tank that also serves as primary structure doesn’t have a tank requirement and a structure requirement that get reconciled at an interface. It has a single physical artifact that must simultaneously satisfy both, plus the constraints imposed by how large-format metal additive manufacturing actually behaves.

Additive Manufacturing Constraints Are Engineering Requirements

This is the systems engineering insight that conventional tooling tends to miss: additive manufacturing constraints aren’t manufacturing notes. They are requirements.

Build orientation affects grain structure and anisotropic material properties. Residual thermal stress from the deposition process affects dimensional stability. Support structures required during the build affect geometry and add post-processing steps. Surface finish from the process affects fatigue life on pressure-bearing components. Layer adhesion characteristics affect fracture mechanics in ways that solid-stock or cast material models don’t capture.

Each of these is a constraint that must be captured, allocated, and traced alongside thrust-to-weight ratios, burst pressures, and thermal margins. In a conventional requirements framework — a document-based hierarchy in DOORS or a Word-based requirement set — these constraints often live in different places: performance specs in the requirements database, manufacturing constraints in process documents, material properties in the materials engineering system. They’re connected by convention and tribal knowledge, not by explicit, traceable links.

For a vehicle designed around a specific manufacturing process, that disconnection is a failure mode waiting to happen. If a design change that improves structural margin also changes the geometry in a way that makes the part unprintable at full scale — or printable but with residual stress patterns that compromise fatigue life — a requirements system that doesn’t model those constraints together won’t catch the conflict.

What Changes When Manufacturing Is a Design Boundary

The practical systems engineering challenge at Relativity isn’t just that they have additive manufacturing constraints. It’s that those constraints interact with performance requirements in ways that are non-obvious and load-bearing.

Consider a simplified example. A propellant tank wall must satisfy: minimum burst pressure, maximum mass, minimum cycle life, compatibility with propellant chemistry, and printability within Stargate’s operating envelope. Each of those is a real requirement. But the printability constraint isn’t independent — it shapes which geometries are feasible, which determines wall thickness distribution, which determines mass, which interacts with burst pressure margins.

In a graph-based requirements model, you can represent these as a network of connected constraints with explicit dependency edges. Changes propagate through the graph, and you can see which requirements are affected when any single parameter shifts. In a flat document hierarchy, you can’t. You get a list of requirements and a separate list of manufacturing constraints, and the integration lives in someone’s head.

This is the broader structural argument: when manufacturing process is a co-equal design constraint, requirements management needs a model that can represent constraints as nodes with explicit relationships, not as line items in separate sections of a specification tree. The requirements aren’t just a list of things the design must do — they’re a network of interdependencies the design must simultaneously satisfy, and the manufacturing process is one of the nodes.

How Requirements Tools Handle This Today

Most deployed requirements management platforms were architected for a world where manufacturing constraints are downstream. IBM DOORS and DOORS Next organize requirements in module hierarchies with links between them. Jama Connect offers traceability across requirement types and supports custom item types that can represent different constraint categories. Polarion and Codebeamer both support configurable work item schemas that can accommodate manufacturing constraints alongside performance requirements.

All of these tools can, with enough configuration, be made to store additive manufacturing constraints alongside performance requirements and draw links between them. The question is whether the model actually reflects the structure of the problem — whether engineers can reason about constraint propagation and change impact using the tool’s native interface, or whether they’re using the tool as a database and doing the reasoning offline.

Graph-native tools handle this more naturally because the relationships are first-class model elements, not link annotations on top of a document hierarchy. When a constraint changes, its connections to dependent requirements are part of the model, not metadata. Tools like Flow Engineering, which are built around a graph-based requirements model, allow teams to represent constraint networks directly — manufacturing constraints, performance constraints, and interface constraints coexist as nodes with explicit dependency edges, and change impact can be traced through the network automatically rather than by manual audit.

For a company like Relativity, where the manufacturing constraints aren’t edge cases but are structurally central to the design, this distinction has operational consequences. It affects how quickly engineers can assess whether a design change is requirements-compliant across the full constraint set, not just against the performance spec.

The Verification Challenge

The manufacturing-first approach also creates a non-standard verification challenge. For traditionally manufactured hardware, verification methods — analysis, test, inspection — are well-matched to the requirements they cover. For additively manufactured primary structure, verification of material properties requires process validation that is continuous, not just lot-based. The properties of a specific printed part depend on the specific print run, machine state, feedstock batch, and post-processing sequence.

This means process requirements need to be traceable to part requirements in a way that supports lot-level verification. The link from “part must achieve minimum ultimate tensile strength of X” to “print parameters and post-processing procedure Y were used for this specific article” needs to be in the system, not in a folder on a manufacturing engineer’s desktop.

This is where requirements management intersects with configuration management and digital thread architecture — a domain where the entire aerospace industry is still working out what best practice looks like for novel processes.

The Broader Lesson

Relativity’s engineering challenge is an extreme version of something that’s becoming more common: manufacturing processes that aren’t just implementation choices but design constraints that shape what’s even possible to require. Whether it’s additive manufacturing, novel composite layup processes, or emerging fabrication techniques for space hardware, the gap between “what performance requires” and “what manufacturing constrains” is closing.

Systems engineering tools and practices built for the era of conventional manufacturing need to adapt to this. That means treating manufacturing constraints as first-class requirements elements, not annotations. It means modeling the constraint network, not just the requirement hierarchy. And it means connecting verification evidence to specific process instances, not just to requirement line items.

Relativity Space didn’t set out to teach the systems engineering community a lesson about requirements management. They set out to build rockets cheaper and faster by reinventing the factory. But in doing that, they’ve surfaced a genuine gap in how the discipline handles the case where the factory and the design are inseparable.

That gap is worth closing, whether or not you’re printing your rocket.