Terran Orbital and the Systems Engineering Demands of High-Volume Satellite Manufacturing
What building small satellites at commercial throughput reveals about where traditional space program practices break down
When Lockheed Martin acquired Terran Orbital in late 2024, the transaction was read by most observers as a supply chain play — a major defense prime absorbing a high-throughput small satellite manufacturer to secure domestic production capacity. That reading is correct, but incomplete. The more interesting dimension of the acquisition is what it signals about the collision between two radically different approaches to systems engineering: the traditional space program model built around document control and milestone gates, and the commercial smallsat model built around iteration velocity and production line logic.
Terran Orbital had built something genuinely unusual in American aerospace — a manufacturing operation capable of producing satellites at rates that would have been implausible in the geostationary bus era. Their Titusville, Florida facility was designed around serial production, not bespoke integration. That ambition surfaces a set of systems engineering problems that the industry’s standard tooling and processes were never designed to handle.
What High-Rate Manufacturing Actually Means for Systems Engineering
The phrase “high-rate manufacturing” gets used loosely in the space industry. In the smallsat context, it means producing spacecraft with a recurring production cadence measured in weeks rather than years, across a product line that includes multiple variants sharing significant common heritage but diverging in payload, orbital regime, propulsion configuration, and customer-specific requirements.
This creates a specific class of engineering management problem that is distinct from either a single-spacecraft program or a pure commodity manufacturing operation. Each satellite must be individually verified against its own requirements baseline. Requirements are not uniform across the production run. And the production timeline leaves little room for the document review cycles that traditional programs use to gate integration and test milestones.
In a conventional space program, the requirements baseline is established early and changes are expensive — both financially and procedurally. That cost is a feature, not a bug, in programs where a single spacecraft represents hundreds of millions of dollars and a decade of mission planning. The friction in traditional change control exists because the consequences of undocumented changes propagating to flight hardware are catastrophic.
In a high-volume production environment, that same friction becomes an existential threat to throughput. If your change control process takes three weeks and you are building a satellite every few weeks, your change control process is your production bottleneck. This is the core tension, and it is not resolvable by simply working faster within the existing paradigm.
Configuration Management Across Variants: A Requirements Problem in Disguise
The configuration management challenge at commercial satellite production rates is frequently described as a manufacturing problem. In practice, it originates in requirements management.
Terran Orbital’s product strategy involved a common satellite bus — a standardized structural, power, and command-and-data-handling architecture — adapted across variants for different customer missions. This is sensible engineering. It enables reuse, supplier consolidation, and production efficiency. It also creates a requirements management structure that is genuinely complex: a baseline set of bus-level requirements, a layer of mission-specific or customer-specific derived requirements, and a set of interface requirements that must remain consistent across all variants sharing common subsystems.
When that structure lives in documents — Word files, PDFs, requirements databases with static exports — tracking which requirements are common, which are variant-specific, and how a change at the bus level propagates across the variant tree is manual, error-prone, and slow. Engineers spend time they do not have reconstructing traceability that should be structurally enforced.
The more rigorous approach treats the requirements architecture as a graph, not a document hierarchy. Bus-level requirements are nodes. Variant-specific requirements inherit from and constrain them. Interface requirements are edges between subsystem nodes, not tables in a separate ICD document. When a change is introduced — a supplier substitutes a component, a customer adds a capability requirement, a propulsion variant changes mass budget — the graph structure makes downstream impacts visible immediately, without a human manually tracing through document cross-references.
This is not a theoretical distinction. At production rates that compress the schedule from years to weeks, the difference between requirements management that is structurally enforced and requirements management that is manually maintained is the difference between catching an integration conflict before hardware is built and catching it during final environmental test.
Supplier Requirements Management at Commercial Scale
Traditional space supplier management is built around Interface Control Documents — formal, versioned, bilaterally agreed specifications that define what one subsystem delivers to another. ICDs are a sound engineering artifact. They are also inherently static: they represent agreement at a point in time, and keeping them synchronized with evolving designs requires deliberate, manual update cycles.
In a low-volume, long-cycle program, ICD staleness is a manageable risk. Reviews happen, red-lines get incorporated, formal revision cycles close before hardware ships. In a commercial production environment, the assumption that ICDs will be kept current through manual processes does not survive contact with production reality. Suppliers are delivering hardware on commercial lead times. Engineers are managing multiple active configurations simultaneously. The ICD that was accurate at PDR may describe a subsystem that has gone through two hardware revisions by the time the production run begins.
What commercial-scale satellite manufacturing exposes is that supplier requirements management needs to be continuous and machine-readable, not episodic and document-based. The interface definition needs to be a live artifact that both the prime and the supplier can query — not a PDF that one party has and the other does not know is out of date.
This is particularly acute for smallsat manufacturers because their supplier base is often a mix of space-heritage vendors operating on traditional program schedules and commercial component suppliers operating on consumer electronics timelines. Managing requirements interfaces across those two cultures simultaneously, at production volume, is an unsolved problem for most organizations using tools built for the traditional model.
Speed Versus Documentation Rigor: A False Dichotomy With Conditions
The conventional wisdom in the space industry frames speed and documentation rigor as fundamentally in tension. This framing is accurate when documentation is implemented as a bureaucratic process — sign-offs, review boards, formal transmittals — rather than as an engineering artifact. It is less accurate when requirements and their traceability are maintained as a living, queryable model rather than a paper trail.
The failure mode at high-volume commercial space programs is not insufficient documentation. It is documentation that exists for compliance reasons rather than engineering reasons — records that demonstrate process was followed rather than artifacts that capture design intent and enable impact analysis. When documentation serves compliance, engineers rationally minimize it under schedule pressure. When documentation serves engineering — when it is the primary tool for understanding what changed and what it affects — engineers have an incentive to maintain it because it reduces their own rework burden.
The shift required to make documentation serve engineering rather than compliance is primarily a tooling shift. Requirements captured in a graph-based model with live traceability to architecture, test, and verification artifacts can be queried in seconds. Requirements captured in a document hierarchy require hours of manual review to answer the same questions. At production rates where engineers are making dozens of configuration decisions per week, that difference compounds.
This is the architectural argument that modern requirements tooling makes — and it is an argument that becomes most visible, and most urgent, precisely in the high-rate manufacturing context that Terran Orbital represents.
Where Traditional Space Program Practices Break Down
Terran Orbital’s operating model put systematic pressure on several specific assumptions embedded in traditional space program practice.
Milestone-gated verification. Traditional programs structure verification around a set of formal review gates — PDR, CDR, TRR — where requirements compliance is evaluated against a snapshot of the design. This works when the design is relatively stable between gates. In a production environment, configuration changes are continuous. A gate-based model cannot keep pace; it either introduces unacceptable latency or becomes a formality that the production line routes around.
Requirements as the prime’s document. In traditional programs, the prime contractor owns the requirements baseline and flows requirements down to suppliers through formal transmittals. Suppliers receive requirements; they do not participate in managing them. At commercial scale, this model creates information latency that translates directly to hardware defects. Suppliers need to be working against current requirements, which means the requirements baseline needs to be accessible to them, not transmitted episodically.
Change control as a serialized process. Traditional Engineering Change Proposal processes are sequential — a change is proposed, reviewed, approved, incorporated, and verified in discrete steps with formal handoffs between each. This serialization is appropriate when changes are infrequent and high-stakes. At production rates where configuration changes are continuous, a serialized change control process creates a queue that never clears.
Test as the primary verification method. In low-volume programs, environmental testing is the mechanism by which requirements compliance is verified — if the hardware passes test, the requirements are met. At commercial volume, per-unit environmental testing at the rigor of traditional programs is economically and schedule-wise infeasible. This shifts more of the verification burden to analysis and similarity, which in turn requires a requirements traceability model sophisticated enough to support those verification methods with appropriate rigor.
The Lockheed Acquisition and What It Signals
Terran Orbital’s acquisition by Lockheed Martin is not a story about a startup failing to make its business model work. The commercial satellite manufacturing market evolved rapidly, and the consolidation dynamics were driven by factors well beyond systems engineering practice. But the acquisition does illuminate a structural dynamic: high-rate commercial satellite manufacturing requires a systems engineering operating model that most primes have not developed, and most commercial startups have not fully solved.
Lockheed brings mature processes, deep supplier relationships, and the financial stability to sustain a high-throughput manufacturing operation through the demand cycles inherent to government satellite programs. What that integration will look like at the systems engineering level — whether Terran Orbital’s production-oriented practices survive contact with traditional program management culture, or whether they get regularized into something slower and more familiar — is the more consequential question for the industry.
The organizations watching this most carefully are the ones trying to build their own high-rate manufacturing operations: the merchant satellite manufacturers, the constellation operators with ambitious replenishment schedules, and the defense prime contractors now required by their government customers to demonstrate commercial-rate delivery.
Honest Assessment
High-rate satellite manufacturing is not a solved problem. The production engineering challenges are real and have received significant investment. The systems engineering infrastructure to support that production — requirements management at scale, configuration tracking across variants, supplier interface management at commercial velocity — is less mature and less discussed.
The traditional space industry’s requirements management practices were designed for a context where cost dominated and schedule was secondary to technical rigor. That context still exists for many programs. But it does not describe a manufacturer building dozens of spacecraft per year on commercial timelines and margins.
The tooling gap is real. Organizations building graph-based, AI-assisted requirements management systems — architectures where requirements are connected artifacts rather than text in documents — are building infrastructure that matches the problem structure of high-rate manufacturing. The engineering teams at companies like Terran Orbital, and the primes now integrating those operations, need requirements management that is fast enough to support production decisions, connected enough to make change impacts visible, and rigorous enough to satisfy the verification demands of space hardware.
That combination has not historically existed in a single tool. Closing that gap is where the most consequential systems engineering innovation in the space industry is currently happening — and high-volume smallsat manufacturing is the stress test that makes the gap visible.