Topics / Engineering practice
Preliminary design review (PDR): purpose and checklist
A preliminary design review (PDR) assesses whether the proposed architecture can meet the requirements within the project’s constraints and risks. It supports a decision to proceed into detailed design, before expensive choices become difficult to change.
What to prepare for a PDR
- Requirements baseline: the behavior, constraints and scope the architecture must support. Mark unresolved intent.
- Architecture: component responsibilities, data flow, external interfaces and resource assumptions.
- Trade studies: the choices considered, reasons for selection and evidence behind feasibility claims.
- Risk: failure modes, expensive unknowns and the experiments or analysis needed to reduce them.
- Verification approach: how the team expects to observe the most consequential promises.
Entry: the proposed architecture and its basis are available for review. Exit: the authorized decision records whether detailed design may proceed, which conditions apply and who owns each remaining action.
NASA publishes software review criteria and adaptable checklists. The working checklist here is our own; use your project’s approved criteria for the actual decision.
PDR tests the approach; CDR tests the detail
A critical design review examines a more mature design. At PDR, a storage choice may still depend on an experiment. At CDR, the design should explain the resulting write, acknowledgment and recovery rules.
Keep the experiment’s result attached to the decision. An architecture diagram that looks plausible is not evidence that its throughput or recovery assumptions hold.
Review the argument behind the architecture.
Bring the important requirements, allocated component responsibilities, interfaces, major trade-offs and unresolved risks. The decision is whether the design is sufficiently understood to proceed, with specific actions for what remains open.
NASA’s software handbook describes preliminary design work as an input to later detailed design and review. The exact entrance and exit criteria belong to the applicable project plan.
Source: NASA software handbook: detailed design. Scope and edition reviewed 3 October 2026.
Make an unresolved interface visible.
Illustrative example
The producer can outrun the storage service.
A sensor collector sends bursts faster than the persistence component can commit them. The architecture shows a queue between the two, but does not say what happens when it fills. An unbounded queue may exhaust memory; dropping records may violate the data-preservation requirement. A clean component diagram leaves that trade-off unresolved.
Allocate responsibility for capacity, flow control and overload reporting before detailed design. Agree which inputs must be preserved, whether the producer can pause and how the system exposes loss when it is permitted. Plan a bounded-load experiment that challenges the chosen policy.
- Which requirement defines allowable loss and resource use?
- Who detects saturation and who controls incoming work?
- What happens to buffered records during shutdown or recovery?
- What evidence will support the chosen capacity and overload behavior?
Use automated checks as preparation.
Proof provides a PDR assessment for configured structural checks, including interface coverage, dependencies and requirement validation. It reports observations from the project model; it does not decide whether an architecture is suitable or replace the review authority.
proof gate pdr --format markdownInspect each criterion and its evidence. A generated design document or a cycle-free dependency graph alone does not establish a sound design.
Try it on your software
Bring one architecture decision with an unresolved risk.
We can connect the decision to its requirements and the evidence the review needs.