The short version

For highly configurable manufacturers, the rules that govern what can actually be built — which options are compatible, what each combination resolves into — are often locked inside the ERP with almost no usable documentation outside it. That makes them nearly impossible for engineering to validate or maintain. The fix: use AI to pull those rules out of the ERP and scattered documents into clear, reviewable matrices, let engineering and production validate them in a simple interface, and push the confirmed rules back into the systems of record.

The problem: rules you can't see

Configurable product lines are defined by their rules. Which options are compatible with which, which finish is available on which model, which choices are mutually exclusive — the product isn't really the parts, it's the logic that says how the parts can be combined. For a manufacturer with deep, complex product lines, that logic is enormous.

And in most established manufacturers, that logic lives in a place almost no one can inspect: encoded inside the ERP's configuration engine, with only sparse documentation outside it. What documentation does exist tends to be PDF marketing material and outdated spreadsheets that reference a mix of current and long-retired part numbers. The authoritative rules are buried in a system that wasn't built for humans to read, and the human-readable material is neither authoritative nor current.

This creates a bad bind. Engineering is the group that actually knows whether a rule is right — but they can't practically see the rules, because extracting and interpreting them from the ERP is exceedingly difficult. So the rules can't be validated, can't be confidently updated, and slowly drift from reality as products change. New products inherit the problem. The configuration model becomes something the organization depends on but no longer fully understands.

The approach: make the rules visible, then validatable

The core move is to get the rules out of the black box and in front of the people who can judge them — without asking those people to become ERP configuration experts.

Pull the rules out with AI. The rules and their supporting evidence are scattered across the ERP's own encoding, PDF documentation, and engineering spreadsheets. AI is well suited to reading across all of those messy, inconsistent sources, reconciling them, and reformatting the logic into a clean, structured representation. What was buried in a system and smeared across stale documents becomes a single, coherent ruleset.

Present it as reviewable matrices. Structured data alone isn't enough — engineering has to be able to see and check it. So the rules are surfaced as compatibility matrices and option rules in a simple interface: which options work with which, which combinations are required or excluded, what the defaults are. This is the format engineering and production actually think in, so they can spot what's wrong at a glance rather than parsing configuration syntax.

Configurator interface showing a product structure tree alongside option rules, with required options marked and incompatible options flagged as excluded by the current selection.
Rules pulled out of the ERP and surfaced as something engineering can actually read — required options, valid combinations, and what the current selection excludes.

Let engineering validate interactively. In the interface, engineers can edit the compatibility matrices and individual rules and immediately see the effect — confirming valid combinations, correcting bad ones, and validating the ruleset against how the product really builds. The purpose is twofold: simplify defining rules for new products, and validate the existing models that were previously impossible to review.

Push the confirmed rules back to the systems of record. Once validated, the rules flow back into the PLM/CAD system and the ERP, so the systems of record now hold a version engineering has actually confirmed — closing the loop instead of leaving a validated copy stranded in a side tool.

From configuration to what production actually needs: eBOM to mBOM

Getting the configuration right is only half of what the shop floor needs. A configured product first resolves into an engineering bill of materials — the parts as engineering defines them — but production needs the manufacturing bill of materials, the parts as they're actually built and stocked. Bridging those two is its own quiet source of friction.

A common example: engineering often does not track finishes on its models, because a finish usually doesn't change a part's mechanical properties. But production absolutely needs the finish, because you can't actually make or stock the part without it. So the same configured product looks complete to engineering and incomplete to manufacturing.

The tool closes that gap. After a product is configured, it explodes the engineering BOM to the derived parts needed to build the product, then resolves those to the correct manufacturing part numbers — applying finishes and other production-specific attributes where required. Engineering sees the eBOM with its part records; production sees the mBOM that resolves cleanly into buildable, stockable materials. One configuration, both views, reconciled.

A compatibility matrix marking which options are valid, invalid, or not applicable against each function, shown alongside the resolution from engineering BOM to manufacturing BOM.
The compatibility matrix engineering validates, and the eBOM-to-mBOM resolution that turns a configured product into buildable, stockable parts.

Why this is newly possible

Reconstructing and validating a large configuration model used to be prohibitive — the rules were too hard to extract, and there was no practical way to put them in front of engineering for review. Two things change that. AI can read across the ERP encoding, PDFs, and spreadsheets and reformat sprawling, inconsistent rules into structured, reviewable form far faster than any manual effort. And a purpose-built validation interface turns those rules into something engineering and production can actually confirm, instead of something only the ERP understands.

The result is the same pattern that runs through all of this work: AI does the heavy lifting of extraction and structuring; human experts hold the authority over what's correct; and the confirmed truth flows back to the systems everyone depends on.

Why it matters

Configuration rules are where a manufacturer's product complexity actually lives, and when they're trapped in a system nobody can validate, every downstream process inherits the uncertainty — quoting, manufacturing, quality, new product introduction. Making those rules visible and validatable, and reconciling the engineering and manufacturing views of a product, turns the configuration model from a liability the organization can't inspect back into an asset it controls.

This is part of a series on how we approach product-data remediation for complex manufacturers. See the series overview for the full phased program, the piece on reconciling broken product data, and the companion on converting legacy 2D drawings into 3D models.