Systems Engineering at the Edge of Earth: How In-Space Manufacturers Are Reinventing Requirements
The Collision No One Fully Anticipated
When Varda Space Industries successfully re-entered its W-1 capsule in the Utah desert in 2024 — carrying ritonavir crystals grown in microgravity — it was celebrated as a milestone in commercial space. It was also a quiet demonstration of a systems engineering problem that nobody has cleanly solved: how do you apply the discipline of requirements management to a system that is simultaneously a spacecraft, a pharmaceutical manufacturing facility, and a supply chain node?
Aerospace systems engineering was built around a different set of assumptions. Vehicles are unique or produced in very small quantities. The customer is a government agency with defined verification procedures. Mission success is binary — the satellite works or it doesn’t. Every requirement traces to a safety case or a contract line item. The timeline is measured in years.
In-space manufacturing breaks every one of those assumptions. Companies like Varda Space, Space Forge (based in Cardiff, Wales), and Redwire Space are commercializing the microgravity environment to produce fiber optic preforms, pharmaceutical crystals, and compound semiconductor materials with properties that cannot be achieved on Earth. They are doing this commercially, meaning economics drive requirements as much as physics does. And they are doing it at scale — not as demonstration missions but as intended ongoing production operations.
The systems engineering challenges that result are genuinely novel, and how these companies navigate them will define whether in-space manufacturing becomes an industry or remains a collection of impressive demonstrations.
Production Rate Requirements: When Mission Cadence Becomes Manufacturing Throughput
Traditional aerospace systems engineering handles production rate as a business consideration upstream of the engineering problem. The requirements engineer defines what the satellite must do; procurement figures out how many to build. For in-space manufacturers, production rate is a first-order engineering requirement that drives everything downstream.
Consider Varda’s business model. The company is not selling spacecraft. It is selling microgravity-manufactured pharmaceutical ingredients. The economics only work if re-entry capsules fly frequently enough, carry enough product per mission, and return enough usable yield. That yield requirement — say, X kilograms of usable crystal per mission — propagates immediately into requirements on the manufacturing process (growth duration, chamber conditions, contamination control), requirements on the spacecraft (power budget, thermal stability, vibration isolation), and requirements on the re-entry system (g-load limits, thermal protection, recovery time).
This is manufacturing process engineering reasoning applied to a spacecraft system, and the two disciplines use different vocabulary for the same concepts. A manufacturing engineer thinks in terms of process capability indices, defect rates, and cycle time. An aerospace systems engineer thinks in terms of functional requirements, performance margins, and failure mode analysis. When these teams must derive requirements together, the interface is genuinely difficult.
Space Forge’s approach to in-space semiconductor manufacturing illustrates a further complication. Their target materials — compound semiconductors like gallium arsenide or gallium nitride grown in conditions unavailable on Earth — have highly variable yield depending on subtle process parameters. The requirements on the manufacturing module cannot be fixed at PDR because the process science is still maturing. Traditional aerospace development handles this through formal requirements change control, with every change requiring impact analysis across the full requirements tree. For a commercial manufacturer trying to iterate quickly on process parameters, that overhead is crippling.
The engineering response has been to partition the requirements architecture more aggressively than aerospace tradition suggests. Fixed requirements (structural loads, electromagnetic compatibility, re-entry trajectory) are held stable and managed with full rigor. Process requirements (growth temperature profiles, contamination thresholds, crystal geometry) are treated as a separate, more fluid tier with lighter-weight change management. This works, but it creates genuine traceability risk: a process requirement change that shifts power consumption can violate a fixed requirement on the power subsystem without the connection being visible if the requirements are managed in separate silos.
Product Quality Traceability: The Regulatory Void
When a semiconductor fab ships a wafer, it ships a data package: process traveler, metrology records, defect maps, chain of custody. When a pharmaceutical batch leaves a GMP facility, it carries a batch record with every critical process parameter documented against a validated process. When Varda’s capsule lands in Utah carrying ritonavir crystals, what documentation does it carry?
The honest answer is: whatever Varda decided to generate, because no external framework currently mandates it. The regulatory situation for space-manufactured goods is genuinely unresolved. The FDA has not established GMP standards for pharmaceutical ingredients manufactured in space. The FCC, FAA, and commercial space regulations address the launch and re-entry vehicle but not the product quality of what the vehicle carries. Semiconductor customers have their own incoming inspection requirements but no established protocols for space-manufactured material.
This regulatory vacuum creates a requirements engineering problem that is more serious than it first appears. When there is no external standard to flow down from, the requirements architect must generate acceptance criteria from first principles — and those criteria must be defensible to customers who are accustomed to regulated supply chains. A pharmaceutical company considering Varda-manufactured excipients needs to present those materials to the FDA. That means the traceability record for the space manufacturing process must ultimately satisfy FDA reviewers, even though the FDA has not yet told anyone what that means.
The practical consequence is that in-space manufacturers are over-engineering their data collection relative to current requirements and hoping the regulatory framework catches up. Redwire, which has extensive experience with in-space manufacturing experiments on the ISS, has built internal process documentation systems that draw on both aerospace mission data packages and pharmaceutical batch record concepts. It is bespoke, manual-intensive, and not portable to a customer’s quality management system without significant translation work.
This is the kind of problem that modern requirements and traceability infrastructure is positioned to address — but only if the tooling can represent process requirements, product quality attributes, and regulatory compliance requirements in a unified model rather than separate documents. Graph-based requirements tools that can model relationships between process parameters, product attributes, and external standards are meaningfully more useful here than flat document structures. Tools like Flow Engineering, which represent requirements as nodes in a connected graph rather than paragraphs in a Word document, allow teams to link a process temperature requirement directly to the product crystallinity attribute it controls and then to the customer acceptance criterion it must satisfy — making the traceability chain visible and queryable rather than reconstructed manually for each audit.
Re-Entry and Recovery: The Delivery Mechanism Is Part of the Product
In-space manufacturing is sometimes discussed as if the spacecraft is a neutral platform and the interesting engineering is in the payload. That framing underweights the re-entry and recovery system, which is not peripheral — it is the mechanism by which the manufactured product is delivered to the customer.
Varda’s W-2 and subsequent capsules must satisfy requirements that are simultaneously aerospace requirements (structural integrity through peak heating, parachute deployment reliability, landing load limits) and supply chain requirements (product containment, contamination prevention, temperature maintenance if relevant, recovery time from landing to handoff). These two requirement sets are not independent. The structural requirements for the heat shield drive mass and volume constraints on the capsule interior. The contamination prevention requirements for the product drive sealing and material selection requirements that interact with the thermal protection system.
The classic aerospace approach to this interface would be an ICD — interface control document — between the re-entry vehicle and the payload. But an ICD written by aerospace engineers in aerospace terms will not capture what a pharmaceutical or semiconductor customer actually needs. The customer cares about crystal integrity, contamination levels, and time from landing to characterization. Translating those customer needs into verifiable spacecraft-level requirements requires someone who understands both domains, and that person is rare.
Space Forge’s ForgeStar vehicle takes a different architectural approach: the entire manufacturing module re-enters, rather than separating a recovery capsule from a bus that stays on orbit. This simplifies the re-entry vehicle requirements in some ways (no separation event, no on-orbit servicing questions) but complicates the manufacturing module requirements significantly — every component must survive not only the microgravity manufacturing environment but also the thermal and mechanical loads of re-entry.
Both architectures ultimately require deriving re-entry system reliability requirements from manufacturing economics. If a mission failure destroys a product batch worth $10M and costs $15M to replace, the acceptable mission failure rate is a business calculation as much as a safety calculation. Aerospace programs are not accustomed to making explicit reliability-cost tradeoffs at the requirements level in quite this way. The result is that re-entry system requirements are sometimes underspecified relative to the economic risk they represent.
Requirements at the Intersection: What Breaks in Practice
The deeper problem is structural. Systems engineering as a discipline developed a set of practices — requirements decomposition, functional analysis, FMEA, verification planning — that assume a relatively clean boundary between the system being engineered and the world outside it. The system has requirements. The environment has constraints. Requirements are decomposed into subsystem requirements. Verification closes the loop.
In-space manufacturing, the system boundary is genuinely unclear. Is the manufacturing process part of the system? It has to be, because product quality requirements cannot be satisfied without controlling it. Is the regulatory framework part of the system? It effectively is, because requirements cannot be verified without knowing what the regulator will accept. Is the customer’s downstream process part of the system? It influences what product quality attributes actually matter.
Traditional document-based requirements management — a requirements specification document, a traceability matrix, an ICD binder — does not handle this well. The relationships are too complex and too dynamic. Requirements that look independent turn out to be coupled through physics that becomes apparent late in development. Regulatory requirements change as agencies start paying attention to in-space manufacturing. Customer needs evolve as they learn more about what microgravity-produced materials can do.
The practical response from engineering teams at these companies has been to invest in more sophisticated model-based and graph-based infrastructure for requirements management. The goal is not just to store requirements but to make the network of dependencies visible — so that when a process requirement changes, the team can immediately see what product attributes are affected, what verification activities need to be revisited, and whether any regulatory requirements are now at risk. Flow Engineering represents this type of approach: requirements as a connected graph, with AI-assisted analysis to surface non-obvious dependencies and flag requirements that are ambiguous or unverifiable. For engineering teams working at the intersection of multiple regulatory frameworks and multiple technical disciplines, that capability matters more than it does on a conventional program.
The Honest Assessment
In-space manufacturing is technically validated. The physics works. Companies have demonstrated that microgravity produces materials with properties unavailable on Earth, and at least some of those properties have commercial value. The engineering discipline has not caught up.
Systems engineering for in-space manufacturing needs to simultaneously borrow from aerospace systems engineering (for the spacecraft and re-entry systems), pharmaceutical process engineering (for product quality and traceability), and industrial manufacturing engineering (for production rate and yield economics). None of these disciplines alone provides the right framework. The tools most of these companies are using — adapted from aerospace or from manufacturing — were not designed for this intersection.
The companies that will succeed at industrializing space manufacturing are not just the ones that solve the materials science. They are the ones that build requirements infrastructure robust enough to hold the full problem together across disciplines, across regulatory frameworks, and across the fast iteration cycles that commercial economics demand. That infrastructure is not yet fully mature in any of the available tools, but the direction of travel — toward connected, model-based, AI-assisted requirements management — is clear. The alternative is what these companies are experiencing now: expensive late-program discoveries that things that looked like independent requirements were coupled all along.