Relativity Space: How 3D Printing an Entire Rocket Changes the Systems Engineering Equation

Relativity Space set out to 3D print an entire rocket. Not most of it. Not the non-structural bits. The whole thing — tanks, engine components, interstage, feedlines — produced almost entirely by large-format metal additive manufacturing using their proprietary Stargate printing systems. The first vehicle, Terran 1, flew in March 2023 and reached max-q before a second-stage ignition failure ended the mission. The rocket itself performed. The part that mattered — the printed structure — held together under full aerodynamic and thermal load.

That outcome matters less for what it tells us about 3D printing and more for what it reveals about systems engineering. Relativity didn’t just adopt a different manufacturing process. They adopted a manufacturing process that restructures the entire logic of how a launch vehicle gets decomposed, specified, traced, and verified. The systems engineering implications are significant enough to warrant direct examination, separate from the launch vehicle business case.

The Interface Management Problem Gets Inverted

Conventional launch vehicle development is an interface management problem at its core. A vehicle like the Falcon 9 contains roughly 10,000 parts. Early Atlas and Delta vehicles had part counts in the hundreds of thousands. Every discrete part boundary is a potential interface — mechanical, thermal, electrical, fluidic, or some combination. Managing those interfaces is the central task of systems engineering in aerospace: writing ICDs, allocating tolerances, coordinating between subsystem teams, and running integration activities that verify the interfaces were actually implemented as specified.

Relativity’s Terran 1 had approximately 1,000 parts. Their Terran R target is similarly aggressive. When you collapse part count by two orders of magnitude, you don’t just reduce the quantity of interfaces — you eliminate entire categories of them. The bolted joint between a tank dome and a barrel section disappears if those two features are a single printed structure. The weld seam between a manifold and a feedline disappears if they’re printed monolithically. The fastener pattern on a thrust structure bracket disappears if the bracket and the structure are the same material volume.

This sounds unambiguously beneficial, and in many ways it is. Fewer interfaces mean fewer failure modes, fewer ICD negotiation cycles, and less integration labor. But the inversion is this: you’ve traded a large number of discrete, well-understood interface types for a small number of continuous, poorly-standardized interface types. The boundary between a printed tank wall and a printed weld-equivalent joint is not an interface in the traditional sense. It’s a gradient — of microstructure, of residual stress, of porosity distribution, of local material properties that depend on print path, laser power, scan strategy, and chamber atmosphere at that specific moment in the build.

Systems engineering as a discipline has mature methods for discrete interfaces. It has immature methods for continuous, process-dependent material transitions. That gap is where the real engineering challenge lives.

Manufacturing Variability Is a Requirements Problem, Not a Tolerance Problem

In conventional manufacturing, variability is handled through geometric tolerancing. A machined part has dimensional tolerances. A casting has surface finish specifications and allowable defect sizes. A forging has grain flow requirements. These are material properties requirements in a limited sense, but they’re generally separable from the design intent — you design the geometry, and the manufacturing process delivers it within an acceptable envelope.

Large-format metal additive manufacturing — Relativity uses directed energy deposition with their Stargate printers — doesn’t work that way. The material properties of a printed structure are not independent of the geometry being printed. The thermal history of a voxel depends on what was printed adjacent to it, what was printed above and below it, how long the laser dwelt in that region, and how heat conducted away through the surrounding structure. Change the wall thickness in one section and you change the residual stress state in an adjacent section. Print a large flat panel and you get different grain morphology than printing a curved shell of the same nominal alloy.

This means manufacturing variability is not a post-design phenomenon that tolerancing can contain. It’s a design-coupled phenomenon that has to be addressed in the requirements themselves. The question isn’t “what dimensional variation can we accept?” It’s “what process parameter ranges produce material properties within the structural requirements, and how do we verify that the actual print stayed within those ranges?”

That’s a fundamentally different requirements engineering problem. It requires requirements that reference process parameters as variables — laser power, scan speed, layer thickness, inter-pass temperature — and it requires traceability from those parameters to structural margins. In a traditional requirements structure, manufacturing process is an implementation detail below the system specification level. In additive manufacturing, it’s a first-class design variable that appears in the requirements baseline.

The verification question is equally hard. You cannot inspect material properties from the outside of a printed structure the way you can inspect dimensional compliance. Non-destructive evaluation methods for AM structures — computed tomography, phased-array ultrasound, acoustic resonance — are maturing but not standardized. The verification chain from a structural requirement to a printed part is longer, more inference-dependent, and less certain than the equivalent chain for a machined or forged component.

What Happens to the V-Model

The systems engineering V-model is a sequencing model. On the left side, requirements flow down from system to subsystem to component. At the bottom, design decisions get made. On the right side, verification flows back up. The model assumes a temporal ordering: you finish requirements before design, you finish design before manufacturing, you verify manufactured hardware against requirements.

That sequencing assumption breaks down in Relativity’s design environment — not because they’re undisciplined, but because design and manufacturing are coupled in a way the V-model doesn’t accommodate.

Consider a structural requirement for a propellant tank: it must contain LOX at operating pressure with a defined safety factor, survive the acoustic environment during launch, and meet a mass budget. Satisfying that requirement requires choosing wall thickness, geometry, and alloy. But in additive manufacturing, choosing those parameters also partially determines what print strategy is feasible, which determines what material properties you’ll actually achieve, which feeds back into whether the structural requirement is actually satisfied. You cannot complete the design without knowing the process, and you cannot finalize the process without knowing the design.

Aerospace SE practitioners will recognize this as a concurrent engineering problem, and concurrent engineering is not new. Model-based systems engineering exists partly to handle this kind of coupling. But MBSE frameworks were developed primarily to manage complexity across organizational interfaces in large multi-contractor programs — to ensure Boeing and Lockheed and NASA were working from the same model. The coupling Relativity faces is tighter and more technical: it’s between design intent and physics of manufacture, not between organizational boundaries.

The practical implication is that Relativity’s V-model has to be replaced with something more iterative. The design authority for a structural component can’t be separated from the process authority for printing that component. Requirements have to be expressed in terms that are verifiable against process outputs, not just geometric outcomes. Verification activities have to include in-process monitoring — thermal imaging during printing, real-time parameter logging — as part of the verification record, not just post-process inspection.

That’s a significant departure from how aerospace SE programs are typically run, and it has downstream consequences for certification, change management, and supplier qualification that the industry is still working through.

The Part Count Reduction Is Also an Organizational Signal

One aspect of the systems engineering change that gets less analytical attention: collapsing part count doesn’t just reduce interfaces in the hardware. It reduces organizational interfaces. A 100,000-part vehicle is built by dozens of suppliers, each responsible for a portion of the part tree. The systems engineering organization exists partly to manage the technical interfaces between those suppliers — to ensure that part A from supplier X and part B from supplier Y fit together and function together.

When Relativity prints structures in-house, they eliminate many of those supplier relationships. The systems engineering burden shifts from managing inter-organizational ICDs to managing intra-process consistency. That’s not obviously simpler. An ICD negotiation between two engineering teams, however contentious, produces a documented artifact that both parties sign and that can be traced. A process parameter decision made by a manufacturing engineer during a print job may not produce an equivalent artifact unless the process management infrastructure deliberately creates one.

This is a requirements traceability problem specific to vertically integrated additive manufacturing. When the manufacturing organization is also the design organization, the informal feedback loops that would normally constitute a change request and an ICD update can happen without generating any traceable record. The organizational separation that makes traditional aerospace SE heavyweight is also the organizational separation that forces explicit documentation of technical decisions. Remove the separation and you have to rebuild the documentation discipline through other means.

The Honest Assessment

Relativity’s approach is genuinely novel and the systems engineering implications are genuinely unresolved. That’s not a criticism — it’s an accurate description of what happens when a manufacturing paradigm changes fast enough that the engineering discipline hasn’t finished catching up.

The advantages are real: fewer discrete interfaces mean fewer integration failure modes, shorter supply chains mean faster design iteration, and monolithic printed structures eliminate entire classes of fastener fatigue and joint leakage problems that plague conventional vehicles. Terran 1’s first flight was a meaningful demonstration that large-scale metal additive manufacturing can produce flight-worthy structures.

The challenges are also real: material property variability tied to process coupling is a harder requirements problem than dimensional tolerancing; in-process verification methods aren’t standardized and aren’t as legally defensible as post-process inspection for certification purposes; and the V-model’s sequencing assumptions, which underpin most aerospace SE planning and contractual structures, don’t map cleanly onto a design-manufacture-coupled workflow.

The systems engineering discipline needs new frameworks here. Specifically: requirements structures that can reference process parameters as design variables with defined acceptable ranges; verification methodologies that incorporate in-process monitoring as primary evidence rather than supplementary data; and change management processes that account for the fact that a print parameter adjustment is a design change, even if it doesn’t touch a CAD file.

Tools built for document-centric requirements management — where a requirement is a sentence in a numbered list, and traceability is a link between two sentences — struggle with this problem. The relationships between a structural requirement, a process parameter envelope, a print monitoring record, and a material coupon test result aren’t hierarchical document relationships. They’re a graph of technical dependencies, and reasoning about them requires infrastructure that can represent that graph explicitly and query it systematically.

The launch vehicle industry is moving toward higher production rates and shorter development cycles. Relativity’s bet is that additive manufacturing is the path there. Whether that bet pays off in the market, the systems engineering discipline has to be ready with methods that match the manufacturing reality — not methods that assume a separation between design and manufacturing that no longer exists.