Releasing to manufacturing means moving a specific, reviewed and approved set of design files into a controlled state where production can build from them, and only from them. A proper release has four states: draft, in review, released, and allocated to a manufacturing load. Files that skip any of these states are not released. They are just files that were sent. 

The most expensive email in hardware 

There is a moment in almost every hardware company where somebody attaches a zip file to an email and writes "latest files, good to build". 

That single action carries more risk than any other communication in the business, and it is almost never controlled. There is no record of who approved it, no statement of which revision each file belongs to, no confirmation that the BOM matches the layout, no statement of which variant it applies to, and no way for the factory to distinguish it from the five previous emails with similar subject lines. 

Weeks later, when a build comes out wrong, the investigation consists of searching mailboxes. Everyone has done this. It is not a small-company problem either. Large hardware organisations with formal processes still leak files through side channels because the formal process is slower than the email. 

The four states a file must pass through 

A release gate only works if the states mean something and the system enforces them. 

1. Draft. Work in progress. Visible to the team, versioned, but not buildable. Anyone can edit. Nothing in this state can reach manufacturing under any circumstance. 

2. In review. Submitted for approval. Locked against edits. A named reviewer with the authority to approve is looking at it. Comments and change requests happen here. 

3. Released. Reviewed and approved by a person with the role to do so. Immutable. A released revision never changes. A correction creates a new revision that goes through the same path. This is the state that gives the revision number meaning. 

4. Allocated. The released revision has been assigned to a specific variant and a specific production load. This is the state manufacturing can actually see. 

The distinction between released and allocated is the one most systems miss, and it is the one that prevents the most common failure. A file being approved does not mean it should be built right now, on this line, for this variant, in this quantity. Allocation is the decision to build. Release is the decision that it is buildable. 

What must be released, not just the Gerbers 

The handover package is larger than most teams treat it as. Everything that determines what gets built needs to be in a released state and allocated together as a set. 

1. Schematic revision 
2. PCB layout and Gerber or ODB++ set, with drill and fabrication drawings 
3. Bill of materials, including approved alternates and their validation status 
4. Pick and place file and assembly drawings 
5. Mechanical files, step models, enclosure drawings and assembly instructions 
6. Firmware binaries, both application and production test builds 
7. Test plan, test point list, limits and the golden sample reference 
8. Labelling, serial number scheme and packaging specification 

If any one of these is at a different revision from the rest, the build is inconsistent. Releasing them as a set, and allocating them as a set, is what prevents a correct layout being built with last month's BOM. 

Accountability moves at the gate 

This is the part that matters organisationally, not just technically. 

When a person with the appropriate role allocates a released file set to a production load, responsibility transfers. Manufacturing is accountable for building exactly what was allocated. Engineering is accountable for what they allocated being correct. 

Without that gate, accountability is permanently ambiguous, and ambiguous accountability produces the worst outcome in manufacturing: nobody stops the line because nobody is certain they are the one who should. 

The gate also protects engineering. When a build goes wrong and the allocated file set is on record, the question of what the factory was told to build is settled in seconds rather than argued for a week. 

The return path: engineering change requests from the line 

A release gate that only works in one direction fails within the first build, because production always encounters things engineering did not anticipate. 

The most common is component unavailability. A part in the released BOM is out of stock, has a twelve-week lead time, or the price has moved. The factory needs an answer today. 

What usually happens is a phone call or a chat message, an informal approval, and an undocumented substitution. That is precisely how untested alternates enter shipped product. 

What should happen is a structured engineering change request. 

• Production raises a request against the specific BOM line and production load 
• It appears in engineering's queue, routed to the responsible owner 
• Engineering evaluates whether an approved alternate exists, whether it has been validated, and whether it requires testing 
• The outcome is a new released BOM revision, allocated to the affected load, or a documented rejection 
• The request is closed with the decision recorded 

The result is that every substitution in your product's history has a reason, an approver and a date attached to it. When a failure appears eighteen months later that correlates with a component change, the record exists. 

How S3Suite implements the gate 

• Files carry an explicit state. Draft, review and released, with role-based permission on who can approve a release. 
• Only released files can be allocated. The system will not let a draft or in-review file reach manufacturing, which removes the possibility rather than relying on discipline. 
• Allocation is to a variant and a production load, so the factory sees exactly one valid file set for what they are building. 
• The allocated set is versioned as a set, so schematic, BOM, Gerbers and firmware move together. 
• Engineering change requests are raised from the Manufacturing Suite and land in the Engineering Suite against the correct project and owner. 
• The full history is queryable. Which revision was allocated to which load, who approved it, what changed, and which serial numbers were built from it. 

The one rule worth adopting even without a system 

If you take nothing else from this: no file reaches manufacturing except through a named person who approved a specific revision for a specific build. 

Write down who has that authority. Write down what they approved and when. Even in a spreadsheet, that single discipline prevents the majority of build errors, and it makes adopting a real gate later a formality rather than a project. 

FAQ 

What does release to manufacturing mean? 

It is the formal transfer of a specific, approved revision of the complete design package into a controlled state that production can build from, with a named approver and a recorded date. 

What is the difference between a released and an allocated file? 

Released means reviewed and approved as buildable. Allocated means that released revision has been assigned to a specific variant and production lot, which is the actual instruction to build. 

Should drafts ever be shared with a contract manufacturer? 

Only clearly marked as pre-release for quotation or DFM feedback, never as a build instruction. If drafts can reach the line at all, one eventually will be built. 

What is an engineering change request from production? 

A structured request raised by manufacturing when the released package cannot be built as specified, most commonly component unavailability, which routes to engineering for a documented decision and a new released revision. 

Why do component substitutions need to be documented? 

Because an undocumented alternate is an untested change in shipped product. When a correlated failure appears later, the substitution record is often the only path to root cause. 

CTA: Put a real gate between engineering and manufacturing. [See how S3Suite handles release and allocation] 

Internal links: /insights/managing-hardware-product-variants-in-production, /insights/testing-bom-alternate-components, /insights/hardware-version-control-for-electronics-teams, /s3suite