Spacecraft Design II: Underlying Assumptions and Validity Regimes

Abstract

Spacecraft design education typically presents a linear progression through design reviews and baselines, but this framing obscures critical assumptions about when decisions are reversible, what "completeness" means at each phase, and which cost drivers dominate at different lifecycle stages. This article examines the underlying validity regimes of the spacecraft design process—the conditions under which standard design review gates and baseline-locking practices actually minimize total program cost and risk. We argue that the V-diagram framework ^{[system-engineering-v-diagram]} is not a universal prescription but rather a risk-mitigation strategy optimized for specific project contexts, and that understanding these contexts is essential for applying design methodology appropriately.

Background

The spacecraft design curriculum typically presents the design process as a sequence of formal reviews: System Requirement Review (SRR) ^{[system-requirement-review]}, System Design Review (SDR) ^{[system-design-review]}, Preliminary Design Review (PDR) ^{[preliminary-design-review]}, and Critical Design Review (CDR) ^{[critical-design-review]}. Each review gates progression to the next phase, and each phase produces a baseline—culminating in the build-to baseline ^{[build-to-baseline]} that locks all specifications for manufacturing.

This structure is presented as best practice, but it rests on several implicit assumptions:

1. Cost monotonicity: Changes become exponentially more expensive as the project advances.
2. Requirements stability: Mission needs and constraints are sufficiently well-understood early to support detailed decomposition.
3. Design coupling: Subsystems are tightly coupled, so early architectural decisions constrain later choices.
4. Manufacturing dominance: The largest cost driver is manufacturing and assembly, not design iteration or technology maturation.

These assumptions are not universal. Understanding when they hold—and when they fail—is essential for applying design methodology appropriately.

Key Results

The Cost-of-Change Assumption

The standard justification for locking baselines early is that changes become exponentially more expensive as the project progresses. This is true within a given design approach, but it assumes the design approach itself is sound. If the approach is fundamentally flawed—if a subsystem cannot meet its requirements, or if an interface assumption was wrong—then the cost of discovering this at CDR (when manufacturing tooling may already be committed) vastly exceeds the cost of discovering it at PDR.

The V-diagram framework ^{[system-engineering-v-diagram]} mitigates this risk by requiring that every requirement defined on the left side (decomposition) have a corresponding verification activity on the right side (integration and testing). This traceability prevents requirements from being lost and ensures that design decisions are validated before they propagate downstream. However, this framework is most effective when:

• Requirements are stable and well-understood before detailed design begins.
• The design team has sufficient experience with similar systems to make sound architectural choices.
• Manufacturing processes are mature and well-characterized.

In domains where these conditions do not hold—such as novel spacecraft architectures, new propulsion technologies, or missions with unprecedented operational constraints—the standard review sequence may create false confidence in designs that have not been adequately validated.

Baseline Locking and Configuration Control

The build-to baseline ^{[build-to-baseline]} is established at CDR and serves as the authoritative reference for manufacturing. Once approved, all changes are controlled through formal change management to maintain configuration integrity. This practice is sound when:

• The design is sufficiently mature that changes are truly exceptional.
• Manufacturing is the dominant cost driver.
• The project has sufficient schedule margin to absorb the overhead of change control.

However, in projects where design maturity is uncertain or where technology is still being validated, aggressive baseline locking can create a false sense of control. A locked baseline that contains unresolved technical risks (marked as TBD ^{[to-be-decided-tbd]} or TBC ^{[to-be-confirmed-tbc]}) is not actually locked—it is a placeholder that will require rework once the TBDs are resolved.

The Role of Design Reviews as Risk Gates

Each design review serves a specific risk-reduction function:

• SRR ^{[system-requirement-review]} validates that derived requirements properly decompose mission objectives. It catches misinterpretations early, when changes are least costly.
• SDR ^{[system-design-review]} evaluates the high-level architecture and requirement allocation. It ensures the proposed decomposition is sound before detailed design begins.
• PDR ^{[preliminary-design-review]} demonstrates that the design approach is feasible and mature enough to justify detailed design. It is the last major review before the design is "locked down."
• CDR ^{[critical-design-review]} certifies that the detailed design is complete, correct, and ready for manufacturing. It is the final opportunity to catch design errors before manufacturing costs are incurred.

These reviews are effective risk gates when the review criteria are rigorous and the decision to proceed is genuinely contingent on the review outcome. However, reviews can become pro-forma exercises if:

• The project has already committed to a schedule that does not allow for major redesign.
• The review criteria are vague or not enforced consistently.
• There is organizational pressure to proceed regardless of review findings.

In such cases, the reviews provide the appearance of risk management without the substance.

Validity Regimes and Design Methodology Selection

The standard spacecraft design process is optimized for programs where:

1. Requirements are stable and well-understood before detailed design.
2. The design team has significant experience with similar systems.
3. Manufacturing is the dominant cost driver.
4. Schedule is less constrained than budget.
5. The project can afford the overhead of formal reviews and change control.

In this regime, the V-diagram framework and baseline-locking practices minimize total program cost by preventing costly downstream rework.

However, in programs where:

1. Requirements are uncertain or evolving.
2. Technology is novel or immature.
3. Design iteration is the dominant cost driver.
4. Schedule is more constrained than budget.
5. The project cannot afford the overhead of formal reviews.

A more iterative, spiral-based approach may be more appropriate. In such programs, the goal is to reduce technical risk through rapid prototyping and testing, rather than to prevent downstream rework through early baseline locking.

The key insight is that no single design methodology is universally optimal. The choice of methodology should be driven by an explicit assessment of which risks dominate the program and which cost drivers are most significant.

Worked Example: Technology Maturation vs. Manufacturing Cost

Consider two spacecraft programs:

Program A: A communication satellite using mature, flight-proven subsystems. Requirements are well-understood, and the design team has built similar satellites. The dominant cost driver is manufacturing and assembly. In this case, the standard design review sequence is appropriate. Early baseline locking prevents costly manufacturing rework and ensures configuration control.

Program B: An experimental spacecraft using a novel propulsion system that has never been flight-tested. Requirements are uncertain because the propulsion system's actual performance is unknown. The design team has limited experience with this technology. The dominant cost driver is design iteration and technology maturation, not manufacturing. In this case, a more iterative approach is appropriate. The program should invest in ground testing and prototype development to validate the propulsion system before committing to a detailed design. Aggressive baseline locking would lock in design decisions based on uncertain assumptions about propulsion performance, creating high risk of costly redesign.

The two programs require different design methodologies because they face different dominant risks.

References

• ^{[system-engineering-v-diagram]}
• ^{[system-requirement-review]}
• ^{[system-design-review]}
• ^{[preliminary-design-review]}
• ^{[critical-design-review]}
• ^{[critical-design-review]}
• ^{[preliminary-design-review]}
• ^{[build-to-baseline]}
• ^{[build-to-baseline]}
• ^{[to-be-decided-tbd]}
• ^{[to-be-confirmed-tbc]}

AI Disclosure

This article was drafted with AI assistance. The structure, argumentation, and synthesis of concepts across multiple source notes were performed by Claude (Anthropic). All factual claims and citations to source material have been verified against the provided notes. The author is responsible for the validity of the underlying course notes and for any errors in interpretation or application.