CAD and product record integration: making geometry and released state agree

Two systems holding the same part, neither of them wrong

Designers work in the modelling tool, where the file is the part. Everyone else works from the product record, where the number, revision and status are the part. Without a defined boundary both become authoritative and drift apart: a model is edited after release, a record shows a revision no drawing matches, and purchasing quotes against something engineering abandoned weeks ago. The first job of an integration is a rule nobody can bypass. Released state belongs to the record, geometry belongs to the vault, and a change to either has a defined consequence in the other. Sites that skip this settle the argument case by case, usually after a wrong part has already been cut.

What check-in has to enforce rather than merely log

A working vault does more than store files. It locks a model while somebody is editing it, so two engineers cannot both save over the same assembly. It increments revision on release rather than on save, so work in progress never looks approved. It regenerates derived outputs — the neutral exchange file, the flat drawing, the lightweight viewable — from the released model instead of trusting an engineer to export them, because hand exports are the most common route by which a supplier receives geometry that no longer matches its drawing. And it preserves component links, so opening an old revision returns the parts that were current at the time.

The modelled assembly is not the bill you will build from

A modelled assembly reflects how geometry fits together. A manufacturing bill reflects how material is issued and consumed. They differ in ways that matter. Adhesives, lubricants and surface coatings appear nowhere in the model. Fasteners may be modelled individually but bought by mass. A sub-assembly exists in the plan because it is stocked, not because it is a design entity. Packaging is absent entirely. An integration that pushes modelled structure straight into planning produces a bill that looks complete and cannot be built. The workable pattern transfers the design structure and then applies explicit, owned rules for what manufacturing adds, removes and restructures.

Renames, replaces and geometry you did not author

Links break in predictable places. Renaming a file outside the vault orphans every assembly that referenced it. Replacing a component instead of editing it leaves configurations pointing at something that no longer exists. Imported geometry from a customer or supplier carries no parametric history, so a change against it becomes a remodelling job the schedule never allowed for. Parts that predate the system arrive with no revision history and get loaded as though born at their current state. Each of these is survivable when anticipated, and each turns into an archaeology exercise when it surfaces mid-change with a customer date attached.

What actually reaches the bench at the far end

The point of all this is that a person at a workstation opens the correct instruction for the revision in front of them. That needs the record to know which revision is effective for their order, and the distribution mechanism to withdraw what it supersedes. Screens at the line handle this better than printed packs, but only where the network reaches the floor and the terminal shows order context rather than a general library to browse. Where paper cannot be avoided, the discipline is a controlled reprint per job and destruction of loose copies at completion — simple to write into a procedure and dependent on supervision to hold.

Frequently asked questions

Can we run a product record system without connecting it to CAD?

Yes, and many firms do, but you inherit manual discipline where the system could enforce it. Somebody has to attach the right files to the right revision, generate neutral formats by hand and remember to update the record whenever a model changes. That holds while volumes are modest and one careful person does it. It fails quietly during holidays, staff changes and rush work, and the failure surfaces only when a supplier builds to a superseded file.

Should the design structure generate the manufacturing bill automatically?

Automatic generation is useful as a starting draft and dangerous as a final answer. Let the transfer create or update the structure, then leave manufacturing free to insert stocked sub-assemblies, add consumables, restate quantities in issue units and attach packaging, with those additions protected so the next transfer does not erase them. The rule that keeps it sane: engineering owns what the product is, manufacturing owns how it is decomposed for production, and both trace to the same source revision.

How should we handle models that arrive from customers or suppliers?

Bring them in as controlled items, flagged as non-parametric, with a record of which party owns the geometry and the terms under which it may be used. Give them their own revision identity so an updated file from a customer creates a change rather than silently overwriting production data. The common failure is treating received geometry as a working file on a shared drive, which leaves nobody able to state which version the parts already on the floor were made from.