Machine Design #109: Drawing Release Packages — One Correct PDF Is Not Enough
Drawing release package must preserve function, intent, manufacturability, inspectability, release quality, and serviceability when the boundary changes.
Evidence before release
Write the input, expected result, acceptance limit, failure symptom, and measurement method before changing a drawing or releasing a package. Assign an owner to every assumption, value, and change.
Core checks
- Drawing, model, BOM, and configuration completeness: record value, source, method, owner, and pass/fail evidence.
- Material, process, surface, and inspection data: record value, source, method, owner, and pass/fail evidence.
- Revision, filename, and access control: record value, source, method, owner, and pass/fail evidence.
- Supplier package and acceptance record: record value, source, method, owner, and pass/fail evidence.
- Missing-file and outdated-file checks: record value, source, method, owner, and pass/fail evidence.
- Release approval and traceability: record value, source, method, owner, and pass/fail evidence.
| Failure mode | Symptom | Verification |
|---|
| Intent missing | Correct file, wrong function | Review requirements and evidence |
| Package incomplete | Supplier or inspection stops | Run a release completeness check |
| Documents out of sync | Correct number, wrong revision | Baseline every reference |
What goes in a release package, and who each item serves
A correct drawing still leaves several gaps that the supplier will fill with assumptions. A complete release package is the set that lets the receiving side work without having to ask questions that should already have been answered.
| Component | Who uses it | What happens if it is missing |
|---|
| The drawing in a readable format, at the right revision | Programmer, inspector | Nothing to refer to at acceptance |
| Geometry data in the agreed format | Machining programming, sheet cutting | The supplier rebuilds the geometry from the drawing, with deviation and lost time |
| Bill of materials — code, quantity, material, treatment | Purchasing, assembly | Missing or wrong items ordered, discovered late |
| General notes and applicable standards | Shop, inspection | Each party applies a different default |
| Inspection requirements and the report form | Both inspection teams | Acceptance disputes because each side measured differently |
| File list with revisions | Whoever receives the package | Old files get mixed in with nobody noticing |
| Packing and transport notes | Stores, transport | Precision parts damaged on the way |
The two most often missing are the last two rows. A file list with revisions is the cheapest item to produce and saves the most: it lets the receiving side verify they hold the correct set, instead of discovering a mismatch after the material has been cut.
The main enemy is files that are individually correct but at different revisions
Every file in a package can be correct on its own and still produce a wrong part, if they belong to different revisions. The typical situation: the drawing has been updated with new screw holes, but the geometry file sent alongside is the previous version, or the bill of materials still lists the old material.
Three measures, easiest first:
- Export the whole package in one go from one state, instead of collecting files day by day.
- Put the revision in the file name, so it is visible without opening the file.
- Include a file list with an integrity value, so a substituted or mixed-in file can be detected.
The principles of revision management and the scope that has to be rechecked after a change are in Machine Design #107 — Drawing revision tables.
What has to be stated, not left implied
- Which format governs. When the drawing and the geometry data disagree, which one wins? That has to
be answered before there is a dispute, not while there is one.
- Which parts must be made as a matched set or machined together. That constraint does not emerge
from the geometry and has to be said directly — see Machine Design #90 — Matched machining.
- Which items may be substituted by equivalents. Without a statement, the supplier decides for
themselves wherever they judge it unimportant.
- The approval state. Issued for quotation, issued for manufacture and issued for reference must be
distinguishable on the document itself. A draft understood as a manufacturing release is an expensive and entirely avoidable mistake.
- How subsequent changes will be sent. Who receives them, in what form, and how the receiving side
confirms. Changes announced through a message with no record are a common source of divergence.
A package for a new supplier needs one more layer
A supplier who has worked for you many times already holds the shared defaults. A new supplier does not, so the first package should also include: the drawing conventions in use, how the general notes are to be read, the inspection report format wanted, and one sample part for comparison before the batch runs. The cost of that layer is far below the cost of a batch made to a different interpretation.
Release package formats: readable years from now
A release package needs more than the right files; it needs to open years later, even after the software has changed version. Choose formats by longevity, not just by what is convenient now.
- Native files: keep them so the part can still be edited later, but they depend on the software
version — a new version may open them shifted, an old one may be gone.
- Neutral formats: STEP for the 3D model, PDF (ideally PDF/A for long-term archive) for the 2D drawing.
They do not depend on one specific program, so they stay readable for the long run.
- The pairing rule: each release should carry both native and neutral. Native to keep working,
neutral to read and archive reliably.
Version control and file integrity
- A release is a frozen state: once "released", the content no longer changes quietly; every change goes
through a new rev. Do not overwrite a released file in place.
- Name it with the version: file and folder names should carry the drawing number and rev, so two
releases are never confused.
- Checksum for integrity: for a package sent out or archived for long, include a checksum so the
receiver can tell whether a file was corrupted or altered in transit.
"Released" means a controlled freeze: others rely on that exact set of files to buy and machine from, so it only changes through the revision process, not by a save-over.
MINATA release checklist
- [ ] Function, intent, boundary, and failure symptom are written.
- [ ] Ownership, interfaces, process, and mistake-proofing are clear.
- [ ] Six topic checks have evidence and pass/fail limits.
- [ ] Manufacturing, assembly, inspection, release, and maintenance were tried.
- [ ] Revision, supplier, package, and configuration records agree.
Good engineering ends with questions that can be verified. For drawing release package, evidence that function and intent remain reliable is the MINATA standard.
Frequently asked questions
Is sending the drawing as a document enough?
Not except for very simple parts. The receiving side also needs geometry data in the agreed format, the bill of materials, general notes and applicable standards, the inspection requirements, and a file list with revisions.
If the drawing and the 3D file disagree, which one applies?
Whichever was agreed in advance and stated in the package. The worst case is that nothing was agreed, because then the answer only appears once wrong parts exist and both parties believe they were right.
Why is a file list with revisions needed?
Because files that are individually correct but at different revisions still produce wrong parts. The list gives the receiving side a way to verify they hold the right set, before material is cut.
Do quotation and manufacturing releases need to be distinguished?
They must be, and distinguishable on the document itself rather than only in the covering message. A draft understood as a manufacturing release is an expensive and entirely avoidable mistake.
What extra does a new supplier need?
The drawing conventions in use, how the general notes are to be read, the inspection report format wanted, and one sample part for comparison before the batch runs. An established supplier already holds these defaults; a new one does not.
Frequently asked questions, continued
Should a release package hold native or neutral files?
Both. Native files keep it editable but depend on the software version. Neutral files (STEP for 3D, PDF/A for 2D) stay readable long term, independent of one program. Each release should pair the two.
How is "released" different from a draft?
It is a controlled freeze. A released version does not change quietly; every change goes through a new rev, not an in-place overwrite. Others rely on that exact set of files to buy and machine from.
What is the checksum in a release package for?
So the receiver can tell whether a file was corrupted or altered in transit. For a package sent out or archived for long, a checksum catches differences the eye cannot see.
A quick table for the shop floor
A release package is complete when the situation, its contents and the purpose are lined up:
| Situation | Contents or control | Purpose |
|---|
| A controlled PDF | Correct revision, fonts and paper size | People read it the same way |
| CAD data | The agreed native or exchange format | For machining and coordination |
| A BOM and notes | Part number, quantity, material, treatment | Buy and build the right configuration |
A worked case
A correct PDF that is missing the BOM or the DXF used for cutting still makes the supplier invent the data themselves. The release package needs a manifest listing file names, revisions and checksums, so an old file mixed in can be spotted.
Conclusion
Drawing Release Packages is not paperwork done to make a file look tidy. It is how intent becomes a result that can be manufactured, assembled and measured repeatedly. A good drawing does not need the designer standing beside it to explain it; the structure of the information has to do that work.
View all MINATA technical articles