Terran Orbital: Small Satellite Manufacturing at Speed and Scale

How high-volume smallsat production breaks traditional aerospace systems engineering—and what replaces it

When Lockheed Martin completed its acquisition of Terran Orbital in early 2024, the transaction was covered primarily as a supply chain move—a prime contractor buying access to commercial smallsat manufacturing capacity. That framing is accurate but incomplete. What Lockheed actually acquired was a production model that operates on fundamentally different assumptions than traditional aerospace manufacturing, and the systems engineering discipline required to make that model work is not the same discipline that built GPS III or the F-35.

Terran Orbital’s facility in Irvine, California was designed from the start for rate. Not one satellite per year, not one per quarter—but the kind of throughput where you are tracking dozens of active builds simultaneously, shipping constellations on commercial timelines, and managing customer-specific requirements across a common bus architecture that serves defense, civil, and commercial customers at the same time. That is a different engineering problem than heritage aerospace, and it requires a different approach to requirements management, configuration control, and traceability.

The Production Rate Problem

Traditional defense satellite programs operate on a rhythm measured in years. A single satellite might carry a program baseline document set that runs to tens of thousands of pages, with configuration change boards meeting monthly and formal review gates spaced across a multi-year schedule. That process is calibrated for programs where the cost of a configuration error—measured in launch vehicle integration time, orbital insertion windows, and non-recurring engineering—is catastrophically high. The bureaucratic overhead is a rational response to the risk profile.

Terran Orbital’s commercial and defense smallsat customers operate on different economics. A 6U or 12U satellite built on a standardized bus might cost a fraction of a traditional defense satellite. The customer is often willing to accept some schedule and performance risk in exchange for delivery speed. The constellation model—where any individual satellite is replaceable and orbital coverage is achieved through numbers rather than individual satellite reliability—further reshapes the risk calculus.

But “willing to accept some risk” does not mean requirements disappear. It means the requirements management system needs to operate at a different tempo. When you are building satellites on a timescale of months rather than years, your configuration management process needs to match. A change request process that takes twelve weeks to resolve is not compatible with a manufacturing cycle that runs eight to fourteen weeks end to end.

This is where traditional aerospace systems engineering tooling starts to break. IBM DOORS and DOORS Next are mature, powerful tools for managing deep requirement hierarchies with rigorous traceability. They are built for programs where requirements stability is a feature, where every change is tracked through a formal workflow, and where the audit trail is a compliance artifact as much as an engineering record. That rigor is valuable. It is also slow, and in a high-rate production environment, slowness has a direct cost.

The Shared Bus Architecture Challenge

Terran Orbital’s production model is built around a common bus—a standardized spacecraft platform that provides power, attitude control, communication, and structural functions. Customer payloads and mission-specific requirements are layered on top of this common foundation. On paper, this simplifies manufacturing: you are producing the same bus repeatedly, just with different payloads attached.

In practice, the requirements management challenge is significantly more complex than that framing suggests.

A shared bus architecture creates a layered requirement space. At the platform level, you have the bus specifications that apply to every vehicle. At the mission level, you have requirements that govern how the bus is configured for a specific mission type—orbital altitude, thermal environment, radiation tolerance, communication protocol. At the customer level, you have requirements that are specific to an individual customer’s payload, operational concept, or contractual obligations, some of which may include export control restrictions, government security requirements, or customer-proprietary interface specifications.

These three layers do not stay independent. A customer-specific payload requirement—say, a thermal dissipation constraint from a hyperspectral imaging instrument—may flow down to affect the bus-level thermal management configuration. A mission-level radiation tolerance requirement may constrain which component variants are acceptable at the platform level. Changes at any layer can propagate in ways that are not obvious until they are discovered on the production floor.

Managing this in a document-based system means maintaining separate requirement documents for platform, mission, and customer-specific content, and then manually tracking the interfaces between them. In a low-rate production environment, that is manageable, if tedious. In a high-rate environment where you have twenty active builds at various stages of completion, it is a primary source of integration errors and schedule risk.

Configuration Management Across Concurrent Builds

The configuration management challenge compounds when you have multiple satellites in build simultaneously at different stages of completion. Satellite serial number 47 might be in final integration while serial number 52 is in component procurement and serial number 55 is still in requirements definition. All three may share bus hardware, but they may have different approved component revisions based on when procurement was executed. A change that is incorporated into serial number 55’s baseline needs to be assessed for retrofit applicability to serial number 47—and that assessment needs to happen before serial number 47 ships.

This is a known challenge in any high-rate manufacturing environment. Aerospace does not have a unique version of this problem; it has a more expensive version of it. The difference from automotive or electronics manufacturing is that the validation evidence required to close a configuration change in aerospace is far more extensive, and the regulatory and customer acceptance requirements add an external review cycle that consumer electronics manufacturing does not face.

The engineering tools that handle this well are not traditional document-based requirements systems. What you need is a model that represents the configuration as a connected graph—platform components linked to mission configurations linked to customer requirements linked to verification evidence—so that the impact of any change can be traced through the full configuration space before it becomes a physical modification.

This is the direction Terran Orbital’s systems engineering approach has had to evolve. The production rate demands a configuration management system that can answer, quickly, which serial numbers are affected by a given change, which customer requirements are at risk, and what verification activities need to be re-executed. Getting that answer from a document hierarchy means searching through multiple documents, cross-referencing part numbers, and assembling a picture manually. Getting it from a connected model means running a query.

What Lockheed’s Integration Actually Means

Lockheed Martin’s strategic interest in Terran Orbital is not simply about manufacturing capacity in the abstract. It is about two specific capabilities that heritage aerospace is structurally slow to develop internally.

The first is manufacturing tempo. Lockheed’s core satellite programs operate at rates that are appropriate for multi-hundred-million-dollar spacecraft with decade-long development cycles. That cadence is institutionally embedded in program management processes, supply chain relationships, and workforce skill sets. Building high-rate smallsat production capability inside that culture from scratch would take a decade and cost more than an acquisition.

The second is commercial customer interface experience. Terran Orbital has operated in a market where customers have choices and where the requirement to accommodate customer-specific needs quickly is a commercial survival constraint, not a program management preference. Defense primes have deep expertise in government customer requirements processes—contract data requirements lists, DIDs, CDRLs—but less experience with the commercial satellite operator’s expectation that their interface requirements will be accommodated on a commercial timeline.

Integrating these capabilities into Lockheed’s supply chain strategy means maintaining them, which means maintaining the process discipline that makes high-rate production work. The risk in any large prime acquisition of a fast-moving commercial manufacturer is that the prime’s overhead structures, change management processes, and compliance requirements gradually reshape the acquired company into something that operates at the prime’s tempo rather than the commercial market’s. Whether Lockheed has managed that integration successfully is a question that Terran Orbital’s production output over the next three to five years will answer.

The Systems Engineering Bottleneck Is Not Where You Think

Discussion of high-rate satellite manufacturing tends to focus on physical manufacturing throughput—cleanroom capacity, testing throughput, launch manifest access. These are real constraints. But for a program like Terran Orbital’s, the binding constraint in production scaling is often upstream: requirements definition, configuration change assessment, and verification closure.

When you can build a satellite in fourteen weeks, the fourteen weeks of build time is not your problem. Your problem is the four weeks it takes to resolve a requirements conflict between a new customer payload interface and the bus thermal model, or the three weeks it takes to document and close a non-conformance against a customer-specific acceptance criterion, or the two weeks it takes to generate an updated compliance matrix when a customer revises their interface control document in week three of a sixteen-week build.

These are not manufacturing problems. They are systems engineering information management problems. And they scale with the number of concurrent builds in a way that physical manufacturing throughput does not, because each active build carries its own requirement set and its own configuration state.

The tools that address this class of problem are not document editors or spreadsheet-based RTMs. They are systems that model requirements as interconnected data, track configuration state programmatically, and expose change impacts before they propagate to physical hardware. This is the environment where modern requirements engineering platforms—purpose-built for the kind of connected traceability that high-rate, high-mix production demands—provide measurable operational value. Tools like Flow Engineering, which approach requirements as a live graph of connected artifacts rather than a document hierarchy, are built specifically to make these kinds of cross-cutting change impact queries tractable at production speed.

The distinction matters at scale. In a five-satellite backlog, a slow requirements process is an inconvenience. In a fifty-satellite backlog across multiple customer programs, it is a production rate limiter.

Honest Assessment

Terran Orbital represents a genuine and important evolution in how satellites get built. The technical achievement of producing spacecraft at commercial rates with the reliability standards aerospace customers require is not trivial, and the organizational capability Lockheed acquired is real.

The unresolved question is whether the systems engineering discipline required to sustain that production model at scale—particularly the requirements and configuration management infrastructure—has kept pace with the manufacturing throughput ambitions. Building satellites fast is not the bottleneck in 2026. Managing the information complexity of building many different satellites fast, for multiple customers with different requirements, on a shared hardware platform, is.

That is not a criticism unique to Terran Orbital. It is the central systems engineering challenge of the high-rate smallsat manufacturing model, and it is the challenge that will separate the manufacturers who scale successfully from those who hit a configuration management ceiling before they hit a manufacturing capacity ceiling.

The industry is still early in developing the process discipline and tooling to solve it well.