The Review That Separates Thinking from Doing
Preliminary Design Review (PDR) occupies a precise location in a program’s lifecycle: it sits after the system architecture has been established and before detailed design work — circuit schematics, FPGA logic, mechanical tolerances, software module design — begins in earnest. The review’s job is to answer one question with documented evidence: Is the architecture stable enough that detailed design work can proceed without structural rework?
That question sounds simple. In practice, it is one of the hardest engineering management problems in hardware development, because the answer requires demonstrating not just that a design exists, but that it is complete enough and coherent enough at the system level. Reviewers — whether internal chief engineers, government program offices, or certification authorities — are looking for a specific kind of argument, built from a specific set of artifacts. Teams that treat PDR as a design presentation tend to fail it. Teams that treat it as an evidence package tend to pass.
This article defines PDR precisely, positions it against the other major program reviews, describes what a credible PDR package actually contains, and explains how modern requirements and traceability platforms help engineering teams build that evidence before the review clock runs out.
What PDR Is, Precisely
PDR is a formal program milestone at which the customer, program office, or internal review authority confirms that:
- The system-level requirements are stable, complete, and allocated to subsystems.
- The selected architecture satisfies those requirements and has been analyzed sufficiently to support detailed design.
- Key technical risks have been identified and have credible mitigation plans.
- Interfaces between subsystems are defined well enough that parallel detailed design work can begin without creating integration conflicts later.
The word preliminary does not mean incomplete or immature. It means the design is at the architecture level of fidelity, not the detail level. A PDR-ready design has resolved “what the system does and how it is structured” well enough that teams can be dispatched to design individual components in parallel. What it has not yet produced is the full bill of materials, the final tolerance stack, or the verified software architecture.
PDR is sometimes confused with a checkpoint where a program gets permission to spend money. That framing is partly true in government programs — passing PDR typically unlocks the budget for detailed design — but it misses the engineering purpose. PDR is a risk gate. Its function is to prevent teams from spending months on detailed design work that later gets invalidated by an architectural flaw that a rigorous review would have caught.
The Review Family: SRR, PDR, CDR, PRR
PDR makes the most sense when positioned against the other major reviews in a hardware program. The four canonical milestones form a commitment chain, where each review closes off a category of design freedom:
System Requirements Review (SRR)
SRR validates that the system requirements are complete, testable, and traceable to the customer’s needs. At SRR, there may be no architecture at all — the review is about whether the problem is defined well enough to begin architecture work. Key questions: Are all stakeholder needs captured? Are the requirements unambiguous and verifiable? Are derived requirements justified?
What SRR closes off: The requirements space. After SRR, scope changes become formal change requests with cost and schedule impacts.
Preliminary Design Review (PDR)
PDR validates that the architecture is mature enough for detailed design. By this point, requirements must be allocated to subsystems, key design trades must be resolved, and interface control documents (ICDs) must be in draft form. Key questions: Does the architecture satisfy the allocated requirements? Are interfaces well enough defined for parallel work? Have critical risks been identified and bounded?
What PDR closes off: The architectural solution space. After PDR, changing the fundamental architecture is a major replanning event.
Critical Design Review (CDR)
CDR validates that the detailed design is complete and ready for fabrication. By CDR, schematics, drawings, software design documents, and analysis reports must demonstrate that the design meets requirements. Key questions: Is every requirement met by a specific design element? Have analyses (thermal, structural, EMC, timing) been completed? Is the design producible?
What CDR closes off: The detailed design. After CDR, design changes become engineering change proposals (ECPs) with formal configuration control.
Production Readiness Review (PRR)
PRR validates that the manufacturing and quality processes are ready to produce the system at the required quantity and quality. This review is more process-focused than design-focused. Key questions: Are production processes validated? Is supplier quality controlled? Are acceptance test procedures complete?
What PRR closes off: Production planning. After PRR, process changes require formal disposition.
The progression matters because reversals become exponentially more expensive as programs advance. A requirements change caught at SRR costs hours. The same change caught at CDR costs weeks. Caught after first article production, it can cost programs.
What a Credible PDR Package Requires
A PDR package is not a slide deck explaining the design. It is a structured set of evidence artifacts that allow reviewers to independently verify that PDR entrance criteria have been met. Below are the artifact categories that credible PDR packages contain — and what reviewers actually look for in each.
1. Requirements Baseline with Completeness Evidence
The system specification must be at a stable, controlled baseline. “Stable” means change-controlled, not frozen forever — but it means the requirements cannot be in active flux during detailed design without a formal change process.
Reviewers look for: a requirements count by type and subsystem, a completeness argument explaining why no additional functional requirements are anticipated, and evidence that all requirements are verifiable (i.e., each has an identified verification method: test, analysis, inspection, or demonstration).
The most common PDR failure here is a requirements document with large numbers of TBD (To Be Determined) or TBR (To Be Resolved) placeholders. Programs typically set a threshold — often fewer than 5% of requirements may carry TBDs at PDR — and teams that exceed it are sent back.
2. Requirements Allocation Matrix
Every system-level requirement must be allocated to at least one subsystem or component. This allocation is the architectural argument: it proves that every function and constraint the system must satisfy has been assigned to a design element responsible for satisfying it.
Reviewers look for: a requirements allocation matrix (RAM) or functional allocation table showing the mapping from system requirements to subsystem requirements, with no orphaned requirements (system-level requirements with no allocation) and no orphaned subsystems (design elements with no requirements assigned to them).
Gaps in allocation are the second most common PDR failure mode. They signal that either the architecture is incomplete or the requirements-to-design connection has not been worked.
3. Architecture Description and Trade Study Evidence
The architecture block diagram, functional decomposition, and operational concept description need to be present — but reviewers expect more than pictures. They expect evidence that the selected architecture was chosen over alternatives based on analysis.
Reviewers look for: trade study reports documenting the alternatives considered and the criteria used to select the baseline architecture. The selection criteria should trace back to requirements. An architecture chosen for reasons that do not connect to requirements is a red flag.
4. Interface Definition Documents (ICDs) or Interface Control Documents
Interfaces between subsystems — electrical, mechanical, thermal, software, data — must be defined at PDR to allow parallel detailed design to begin without integration risk. ICDs at PDR are typically at “draft” or “preliminary” status, but they must be specific enough to bind the interface.
Reviewers look for: a complete list of all system interfaces, a status on each ICD (preliminary, approved, TBD), and a plan for resolving any interfaces still marked TBD. Fully undefined interfaces at PDR signal that parallel design work will produce components that cannot be integrated.
5. Risk Register with Mitigations
PDR is a risk gate. The program must demonstrate that it knows what could go wrong and has a credible plan for each risk.
Reviewers look for: a risk register that covers technical risks (design risks, technology readiness risks), schedule risks, and cost risks, each with a probability and consequence rating, a mitigation action, and an owner. Risks labeled “accept” with no mitigation plan are scrutinized heavily. A program that has not yet identified its critical risks is, by definition, not ready for PDR.
6. Verification and Validation (V&V) Planning
At PDR, the full verification plan does not need to be complete, but the program must demonstrate a credible path to verifying every requirement. This includes the test concept for critical requirements and any analysis-based verification approaches.
Reviewers look for: a preliminary test plan or verification plan that assigns a verification method to every requirement class, and identifies any requirements that will be difficult or expensive to verify — because those are typically the ones that get changed to “verified by analysis” without proper justification, which is a certification risk.
How Modern Platforms Build PDR Evidence Continuously
The artifact categories above share a structural problem: they are all interconnected. A requirements change affects allocation, which affects the ICDs, which affects the risk register. In programs that manage these artifacts in separate documents — spreadsheets, Word files, configuration-managed but disconnected — keeping the connections consistent requires enormous manual effort. Teams often fall behind on traceability, then sprint to reconstruct it before the review, producing evidence that reviewers can tell is backfilled.
The alternative is a requirements and traceability platform that maintains these connections as a live model throughout the program. This is where structured, graph-based tools have changed how programs approach PDR readiness.
Flow Engineering (flowengineering.com) is built specifically for this problem in hardware and systems engineering teams. Its graph-based data model treats requirements, subsystems, interfaces, and verification methods as nodes with explicit, typed relationships between them. When a requirement is allocated to a subsystem, that allocation is a first-class object in the model — not a cell in a spreadsheet that someone has to remember to update.
This matters at PDR because the allocation matrix is not a separate artifact that has to be assembled from requirements documents and architecture documents. It is a live query against the model. Teams can ask, at any point during development: Which system requirements have no subsystem allocation? The answer is available in seconds, not after a weekend of spreadsheet work. Requirements completeness — TBDs, unverified requirements, unallocated requirements — becomes a dashboard metric rather than a pre-review audit.
Flow Engineering also models interfaces explicitly, connecting interface definitions to the requirements they satisfy and the subsystems they bound. When an interface changes, the platform makes the downstream impact on requirements and allocations visible immediately. This is the kind of impact analysis that programs running document-based toolchains try to do manually and frequently miss.
The practical effect is that PDR readiness becomes a continuous state. Teams can run a PDR readiness check at any sprint boundary, identify the gaps — open TBDs, unallocated requirements, interface stubs without definitions — and close them incrementally. By the time the review date arrives, the evidence package is not being assembled; it is being extracted from a model that has been maintained throughout development.
This is a different posture than the traditional approach, where PDR readiness is assessed a few weeks before the review and deficiencies are corrected under pressure. Under pressure is when mistakes happen, and when reviewers see backfilled traceability that does not hold up to scrutiny.
Practical Starting Points for PDR Preparation
For teams preparing for an upcoming PDR, or establishing processes for a program in early phases, the following steps are operationally concrete:
Start with a requirements count and TBD audit. Know how many requirements you have, what percentage carry TBDs, and what the closure plan for each TBD is. If you cannot answer this in an hour, your requirements management tooling is working against you.
Build your allocation matrix before you finalize your architecture. Allocation drives architecture verification, not the other way around. If you are doing the allocation after the architecture is drawn, you may find requirements that the architecture does not cover — and it is better to find them before PDR than during it.
Treat interfaces as requirements artifacts. Every interface should trace to the requirements it satisfies and the subsystems it bounds. An interface that cannot be traced to a requirement is either unnecessary or a sign that a requirement is missing.
Run a risk identification session specifically against unallocated and TBD requirements. Unresolved requirements are risks. Treat them as such in your risk register, with owners and closure dates.
Establish PDR entrance criteria in writing, and check against them monthly. Programs that define entrance criteria early — and track against them throughout development — consistently perform better in reviews than programs that define criteria just before the review.
Honest Assessment
PDR is one of the highest-leverage milestones in a hardware program’s lifecycle. Passing it with a credible, well-constructed evidence package means detailed design work proceeds on a stable foundation. Passing it with an incomplete or backfilled package — or failing to hold a rigorous PDR at all — means architectural ambiguities get discovered during CDR or integration, where they cost orders of magnitude more to resolve.
The artifacts a PDR requires — allocation matrices, interface control documents, risk registers with traceability to requirements — are not bureaucratic overhead. They are the engineering argument that the architecture works. Building that argument incrementally, with tooling that maintains the connections between requirements, architecture, and verification throughout development, is now a tractable problem. The teams that treat PDR readiness as a continuous engineering state, rather than a pre-review sprint, are the ones that pass with findings they can close, rather than findings that require architectural rework.