Topics / Engineering practice
Critical design review (CDR): checklist and exit criteria
A critical design review (CDR) assesses whether the detailed design is mature enough to proceed with implementation and testing. For software, review how requirements become interfaces, algorithms and failure handling, how they will be verified, and which risks remain.
A practical software CDR checklist
Before the review: identify the design baseline and circulate the requirements, detailed design, interface definitions, verification approach and open-risk list. Name the people authorized to resolve each decision.
- Behavior: can a reviewer follow each consequential requirement to the design that implements it?
- Interfaces: are inputs, outputs, timing, invalid inputs and ownership explicit?
- Failure paths: what happens on retries, partial writes, timeouts and restart?
- Verification: can the planned observations distinguish the required behavior from a plausible wrong result?
- Open work: which findings block implementation, and which may proceed under an explicit condition?
At exit: retain the reviewed versions, decision, conditions, action owners and closure evidence required. Do not turn an unresolved design question into a check mark because the meeting ended.
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.
CDR vs. PDR vs. TRR
PDR challenges the architecture and major choices. CDR challenges the detailed design. TRR challenges whether the test campaign is ready to produce meaningful results. Passing one does not answer the others.
For agent-written code, these questions still matter even if the team does not hold a formal milestone meeting. Review the intent and evidence for the change before accepting it.
Check that the detail supports the promises.
The review should be able to follow consequential requirements into state, algorithms, interfaces and failure handling. Keep unresolved decisions visible, with owners and a consequence for proceeding.
NASA’s guidance associates detailed-design baselining with CDR. A project should use its own approved review criteria and applicable assurance basis rather than importing a generic checklist unchanged.
Source: NASA software handbook: review criteria. Scope and edition reviewed 3 October 2026.
Test whether a failure path is actually designed.
Illustrative example
Persistence fails after the external action.
A workflow sends a command and then records completion. If the record fails to persist, a restart may send the command again. The review needs the ordering decision, duplicate protection and recovery evidence plan. A successful build says little about that behavior.
Use the case to challenge the design description and the allocated requirements. Record any accepted exception against the reviewed version.
Understand the scope of the Proof gate.
Proof’s CDR command evaluates configured implementation-readiness checks such as build, annotations and trace integrity. These are useful preparation, but narrower than a full critical design review.
proof gate cdr --format markdownRead the criterion results and inspect the underlying artifacts. A passing automated assessment is not approval by a review board or a claim that every detailed-design obligation is satisfied.
Try it on your software
Use a real failure path to review the design.
Bring the design record, requirement and implementation it is meant to govern.