Three levels, and why they cannot be two

What the three levels are

Identity is the part. 100-4420 is one thing in the world, and the number never changes — not when the geometry changes, not when the supplier changes, not when it moves to a different product. Everything else hangs off it.

Revision is a released state of that part which other things reference. Revision B is what shipped between November and July; a BOM line can point at it, a drawing can be issued against it, a qualification can name it. Revisions are public, ordered, and immutable once released.

Iteration is the work in progress inside the revision currently being made. Somebody saves eleven times on a Tuesday; those are iterations. Nothing outside the workspace can reference an iteration, which is precisely what makes it safe to be wrong in one.

The distinction people find hardest is that a released revision cannot be edited. That is not a restriction — it is what the word *released* means. If it could be edited, everything referencing it would silently change meaning.

The mechanism: revision is orthogonal to lifecycle

A common modelling error is to treat lifecycle states as revisions — draft, reviewed, released as though they were A, B, C. They are different axes and conflating them produces a system that cannot express *revision B, currently under review for obsolescence*.

In Manufacturing PLM an object record holds identity, object versions hold revision and iteration, and the lifecycle state machine runs alongside. A revision moves through states; a new revision starts a new pass through the same machine. Per-type revision schemes mean drawings can be numbered differently from parts without either being special-cased.

Revision references come in two kinds and the difference matters more than any other setting in the product. A pinned reference names an exact revision and never moves. A floating reference names the part and lets the revision policy decide — latest released, revision effective at a date, or the revision pinned at parent release. Both are legitimate; the mistake is not knowing which a given line uses.

The failure it prevents

A customer reports a failure on a unit built fourteen months ago. The question is what that unit actually contained.

In a system with one version field, the honest answer is a reconstruction from work orders and material issues — what was consumed, not what was specified. If a substitution happened on the floor and was recorded as the original, the reconstruction is confidently wrong. If the BOM was edited in place at some point, there is no record that it ever said anything else.

With three levels the question is a query: resolve the structure as at that date, for that unit number, at that plant. Every line names the revision that was effective, and the iterations that were in flight at the time are correctly invisible because nothing ever referenced them.

This is the single most expensive thing to get wrong, because the data to fix it does not exist retroactively. A tool that collapsed the levels for two years cannot be migrated into one that does not — the history is gone.

How it meets the rest of the product

The resolution engine takes revision policy as one of its four conditions, alongside effectivity, variants and plant scope. That is why a floating reference resolves differently depending on the date you asked about, and why the answer is reproducible.

Change control is the only route from one released revision to the next. A change names the affected objects and the revisions that will result, and release commits every one of them in a single atomic transaction — there is no state in which half a revision exists.

Workspaces make iteration safe. Work in progress is visible inside the workspace and nowhere else, so an engineer can restructure an assembly across a week without anybody downstream seeing a half-finished BOM. Optimistic locking and check-out expiry handle the case of two people and one part.

Deep copy carries a per-edge policy, so saving-as a product copies the structure but references the same released parts rather than duplicating them — which is the behaviour people expect and almost never get.

How it meets your ERP

Your ERP sees revisions and never sees iterations. That boundary is not a filter applied on the way out — an iteration is not a referenceable thing, so there is nothing to filter.

What publishes on release is the resolved structure at the change's effectivity, carrying the revision identifiers in whatever form the target models them: a BOM Revision in NetSuite, a Part Revision in Epicor, a versioned Production BOM in Dynamics 365. Where an ERP has no revision concept for a given object, the mapping is stated in the connector configuration rather than inferred.

Revision identity is Manufacturing PLM's under the system-of-record matrix, with one common exception: in SAP landscapes the material number itself is usually SAP's, and Manufacturing PLM holds engineering identity alongside it. That is a configuration decision recorded in the matrix, not a behaviour that varies quietly by deployment.

Where the boundary is

Manufacturing PLM does not track what was physically installed. A resolved structure says what a unit was *specified* to contain as at its build date. If the floor substituted an approved alternate and recorded it, that record lives in your ERP or MES; serialised as-built configuration is a separate capability that consumes both.

It also will not let you rewrite a released revision, including to correct a genuine mistake. The route is a new revision through a change, or a deviation if the intent is to permit something off-specification. Both leave a record, which is the point.