Spacecraft Design II: Common Mistakes and Misconceptions

Abstract

Spacecraft design follows a structured lifecycle with formal checkpoints designed to catch errors early, when they are least costly to fix. This article examines three pervasive misconceptions about the design review process and the role of baselines in spacecraft development, drawing on systems engineering best practices. By clarifying the purpose and timing of key reviews—and the distinction between provisional documentation markers—we can better understand why the V-diagram structure exists and how to avoid expensive rework.

Background

The spacecraft design process is governed by a hierarchical framework that decomposes mission needs into progressively detailed specifications, then reintegrates and verifies the result ^{[system-engineering-v-diagram]}. This bidirectional structure—decomposition on the left, integration and verification on the right—ensures that every requirement has a corresponding verification activity and that nothing is lost in translation.

Within this lifecycle, several formal design reviews serve as quality gates. Each review occurs at a specific maturity level and addresses distinct concerns:

• System Requirement Review (SRR): Validates that high-level mission needs have been correctly translated into derived system requirements ^{[system-requirement-review]}
• System Design Review (SDR): Evaluates how system requirements have been allocated to subsystems and assesses manufacturing feasibility ^{[system-design-review]}
• Preliminary Design Review (PDR): Confirms the proposed design approach is feasible and mature enough to justify detailed design work ^{[preliminary-design-review]}
• Critical Design Review (CDR): Certifies that the detailed design is complete, correct, and ready for manufacturing ^{[critical-design-review]}

After CDR approval, the design is frozen into the build-to baseline ^{[build-to-baseline]}—the authoritative set of specifications that governs all manufacturing and assembly activities.

Key Results: Three Common Misconceptions

Misconception 1: PDR and CDR Are Interchangeable Checkpoints

The mistake: Many engineers treat PDR and CDR as similar reviews, differing only in timing. In reality, they address fundamentally different design maturity levels and serve distinct purposes.

PDR occurs when preliminary designs for all major subsystems are complete ^{[preliminary-design-review]}. At this stage, trade studies have been conducted, candidate technologies selected, and the overall design strategy is locked down. The review confirms feasibility and justifies proceeding to detailed design—but detailed design has not yet been completed.

CDR occurs after detailed design is finished ^{[critical-design-review]}. Every component, interface, and specification is fully defined. The review certifies that the design is correct, producible, and ready for manufacturing. After CDR, the design is frozen and becomes the build-to baseline.

The consequence of confusing these reviews is attempting to lock down detailed specifications at PDR or, conversely, allowing major design changes after CDR. The former creates false confidence in incomplete work; the latter incurs exponentially higher costs because manufacturing tooling, procurement, and production schedules have already been committed.

Misconception 2: TBD and TBC Are Synonymous

The mistake: Design documents often use TBD (To Be Decided) and TBC (To Be Confirmed) interchangeably, but they signal fundamentally different states of uncertainty.

TBD indicates that a decision has not yet been made ^{[to-be-decided-tbd]}. The choice itself is pending—the outcome is genuinely uncertain. TBC indicates that a value or item is expected to be confirmed later, but the decision-making process is not in question ^{[to-be-confirmed-tbc]}. For example, a component's exact performance specification might be TBC pending vendor testing, but the decision to use that component class is already made.

This distinction matters because TBDs represent active risk. Unresolved decisions cascade into schedule delays and design conflicts. CDR requires that TBDs be minimized and justified; TBCs, by contrast, are acceptable if the confirmation path is clear and the impact of the eventual value is bounded.

Conflating the two obscures which items require decision-making effort versus which items simply need confirmation of an already-chosen direction.

Misconception 3: The Build-to Baseline Is a Living Document

The mistake: Some teams treat the build-to baseline as a document that evolves throughout manufacturing and assembly. In fact, the baseline is locked at CDR and changes only through formal change control.

The build-to baseline is the approved, detailed set of hardware and software specifications established at CDR ^{[build-to-baseline]}. Once approved, it becomes the single source of truth for manufacturing and assembly teams. All drawings, specifications, and interface definitions are controlled through formal change management processes.

This is not a bureaucratic inconvenience—it is essential for configuration integrity. A "living" baseline creates ambiguity about what was actually designed versus what was built, breaks traceability from requirements to product, and makes it impossible to audit whether the spacecraft meets its original specifications.

The cost of changes increases dramatically after CDR because they may require rework of manufacturing plans, tooling, and already-produced components. This is why the design review process is structured to catch errors before CDR, not after.

Worked Example: Recognizing Misconception in Practice

Consider a spacecraft power subsystem design at PDR. The preliminary design specifies a solar array with a nominal power output of 5 kW at end-of-life, based on trade studies comparing array size, mass, and cost. The design approach is sound and feasible.

However, the exact cell efficiency and degradation model are marked TBC—pending final vendor data. This is appropriate at PDR because the decision to use a particular cell type has been made; confirmation of its performance parameters will follow.

Now suppose the same subsystem arrives at CDR with the cell efficiency still marked TBD. This is a red flag. The decision about which cell type to use should have been finalized during detailed design. A TBD at CDR indicates that a fundamental choice is still pending, which means the design is not actually complete. CDR should not be approved until this decision is made and the specification is locked.

Conversely, if the cell efficiency is TBC at CDR with a clear confirmation path (e.g., "vendor will provide test data by week 10 of manufacturing"), this may be acceptable if the range of possible values does not affect downstream subsystem designs or if contingency margins are sufficient.

The distinction between TBD and TBC, applied rigorously, prevents the common failure mode of approving a design that appears complete but actually contains unresolved decisions.

References

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

AI Disclosure

This article was drafted with the assistance of an AI language model based on personal class notes from Spacecraft Design II. The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims are cited to source notes and reflect the course content. The author retains responsibility for accuracy and interpretation.