In this guide
A useful design freeze identifies the released configuration, exact source files, approved requirements and remaining exceptions. It creates a stable baseline for a named downstream task. It does not require every future design activity to stop, and it should not let unresolved decisions disappear behind one approval label.
Begin by stating the purpose: supplier quotation, prototype ordering, tooling or another operation. Those releases have different evidence requirements. A package ready for a visual review may still be missing manufacturing decisions.
Define the baseline and its scope
Record the product family, configuration selections, source revisions, drawing revisions and supporting specifications. Include a file manifest and the responsible reviewers. Avoid a release name that points to an editable folder whose contents can change after approval.
| Release element | Record | Acceptance question |
|---|---|---|
| Configuration | Option IDs and source revision | Which exact product is authorized? |
| Engineering files | Controlled model and drawing revisions | Do the files agree? |
| Open exceptions | Issue, owner and consequence | Is the downstream task allowed to proceed? |
| Intended operation | Quote, sample or production task | What does this approval authorize? |
Onshape’s release-management overview distinguishes controlled releases and ongoing design activity.1 The operational lesson is to preserve the baseline while new work continues on identifiable revisions.
Separate approval from file generation
A successful export proves that files were produced. It does not establish that all decisions are approved. Keep build status, technical checks and human release decisions separate. Reviewers should be able to see the exact package they are authorizing.
For example, a finish may be approved while a connector relocation remains open. If the release is for an appearance prototype, that exception may be compatible with the task. If the release is for production tooling, the same issue may block it. State the consequence rather than using an undifferentiated pass/fail label.
Define what reopens the release
Identify triggers such as interface changes, material substitution, critical dimension changes or a new supplied component. A spelling correction in an internal note and a changed mounting pattern should not receive the same workflow treatment.
When a trigger occurs, create a new revision and identify affected drawings, BOMs, imagery, test evidence and supplier instructions. Preserve the historical release so an existing quote or sample can still be traced to its actual basis. See the configuration and BOM guide.
Require receiving acknowledgement
Send the package with the release purpose and any exceptions. Ask the recipient to confirm the received revisions before starting the authorized operation. Save that acknowledgement beside the release record. A supplier working from an old attachment can invalidate a carefully reviewed package.
Download the design-freeze register. Use prototype acceptance and RFQ revision control for the corresponding next task.
The Rendora product visualization workflow preserves master and configuration revisions and supports reviewed visual-delivery releases. A visual-content release is distinct from engineering authorization for tooling or manufacture.
Freeze questions
Can work continue after design freeze?
Yes, on controlled subsequent revisions. Preserve the baseline and the authority of the released package.
Does every exception block release?
Evaluate it against the intended downstream operation. Document the issue, decision owner and consequences rather than hiding it.
References
- Onshape, Release management, checked October 26, 2026.
About this guide
Rendora publishes practical guides for teams working with configurable 3D assets and traceable production handoffs. Updated October 26, 2026.