A formula starts in a spreadsheet. A few component switches go into iLogic. Sales gets its own rules in CPQ. Production adds another table because the first three systems do not contain the information it needs.
None of those choices are necessarily wrong. The problem starts when the same product rule exists in several places, each with a slightly different meaning.
I do not think there is one correct system that should own all product logic. I do think every kind of knowledge should have a clear home.
CAD is good at geometric and model-specific logic
CAD is often the most natural place for logic that only makes sense inside the technical model.
A dimension can depend on another dimension. A component can be suppressed when an assembly becomes too narrow. A hole pattern can follow the length of a plate. A drawing view can change when an option is present.
Autodesk Inventor and iLogic are very practical for this kind of work because the logic sits close to the geometry it controls.
That becomes less attractive when a rule is no longer only about geometry.
If the same material choice also changes price, lead time, available options and manufacturing route, hiding that knowledge only inside CAD makes the rest of the process dependent on the CAD model.
At that point the rule describes the product, not only the model.
CPQ is good at product validity and commercial choice
A configurator needs to know which product can be sold.
That includes available options, valid combinations, dependencies, commercial packaging and sometimes pricing. Constraint-based CPQ can go deeper and model technical relations between choices as well.
This makes CPQ a logical home for knowledge such as which product variants are offered, which values are valid for a parameter, which combinations are technically allowed, which option requires or excludes another, and which customer requirement leads to which product choice.
But CPQ should not automatically become the place where every geometric formula or manufacturing detail is recreated.
If a press-brake allowance, detailed hole pattern or Inventor-specific feature definition only exists to build geometry, putting it into the configurator may make the product model harder to understand rather than better.
Custom software becomes useful at the boundaries
Some product knowledge does not fit cleanly inside CAD or CPQ.
A browser configurator may need a lightweight geometry engine. A calculation service may need to evaluate a technical model without opening CAD. A manufacturing check may need to compare a configured part against machine capabilities. An API may need to expose the same product definition to several tools.
That is where custom engineering software becomes useful for me.
Not because the goal is to replace every existing system, but because a small software layer can give shared product knowledge a neutral place to live.
The source of truth is usually not one file
People often talk about a single source of truth as if that means one database or one application.
For configurable technical products I find that too simplistic.
The more useful question is: which system is authoritative for which meaning?
CAD may be authoritative for exact geometry.
CPQ may be authoritative for offered choices and configuration validity.
ERP may be authoritative for released article numbers and commercial stock data.
A manufacturing capability service may be authoritative for what a certain factory or machine can produce.
The product model then needs clear references between those responsibilities.
The goal is not one giant master file. It is one coherent definition of the product without contradictory ownership.
Separate product meaning from implementation details
A useful test is to ask whether a rule still makes sense if the implementation changes.
Imagine the rule:
A stainless plate thicker than 4 mm cannot be bent on this press brake.
That is product and manufacturing knowledge. It remains true whether the geometry is created in Inventor, a web kernel or another CAD system.
Now compare it with:
Suppress the CAD flange feature when the front return is disabled.
That is implementation logic. It belongs close to the Inventor model because it describes how that specific model realises the product.
The first rule should not disappear when CAD changes.
The second probably should not be promoted into the company-wide product model.
That distinction is one of the cleanest ways I know to decide where logic belongs.
Product structure should sit above geometry
This is also why I increasingly separate product structure from geometry.
A component can be a leg, frame, cover, bracket or worktop before it has exact faces and edges. It can have a role, material, relationships, parameters and constraints before any CAD feature is generated.
Geometry can then be derived from that technical description.
That makes it possible for the same product definition to feed different consumers: configuration, pricing, geometry, BOM generation or manufacturing checks.
It also reduces the temptation to use CAD feature names as the product language.
Keep commercial and technical logic distinguishable
Commercial logic and technical logic often meet, but they are not the same.
A certain option can be technically possible but not sold in a market.
A component can be manufacturable but commercially unavailable this month.
A product can be valid for engineering but require an approval because of margin or delivery risk.
Those differences matter because they change at different speeds and belong to different owners.
I prefer to keep them distinguishable even when one system evaluates both.
A configurator becomes easier to maintain when it is clear whether a choice is blocked because the product cannot be built, because the company does not want to sell it, or because an order needs review.
Manufacturing logic deserves its own place
Manufacturing is often where product logic gets duplicated last.
Engineering defines the product, but the workshop then maintains its own knowledge about maximum lengths, available processes, preferred stock sizes, tooling or machine limits.
Some of that belongs directly in the product definition. Some of it belongs to the factory.
The important part is that the configurator should be able to consume it without pretending those limits are permanent properties of the product itself.
A plate may be perfectly valid as a product but impossible to bend in one workshop. That is a capability constraint, not necessarily a product constraint.
Keeping that distinction explicit becomes important when the same product can be made at several sites or when machine capability changes.
A practical split
For the kinds of products I work on, I increasingly think in layers.
Product model describes what exists: structure, components, parameters, materials, relations and technical intent.
Configuration logic describes what may exist: domains, rules, constraints and valid combinations.
Commercial logic describes what may be offered: markets, prices, approvals and commercial availability.
Geometry / CAD implementation describes how a valid product becomes exact geometry, drawings and CAD-specific features.
Manufacturing capability describes what a factory, process or machine can actually produce.
Output adapters describe how the configured product becomes BOM, quotation, CAD, CNC data or another downstream representation.
Those layers do not need separate applications.
They do need separate meanings.
The test I use
When I am unsure where a piece of logic belongs, I ask a few questions.
Does the rule describe the product, or only one CAD implementation?
Would the rule still be true if we changed CAD system?
Does sales need to understand it?
Does manufacturing own it?
Can it vary per factory?
Is it commercial policy or technical validity?
Does it calculate a value, restrict a choice, or describe how an output is generated?
Those questions usually make the boundary much clearer.
Why this matters
A product configurator can work for years with logic spread across CAD, CPQ, spreadsheets and code.
The problem is not that such a system immediately fails.
The problem is that every future change becomes harder to reason about. Nobody is sure which copy of the rule is authoritative, and every integration has to reconstruct part of the product again.
For me, the better direction is not to centralise everything blindly.
It is to make product knowledge explicit enough that every piece has a clear owner and every downstream system knows what it is allowed to derive.
That is the architecture I am trying to build towards in my own work as well.