Prototype programs fail in two directions: they freeze too early, committing to a design that has not answered its open questions, or they never freeze, polishing a design while the schedule and the budget drain away. The freeze decision is the moment the program stops learning by iteration and starts committing by production, and it deserves the same rigor as any other engineering decision. The criteria are not “we are out of time” or “the prototype looks good”; they are a structured review of the remaining risk, the cost of change, and the evidence that the design’s open questions have been answered.
Signs that iteration is still reducing risk
Iteration is productive when each cycle answers a question that the previous cycle could not. The signs are measurable: a test that failed now passes, a fit that did not close now closes, or a material that was uncertain is now confirmed by data. Iteration is still reducing risk when the changes are driven by test results and the convergence is visible — each revision moves the measured performance closer to the target. The team should track the open-risk list, not the number of revisions, because a program can iterate twenty times on appearance and still carry an unanswered load question. As long as the next iteration is expected to answer an open question, the iteration has value.
Risk reduction also has a rate: the value of another iteration is the risk it removes, and the cost is the schedule and the budget it consumes. When the rate slows — when the last few iterations changed little or answered questions that were already known — the loop is no longer learning, and the freeze review should begin.
Signs that iteration is only polishing aesthetics
The other side of the signal is iteration that has stopped reducing risk. The signs include changes driven by preference rather than by test results, revisions that move the design from one acceptable option to another without measurable improvement, and a team that keeps finding “improvements” because the review has no defined end. Cosmetic iteration is not always wrong — appearance prototypes exist to settle visual questions — but the program should know which loop it is in. A design that is functionally frozen and only receiving aesthetic tweaks is a design that should be released for its functional review, with the cosmetic work tracked separately. The discipline is to name the loop: if the change does not affect a test, a tolerance, or a requirement, it is polish, and polish has a budget like any other work.
Polish can also be a sign of avoidance: a team that keeps refining the prototype because the production decision is uncomfortable is spending the schedule on the part it can control. The freeze review is the mechanism that forces the uncomfortable conversation with evidence.
Freeze criteria organized by risk category
Write the freeze criteria by risk category so the review is complete. Functional risk: the part passes the tests that define its function, with the load, environment, and cycle evidence. Fit risk: the assembly fits with the mating parts, and the critical dimensions are verified. Manufacturing risk: the design can be produced by the planned process at the planned tolerance and cost. Supply risk: the materials and finishes are available and qualified. Regulatory or standards risk: the design meets the applicable requirements, and the documentation is in place. Each category has a gate, and the design is frozen when every gate that applies to the program has passed — not when the most visible one has.
The criteria should be written before the review, with the evidence for each gate named. A freeze review that invents its criteria at the meeting is a review that can justify any decision; one that checks against pre-written criteria is a review that can be audited.
The cost of a late design change after tooling starts
The cost of a change rises sharply once tooling starts, and the rise is the economic argument for the freeze. A drawing change before tooling costs the editing time; a change after tooling costs the tool modification, the re-trial, the schedule, and the parts that were already made against the old geometry. The cost curve is not linear — it jumps at the tooling commitment, at the first production parts, and again at the field release. The freeze review is the checkpoint that captures the design before the jump, and the criteria are what give the team the confidence to stop. When a late change is genuinely necessary, the review should price it honestly — including the scrap, the tooling, and the schedule — and the change should pass the same scrutiny that the original freeze did.
The freeze is not a wall against change; it is a gate that makes change expensive and therefore deliberate. A program that knows the cost of a late change is a program that freezes with its eyes open.
Running a formal freeze review with engineering and sourcing
The freeze review should include engineering, quality, sourcing, and the supplier, because each sees a different risk. Engineering presents the functional evidence; quality reviews the inspection and the documentation; sourcing confirms the materials, the finishes, and the supplier readiness; and the supplier confirms the design can be produced as drawn. The review should be recorded with the attendees, the evidence reviewed, and the decision, because the freeze is a commitment that the whole team owns. A freeze signed by engineering alone is a freeze that sourcing and the supplier may not be ready to support; a freeze reviewed by the full team is a commitment that production can execute.
The record also names the exceptions: the cosmetic items deferred, the tests that will run on the first production parts, and the conditions that would reopen the freeze. A freeze with defined exceptions is a controlled release; a freeze without them is a surprise waiting for the first production review.
The decision in practice
A practical example ties the framework together. A housing program reaches revision D with the fit and function gates passing but the environmental test still open because the lab schedule slipped. The freeze review names the open gate, decides that the design is functionally frozen with the environmental test running on the first production-equivalent parts, and documents the exception with a date. The tooling starts on schedule, the environmental test passes on the first parts, and the exception closes. If the test had failed, the change would have been priced and reviewed as a late change with the full cost visible. The example shows the freeze working as a risk management tool: the design is committed where the risk is resolved, and the remaining risk is tracked with an owner and a date rather than hidden under a “frozen” label.
How the freeze review runs in practice
A practical review walks the checklist with the whole team. Engineering presents the functional evidence: which gates passed, which tests produced the data, and which exceptions remain. Quality confirms the inspection and the documentation are tied to the revision. Sourcing confirms the materials, the finishes, and the supplier readiness, and the supplier confirms it can hold the tolerances and the schedule. The review records the attendees, the evidence, and the decision, and the exceptions carry owners and dates. The same review, run without the evidence or with half the team, produces a freeze that the missing side will later question. The formal structure is what makes the freeze a commitment the whole program owns, and it is the structure that lets the program move into tooling with the risk list visible rather than hidden.
The freeze review should also check the downstream gates: the first-article inspection on the production process, the validation tests that run on production parts, and the field or certification tests that the product must pass. A design can be frozen for tooling while the regulatory or field validation is still open, and the freeze record should name those gates so the program knows what remains. The difference between a design freeze and a program freeze matters: freezing the geometry is not the same as freezing the risk. The review that separates the two keeps the tooling moving while the remaining validation is tracked, and it avoids the failure mode where the geometry is frozen but the product is not ready.
The freeze also protects the team from the schedule pressure that produces premature freezes. When a program is behind, the temptation is to freeze what exists and hope the gaps disappear in production; the freeze criteria are the counterweight, requiring the evidence that the gaps are resolved or named as tracked exceptions. The review should be scheduled with enough time for the evidence, not squeezed into the week the tooling quote was promised. A program that freezes on evidence may slip a few days; one that freezes on schedule slips for months in production. The freeze record should note the schedule context so the decision can be reviewed honestly if the program later misses a date. The discipline is the same as the validation gates: the freeze is a claim that the risk is controlled, and the evidence is what makes the claim reviewable.
If your program is approaching the freeze decision and wants the criteria and the evidence reviewed before the tooling commitment, the 6CProto engineering and manufacturing teams can help run the review — the freeze is a commitment, and the criteria are what make it a confident one.