The configuration resolution engine
A bill of materials does not say what a product is made of. It says what it is made of under conditions. Manufacturing PLM ships the engine that turns those conditions into one exact structure — and everything else in the product reads its answer.
What it is, and what it is not
Resolution is the operation that takes a stored structure plus a set of conditions and returns exactly one configuration. It is not a report, not a view, and not a filter applied to a grid. It is the read path — the only one — and every screen in Manufacturing PLM is downstream of it.
The distinction matters because the alternative is so common. In most PLM tools the stored BOM is the answer, and the conditions live in people's heads: an engineer knows the 120-volt lines do not apply, a planner knows the old board expired in June, a buyer knows Frankfurt uses a different connector. The tool shows everyone the same undifferentiated list and each of them mentally subtracts a different set of rows.
That works until two of them subtract differently. Then the cost report and the compare screen disagree, and there is no way to tell which is right, because neither of them wrote down what it assumed.
Four conditions, one pass
resolve() takes four conditions and applies them together rather than in sequence, because applying them in sequence produces different answers depending on the order.
Effectivity narrows to the lines effective as of a date, for a unit number, at a plant. Variant rules narrow to the lines belonging to the options actually chosen. Revision policy decides what a floating child reference points at — the latest released revision, the revision pinned at release, or the revision effective on the date asked about. Plant scope narrows to the site.
The output is a structure with stable line identity, resolved quantities, and a record of which condition removed each line that did not survive. That last part is what makes the result explainable: a dropped row is not missing, it is dropped for a stated reason, and the reason is on screen next to it.
The failure it prevents
The expensive version of this failure is not a wrong BOM. It is two right BOMs that disagree, discovered late.
A cost rollup computed over the stored structure includes both the 120-volt and 240-volt power supplies, because nothing told it a unit only has one. The compare screen, written by a different team, resolves revisions but not effectivity, so it reports the June board change as a difference between two revisions that are not actually both in play. The compliance rollup uses a third path and quietly counts a superseded part's substances.
None of these is a bug in the ordinary sense. Each is a defensible implementation of the same question answered in a different place. Routing every read through one engine is the only fix that scales, and it has to be done before the second read path exists rather than after the sixth.
How it meets the rest of the product
BOM compare resolves both sides before diffing, which is why a comparison never reports an effectivity or variant decision as a difference. Where-used answers questions about the effective structure, so “which shipping products contain this part” is a different and correct answer from “which structures mention it anywhere”.
Cost, mass and compliance rollups sum resolved lines. Impact analysis walks the resolved graph. Every agent — Parts, BOM, Change, Digital Thread — calls the same service the UI calls, at the same conditions, which is what allows an agent answer to carry a citation that a human can click and reproduce.
Determinism is a requirement rather than a nice property here. The same question asked twice returns identical bytes; there is a test asserting it. Without that, an agent citation is unverifiable and an ERP publication is unrepeatable.
How it meets your ERP
The ERP does not receive the stored structure. It receives a resolved one, because a stored structure is a conditional statement and an ERP item master is not equipped to evaluate conditions.
On release, Manufacturing PLM resolves the BOM at the change's effectivity and publishes that exact result, with the dates attached, in the shape the target expects. NetSuite gets a dated BOM revision. SAP S/4HANA gets an engineering change with a valid-from. Dynamics 365 gets a revision record. The transformation is per connector and written down; nothing is inferred at run time.
The reverse direction is read-only. Cost, on-hand, lead time and supplier master come back from the ERP and render as ERP-owned in the Manufacturing PLM interface, greyed and labelled, so nobody edits a number that will be overwritten on the next sync.
Where the boundary is
The engine resolves product definition. It does not plan, schedule, net requirements, or allocate stock — those are ERP functions and Manufacturing PLM has no ambition to duplicate them.
It also does not resolve across systems. If half your structure lives in a legacy tool that Manufacturing PLM has not imported, resolution has nothing to say about it; the answer is complete with respect to what Manufacturing PLM holds, and the migration path exists precisely so that qualifier stops being necessary.
Facts
| Conditions | Effectivity · variants · revision policy · plant scope |
| Evaluation | One pass, order-independent |
| Output | Stable line identity, resolved quantities, drop reasons |
| Determinism | Same question twice returns identical bytes |
| Latency | p95 under 400 ms on a 5,000-line structure |
| Consumers | Compare · where-used · rollups · impact · all 12 agents |
| ERP | Publishes the resolved structure, never the stored one |
| Segment | S05 — the heart of the system |
Frequently asked
Why does a BOM need resolving at all?
Because a stored BOM is a conditional statement, not a list. Lines carry effectivity windows, option membership and floating revision references. Until you supply a date, a unit, a plant and an option set, the structure has many valid readings — and picking between them by hand is where the errors come from.
What is a floating versus a pinned child reference?
A pinned reference names an exact revision of the child part and never moves. A floating reference names the part and lets the revision policy decide, so the assembly picks up the latest released child automatically. Both are legitimate; the mistake is not knowing which one a given line uses.
Is resolution fast enough to sit on every screen?
Yes — p95 under 400 milliseconds on a five-thousand-line structure, which is the scale envelope the product is designed against. Results are cacheable because they are deterministic, so a screen showing the same configuration twice does not pay the cost twice.
Can I see why a line was dropped?
Yes, and this is the point of the design. A line removed by resolution is shown as dropped with the condition that removed it — effectivity ended, option not selected, wrong plant — rather than silently omitted. An engineer who cannot see the reason cannot trust the result.
Do the agents use the same engine?
They call the identical domain service the interface calls, with the same conditions. That is what makes an agent answer citable: the citation points at a resolution a human can re-run and reproduce byte for byte. An agent with its own private read path could not offer that.
How does this compare to Arena or Duro?
Neither ships a resolution engine. They store the conditional structure and leave the evaluation to the person reading the screen, which is workable at small scale and stops being workable once effectivity, variants and multi-plant production are all in play at the same time.
What happens when conditions conflict?
Overlapping effectivity, contradictory variant rules and impossible option combinations are detected and reported rather than resolved arbitrarily. The engine raises the conflict, names the lines involved, and declines to invent an answer — because an arbitrary pick that nobody sees is worse than an error somebody fixes.