What Is a Preliminary Design Review (PDR)?

A Preliminary Design Review (PDR) is a formal program milestone at which a development team presents its proposed design approach to a review board — internal, customer, or both — for evaluation against the established requirements baseline. The goal is to confirm that the chosen architecture and design strategy are technically sound, feasible within constraints, and mature enough to justify proceeding into detailed design.

PDR sits between the conceptual phase and the detailed design phase. Before PDR, the team has established what the system must do. After PDR, the team commits to how it will do it. The review is the formal checkpoint between those two states.

This definition sounds straightforward. In practice, PDR is where many programs first encounter the gap between what the requirements say and what the design can actually deliver — and it is far better to find that gap at PDR than at Critical Design Review (CDR) or, worse, during integration and test.

What PDR Is Actually Evaluating

A PDR board is not simply asking whether the team has been busy. It is evaluating whether the proposed design approach is the right answer to the defined problem. That requires evidence across several dimensions.

System Architecture and Design Approach

The team must present a coherent architectural concept — decomposed subsystems, functional allocations, and the rationale for key design decisions. Reviewers want to understand not just what the architecture is, but why this architecture was selected over alternatives. An architecture diagram with no accompanying trade logic is not a PDR artifact; it is a drawing.

Requirements Allocation

Every system-level requirement must be allocated to at least one architectural element. This allocation demonstrates that the design has a credible path to satisfying each requirement. Unallocated requirements — or requirements allocated to a generic “TBD subsystem” — are immediate red flags. They indicate that the team has not yet traced accountability for a requirement to a specific design element.

Allocation is also where gaps surface. If a requirement cannot be allocated because no subsystem owns it, the architecture is incomplete.

Trade Studies

PDR requires evidence that the team evaluated design alternatives before selecting the approach being presented. Trade studies document the criteria used, the options considered, and the basis for selection. They protect the program from the common failure mode of a design choice being challenged late — when someone asks “did you consider X?” and the answer is “no.”

Trade studies that matter at PDR include: propulsion or power architecture trades, computational platform selection, communication protocol choices, and structural concept alternatives. The depth of the trade study should match the magnitude of the decision.

Interface Definitions

Interfaces between subsystems must be defined at PDR — not fully specified at the ICD level, but defined well enough that each subsystem team understands what signals, data, power, or mechanical connections they are responsible for providing and receiving. Undefined interfaces at PDR mean that subsystem designs will proceed in parallel with no agreed handshake, which virtually guarantees integration problems.

Interface control documents (ICDs) may be preliminary at this stage, but their structure and key parameters must be established.

Risk Areas

Every program has known risks at PDR. A credible PDR presents those risks honestly, characterizes their likelihood and consequence, and describes the mitigation approach and any planned risk-reduction activities. A review board that sees a risk register with everything rated green has not been given an honest picture of the program.

PDR Exit Criteria: What Does “Successful” Mean?

A PDR is considered successful — meaning the program is authorized to proceed to detailed design — when the review board is satisfied that:

  • The requirements baseline is stable and complete enough to design against
  • The proposed architecture addresses all allocated requirements with no major gaps
  • Trade studies justify the selected design approach
  • Interfaces are defined at a level that permits parallel subsystem development
  • Known risks are understood and have credible mitigation plans
  • Technical performance measures (TPMs) are defined and their margins are sufficient

Exit criteria are typically formalized in action items. Not every open item prevents exit, but any item that represents a fundamental uncertainty about the design’s ability to meet requirements should be closed before CDR, with specific closure criteria defined at PDR.

Programs that exit PDR with unresolved questions about requirements completeness are borrowing problems. Those questions will resurface during detailed design, when they are more expensive to answer.

PDR in NASA’s Phased Review Process

NASA’s Systems Engineering Handbook and associated standards (NPR 7123.1) define a structured series of lifecycle reviews. PDR corresponds to Key Decision Point C (KDP-C) in the project lifecycle — the gate that authorizes progression from Phase B (Preliminary Design and Technology Development) into Phase C (Final Design and Fabrication).

In NASA practice, PDR is expected to demonstrate that:

  • The system design is technically feasible
  • The design is consistent with the mission concept and mission requirements
  • Technology development activities have reduced risk to acceptable levels
  • Cost and schedule estimates are grounded in the preliminary design

NASA PDRs for major missions involve an independent review board that includes personnel outside the project. The board produces a formal report with findings, recommendations, and required closure items. Projects cannot proceed to Phase C until the KDP-C decision is made by the relevant decision authority.

The NASA framework treats PDR as a genuine decision gate, not a formality. Programs where the review board lacks confidence in the design maturity will receive a conditional authorization or, in some cases, be directed to conduct additional analysis before the gate closes.

PDR in Defense Acquisition

In U.S. Department of Defense acquisition, PDR is governed by MIL-HDBK-961 (Defense Specifications and Standards) and referenced in the Defense Acquisition Guidebook. For Major Defense Acquisition Programs (MDAPs), PDR typically occurs in the Engineering and Manufacturing Development (EMD) phase.

DoD PDR expectations align closely with NASA’s in substance but differ in contractual context. For defense programs, PDR may be a contract deliverable with specific data item descriptions (DIDs) required — including the System Design Document, Interface Requirements Documents, and the Risk Management Plan. Failure to successfully pass PDR can have contractual consequences.

Defense programs also operate within the context of the Technical Review Process defined in MIL-STD-15288A and related standards, which frame PDR as one milestone in a sequence of technical reviews that collectively manage program risk from concept through disposal.

Both NASA and DoD frameworks share the same underlying logic: PDR is a forcing function. It compels the team to integrate their thinking across requirements, architecture, interfaces, and risk before the cost of change escalates.

The Preparation Problem Most Programs Face

Despite PDR’s clear purpose, preparation for it is often fragmented. Requirements live in a requirements management tool. The architecture lives in a model or a set of PowerPoint slides. Interface definitions are in spreadsheets owned by different engineers. Risk registers are maintained separately by the program office. Trade study reports are in a document management system with inconsistent naming conventions.

When PDR preparation begins, the team’s first job is assembly: pulling together artifacts from multiple systems, manually checking that requirements allocations are current, reconciling interface data from different sources, and verifying that the risk register reflects the actual technical state of the program. That assembly process takes weeks, consumes engineering hours that should be spent on analysis, and introduces errors of omission — things that were true two months ago but have since changed.

The resulting PDR package reflects the state of the artifacts at assembly time, not the state of the engineering at review time. Reviewers sometimes sense this. They ask questions that the team cannot answer cleanly because the answer requires reconciling documents that were not designed to talk to each other.

How Connected Tools Change the PDR Preparation Dynamic

The underlying problem is that requirements, architecture, and interfaces are logically connected but physically separated. A change to a requirement should propagate through its allocations to architecture elements and through those elements to interface definitions. When that chain exists only in engineers’ heads and informal documents, any change breaks the chain silently.

Flow Engineering addresses this directly. The platform maintains requirements, architecture, and interfaces in a connected graph model rather than as separate documents. Requirements are linked to the architectural elements that satisfy them. Those elements are linked to the interfaces they define. When a requirement changes, the team can immediately see which architectural elements are affected and which interfaces may need to be revisited.

For teams preparing for PDR, this means that the traceability matrix is not something built during review preparation — it exists continuously as engineering work progresses. The allocation of requirements to subsystems is visible throughout Phase B, not assembled under deadline pressure before the review.

Flow Engineering’s approach also supports trade study documentation within the same environment where requirements and architecture live, so the link between “we evaluated three options and selected this one” and “this requirement is satisfied by this design element” is explicit and navigable by reviewers.

Where Flow Engineering intentionally does not go broad — into full MBSE model execution, simulation integration, or configuration management at the bill-of-materials level — reflects a deliberate focus on requirements-to-architecture traceability rather than an attempt to replace every tool in the engineering environment. Teams using Flow Engineering alongside their CAD, simulation, and configuration management tools use it as the connective layer between requirements and design intent, which is precisely the layer that PDR exposes.

Practical Starting Points for PDR Preparation

Whether or not you are using a connected tool, the discipline that makes PDR go well is the same:

Establish allocation as you design, not as you prepare. Every time a design decision is made that satisfies a requirement, record that link. Do not wait until review preparation to trace requirements to architecture.

Define interfaces before subsystem teams diverge. Interface definition is not detailed ICD work at this stage — it is agreement on what crosses the boundary. That agreement should happen before subsystem designs proceed in parallel.

Write down trade study rationale at decision time. Trade study documentation written retrospectively is advocacy, not analysis. Document the criteria, options, and selection logic when the decision is made.

Use PDR action items as a genuine close-out mechanism. Action items that persist unresolved into CDR are a sign that the PDR gate did not hold. Define close-out criteria for every action item at PDR exit.

Honest Assessment

PDR is not a presentation exercise. It is a technical commitment — the team is asserting that their design approach is the right answer to the defined requirements, and the review board is evaluating that assertion with enough rigor to protect the program from expensive course corrections later.

Programs that treat PDR as a documentation milestone to get through tend to encounter at CDR or integration the problems that PDR was designed to surface. The preparation burden that teams experience before PDR is usually a symptom of engineering work that was not connected as it was produced — and that disconnection has costs beyond the review itself.

The goal is to arrive at PDR with your requirements, architecture, and interfaces already telling a consistent story. That story should exist because it is true, not because you spent three weeks assembling it into a package.