Releasing CAD, and what release actually means

Most companies release CAD by convening people to confirm that four things are true. All four are checkable, and the meeting exists because nothing was checking them.

ERPShipped in segment S10 · 864 words
CLOUD CADEXTRACTEDPLM▾ Gearbox assembly▾ Housing sub-asmHousing.prtCover.prtShaft.prtFastener kitread over the API — never a file scrapeassembly tree → EBOM seedproperties → part attributesthumbnails → native APIdocument id → association100-4420 Housingrev C · released100-4421 Coverrev A · in work210-0087 Shaftrev B · in workfastener kit — no part yetrelease state → CAD: released geometry locksBOM-first, CAD attached: the structure can hold packaging, firmware and labels that were never modelled.

What release means

Release is a state change applied to a set of objects at once — the model, the drawing, the structure it implies, and the items every one of them references. Not a folder copy, not a file rename, and not a PDF landing somewhere.

The set matters because the failure is always partial. A model released without its drawing, a drawing released against a superseded model, a structure released containing an item still in a working state. Each of those looks like a release and is not one.

Four things have to be true simultaneously, and a release that transitions the set atomically is what makes them true together rather than nearly together: every referenced item is itself released; the drawing corresponds to the model revision being released; the structure the model implies matches the structure being released; and every gate condition your rules define is satisfied.

That last one is where the meeting used to happen. Somebody would ask whether the specification was linked, whether the impact analysis was done, whether anybody had objections. Those are rules, and rules evaluate faster than people convene.

The model and the structure disagreeing

The most common CAD release defect is a mismatch between what the assembly model contains and what the bill of materials says. It happens constantly and almost always for innocent reasons.

A designer suppresses a component to work on something and forgets to unsuppress it. A fastener is added in the model and the BOM was exported before that edit. A subassembly is replaced with a variant and the structure still names the original.

Manufacturing PLM compares the structure derived from the model against the structure being released and refuses the transition when they disagree, naming the specific lines. The check costs a second and the defect costs a fabrication run, which is a trade that needs no analysis.

Where the disagreement is intentional — a phantom assembly, a bulk item that has no model presence, a purchased assembly modelled as one part — that is expressed as a rule about the item rather than as an exception somebody approves each time. An exception approved repeatedly is a rule nobody has written down.

The failure it prevents

A drawing is released and sent for fabrication. It is correct, checked, and shows the part accurately.

It corresponds to model revision B. The model released alongside it is revision C, which changed a hole pattern after the drawing was checked. The parts arrive with the old hole pattern because the shop built to the drawing, which is what a shop is supposed to do.

Both documents were individually correct and were released as a set they did not belong to. Atomic release of a set — where the drawing's model reference is checked against the model being released, and the transition fails if they differ — makes the pairing impossible to get wrong rather than merely unlikely.

How it meets the rest of the product

The CAD connectors handle the mechanics, keeping model relationships and derived structures current as work happens so that the release check has something accurate to check against.

Rules supply the gate conditions, which is what makes release configurable without being negotiable. A company requiring a linked specification before release configures that once and never discusses it again in a meeting.

Controlled copies publish at release, to the destinations configured on the document type. The release is the trigger; nobody remembers to distribute, and the supplier sees the current package because publication was part of the transition rather than a task afterwards.

Revisions become immutable at release, which is what makes everything downstream trustworthy. A released model that can still change is a released model that will, quietly, on a Friday.

How it meets your ERP

Release is the event your ERP is waiting for. An item reaching released state with a released structure is what makes it plannable, purchasable and buildable, and publishing at that moment rather than earlier is what stops the ERP holding definitions that were never approved.

The publication carries the effectivity date rather than the release date, which is the distinction most integrations get wrong. Approved on the 3rd and effective on the 24th means the ERP should change on the 24th, and publishing on approval changes production three weeks early.

Where the release fails ERP-facing gate conditions — an item in the structure missing from the item master — the release is refused with the specific item named. Catching that at release is a thirty-second fix; catching it when a work order fails is an escalation with a production supervisor in it.

Where the boundary is

Manufacturing PLM does not check your design. It checks that the set is internally consistent and that your gate conditions are met. Whether the part is a good part is an engineering judgement, and no rule engine should imply otherwise.

It also does not release on your behalf. An agent can prepare a release — assemble the set, run the checks, report what fails — and the transition itself requires a person, because release is the moment a company commits to a definition and that commitment needs an author.

Facts

Release isA state change on a set, transitioned atomically
The setModel · drawing · structure · every referenced item
Four checksItems released · drawing matches model · structure matches · gates pass
Most common defectModel and BOM disagreeing — suppressed parts, stale exports
On disagreementThe transition is refused, with the lines named
Intentional mismatchesExpressed as item rules, not per-release exceptions
At releaseControlled copies publish; revisions become immutable
To the ERPPublished carrying the effectivity date, not the release date

Frequently asked

Why release a set rather than a file?

Because the failure is always partial — a model released without its drawing, a drawing released against a superseded model, a structure containing an item still in a working state. Each of those looks like a release and is not one, and only an atomic transition prevents it.

What are the four things that must be true?

Every referenced item is itself released; the drawing corresponds to the model revision being released; the structure the model implies matches the structure being released; and every gate condition your rules define is satisfied. All four, simultaneously, or the transition fails.

What is the most common CAD release defect?

The model and the bill of materials disagreeing. A suppressed component that nobody unsuppressed, a fastener added after the BOM was exported, a subassembly swapped for a variant while the structure still names the original. All of them innocent, and all of them expensive.

What if the mismatch is intentional?

Phantom assemblies, bulk items with no model presence and purchased assemblies modelled as one part are expressed as rules about the item rather than as exceptions somebody approves each time. An exception approved repeatedly is a rule that nobody has written down yet.

Does this replace our release meeting?

It replaces the part of it that was checking things. Whether the specification is linked, whether the impact analysis is done, whether the gates pass — those are rules, and rules evaluate faster than people convene. Judgement still belongs in a room with people.

When does our ERP hear about a release?

At release, carrying the effectivity date rather than the release date. Approved on the 3rd and effective on the 24th means the ERP should change on the 24th — publishing on approval instead changes production three weeks earlier than anybody intended.

Can an agent release something?

It can prepare a release — assemble the set, run the checks, report what fails — but the transition requires a person. Release is the moment a company commits to a definition, and a commitment of that kind needs an author who can be named.