A phase gate review verifies, against evidence, that a space program is ready to proceed to its next phase. The standard gate sequence is MCR, SRR, PDR, CDR, TRR, and FRR, each with defined entrance and exit criteria. This checklist covers all six gates, plus the margin thresholds and red flags review boards look for.
Prefer watching? Running a CDR From a Dashboard — self-hosted, no tracking.
Transcript
Eight gates, from System Requirements Review through to Decommissioning, each with a live readiness percentage. This programme is mid-Phase C: SRR at ninety-two per cent, PDR at seventy-one, CDR at forty-three, and everything downstream still red.
The aerospace pack seeds a hundred and eight criteria across these gates, and every one starts red — the tool assumes nothing is done until you say so, which is the right default for a review that runs on evidence.
Critical Design Review has fourteen criteria in five categories: detailed design, interface control, manufacturing readiness, verification plan, and design margins.
Notice the margin items carry actual thresholds — mass margin above ten per cent of the dry mass allocation, power margin above ten per cent, thermal margins positive in all cases. At this stage margins are not a vibe, they are a number a board checks.
Each item is one click through four states: red not met, yellow partial, green met, not applicable. The gate percentage recomputes as you go. This replaces the spreadsheet that one person owns and nobody trusts.
Auto-Score reads the mission’s actual data — requirements, verification, budgets — and proposes a status for each criterion, with the reasoning behind it. It is deterministic rules, not a model, and nothing changes until you apply it. You stay the review authority; the tool does the evidence-gathering pass.
When the board asks whether you are ready for CDR, the answer should be data: requirement approval, verification pass rate, live mass and power margins, open risks, and gate item counts — each card linking straight to its source page.
Review day itself. The package assembles from the same live data rather than being written separately. Expected deliverables are checked against what is actually in the document register, alongside gate readiness counts, a scored checklist, margins, and open action items — exported as a PDF that files itself back into the register.
What is a phase gate review?
Phase gate reviews are the formal checkpoints in a space program lifecycle. Each gate verifies that the mission is ready to proceed to the next phase. The standard gates for most programs are: Mission Concept Review (MCR), System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR), and Flight Readiness Review (FRR).
The most common mistake in phase gate reviews is treating them as presentations rather than technical assessments. A review board is not there to hear a summary of your work. They are there to evaluate whether the evidence supports readiness to proceed. Every item in the review package should be traceable to a specific entrance or exit criterion.
| Gate | Confirms |
|---|---|
| MCR | A mission concept has been selected from a genuine trade space |
| SRR | The requirements are right |
| PDR | The design approach is feasible |
| CDR | The detailed design is ready to build |
| TRR | The test program is ready to execute |
| FRR | All open items are closed; ready for launch or operations |
What does the Mission Concept Review (MCR) require?
Mission Concept Review (MCR) — entrance criteria: mission need is documented, top-level objectives exist, a feasibility study has been completed. Exit criteria: a recommended mission concept has been selected from a trade space of alternatives, with a defensible rationale. The trap at MCR is committing to a concept before the trade space has been honestly explored. If your team cannot describe two alternatives you rejected and why, you have not done MCR.
What does the System Requirements Review (SRR) require?
For SRR, the key criteria are: mission objectives are defined and measurable, system-level requirements are derived from objectives, a preliminary concept of operations exists, and key risks are identified with mitigation plans. The common gap is requirements without clear verification methods; every requirement at SRR should have at least a proposed approach to verification.
SRR red flags: requirements that include implementation choices, requirements without numeric criteria, requirements that combine multiple shall statements. Each of these will get worse downstream and are cheapest to fix at SRR. The review board should be reading a sample of requirements, not just looking at coverage statistics.
What does the Preliminary Design Review (PDR) require?
For PDR, the evidence expands: subsystem requirements are allocated from system requirements, preliminary budgets (mass, power, data rate, link) are established with margin, the requirements traceability matrix shows complete flow-down from mission objectives to subsystem specs, risk mitigations are in progress, and the preliminary design shows how each requirement will be met.
PDR margin policy: most programs require 25-30% mass margin and 20-25% power margin at PDR. If you are reporting healthier numbers than this, the review board will assume you are missing items. If you are reporting tighter numbers, you are likely going to fail to close the design at CDR. Honest budgets at PDR are the single best predictor of program success.
What does the Critical Design Review (CDR) require?
For CDR, the bar is highest: detailed designs are complete, budget margins meet minimum thresholds (typically 10-20% depending on program phase), all requirements have assigned verification methods and responsible engineers, the test plan covers every requirement, and the manufacturing/integration plan is reviewed.
CDR is also where verification readiness becomes critical. Every requirement should have a planned verification method (test, analysis, inspection, demonstration), a planned verification venue (lab, environmental chamber, integration facility), and an assigned engineer. Gaps in this matrix are CDR action items by default; they should not be deferred to TRR.
What does the Test Readiness Review (TRR) verify?
Test Readiness Review (TRR) verifies that the test program is ready to execute. Entrance criteria: hardware is built and accepted, test procedures are written and reviewed, test facilities are scheduled and staffed, and any test equipment calibration is current. The most common TRR slip is procedures that have not actually been red-lined by an independent reviewer. Procedures that look right on paper often have ambiguities that surface only during execution.
What does the Flight Readiness Review (FRR) confirm?
Flight Readiness Review (FRR) is the last gate before launch or operations. The review board confirms that all open items from prior gates are closed, the launch site is ready, the operations team is trained, the contingency procedures are exercised, and the risk posture is acceptable. FRR is not a place for new technical issues; it is a place to confirm closure.
How do you keep gates from slipping?
Across every gate, the same discipline applies: every entrance and exit criterion must map to evidence, the evidence must be current, and the criteria that are not yet met must have an assigned action item with an owner and a date. Vague action items ("address comments") are how gates slip into mush. Specific action items ("update R-1234 verification method to test, owner J. Smith, due 2026-04-15") keep programs honest.
Tracking gate readiness in Hitt Hosting SE
Hitt Hosting SE tracks phase gate readiness as a dashboard. Each gate criterion maps to data in the system: requirement coverage, budget margins, risk status, and gate item checklist completion. When the review board asks "are we ready for CDR?", the answer is not an opinion — it is data. The phase gate item list cycles through Red / Yellow / Green / N/A statuses with one click, so the dashboard reflects the current state without ceremony.