That sounds obvious in engineering, but many configurators still stop one step earlier. They know which options are compatible and which dimensions are allowed, but they do not necessarily know whether the configured variant can be produced with the available machines, processes and material limits.
For simple products that may be fine.
For configurable manufacturing products, I think factory capability eventually has to become part of the model.
Product constraints and factory constraints are different
I find this distinction important.
A product constraint describes the product itself.
A cover must fit the opening.
A motor must provide enough torque.
A frame must support the required load.
Those relations remain true regardless of where the product is made.
A factory constraint describes the available production capability.
A press brake may accept a plate up to a certain length and thickness.
A workshop may have laser cutting but no tube laser.
A saw may handle a certain profile size.
One site may weld TIG, another may outsource that operation.
Those facts can change without changing the product definition.
That means they should not automatically be hard-coded into the product as if they were universal truths.
Describe what the product needs
I prefer the product model to describe manufacturing intent.
A plate needs cutting and two bends.
A profile needs a mitred saw cut.
A hole needs a process that can create its diameter and tolerance.
An assembly requires a certain welding process.
This describes the work the configured product asks for.
The manufacturing model can then describe which processes and limits are available.
The interesting step is comparing those two descriptions.
Capability can be modelled explicitly
A workshop capability model does not have to start complicated.
It could say that a site has laser cutting, a press brake, sawing and TIG welding.
The press brake can have limits such as maximum bend length and maximum material thickness.
A saw can list the profile sizes or cut angles it supports.
A process can specify materials, tolerances or tooling restrictions.
That information is much more useful to a configurator than one generic flag called manufacturable.
It explains why something is or is not possible.
Constraints connect intent to capability
Once product intent and factory capability are separate, constraints can connect them.
If a configured plate requires a 3200 mm bend but the selected factory can handle only 3000 mm, the configuration can detect the conflict.
The system then has several possible responses.
It can reject the variant.
It can suggest another construction.
It can route the order to another factory.
It can keep the configuration valid but mark it for engineering review.
That behaviour is a business/process decision.
The useful part is that the technical conflict is visible before somebody discovers it on the shop floor.
Manufacturing is not only machine limits
Capability goes further than maximum dimensions.
It can include available processes, material and thickness ranges, stock formats, tooling, tolerances, preferred operations, subcontracted operations, site-specific restrictions and certification requirements.
Not all of that needs to be in the first version of a model.
But treating manufacturing as structured capability creates room for the model to grow without turning every new shop-floor rule into another product-specific exception.
The same product can be valid in one factory and invalid in another
This is one reason I do not want factory constraints mixed blindly into product constraints.
Imagine a configurable stainless assembly that requires a certain bend.
The product itself is valid.
Factory A can make it.
Factory B cannot because its press brake is too short.
If the machine limit is stored as a universal product rule, the configurator concludes that the product cannot exist.
That is wrong.
The better conclusion is that this configuration cannot be produced with the currently selected capability.
That small distinction becomes important when companies have several sites, suppliers or changing machinery.
Manufacturing feedback can influence configuration earlier
Once the configurator understands capability, manufacturing can move much earlier in the process.
Instead of sales creating a configuration and engineering later discovering a production problem, the system can reduce the available choices before the invalid variant is committed.
That does not mean sales needs to see every machine parameter.
The UI can stay simple.
The product model and capability model do the technical work underneath.
This is similar to constraint-based product configuration: the user sees a smaller valid choice space without needing to understand every reason behind it.
Geometry can help, but geometry is not enough
Some manufacturing checks need geometry.
A plate length has to be known before it can be compared with a press-brake limit.
A profile cross-section matters for saw capacity.
Hole placement can affect whether a process is reachable.
But geometry alone still does not tell the whole story.
A 3000 mm plate can be geometrically valid while requiring a process or material combination the selected factory does not support.
The geometry engine therefore needs context from the product and manufacturing models.
That is one reason I am interested in a fabrication-aware kernel rather than only a geometry kernel.
Manufacturing capability can also guide design
The relation does not have to be only pass/fail.
Capability information can guide the configured construction.
If one sheet becomes too long, the model may split it into two parts.
If a bend is impossible, another connection method may be available.
If a profile cannot be tube-lasered at one site, a saw-and-drill route may still be possible.
That starts to move from validation towards synthesis.
I would approach that carefully. Automatically redesigning a product is a much bigger step than checking it.
But the same capability model can eventually support both.
Keep the workshop model independent
Factory data changes more often than product architecture.
Machines are replaced. Tooling changes. Processes are outsourced. Capacity differs per site.
That is another argument for keeping capability in its own layer.
A product model should be versioned around the product.
A workshop model should be versioned around the manufacturing resource.
The configuration can then combine a specific product version with a specific capability context.
That makes changes much easier to reason about.
What this means for CPQM
This is also where my use of the term CPQM becomes more concrete.
Configure, Price, Quote, Manufacture is not only about generating CNC output after a valid configuration.
The deeper idea is that manufacturing knowledge should influence the product before the quote is finished.
If the system knows what has to be made and what the factory can make, manufacturing stops being a downstream interpretation step.
It becomes part of the configuration context.
Where I want to take this
I am still exploring this layer in my own semantic/fabrication model.
The direction I find useful is relatively simple:
Product model describes what the configured product is.
Fabrication intent describes which operations the product requires.
Factory capability describes what a site can perform.
Constraints compare the two.
Outputs translate the valid result into geometry, BOM, drawings or machine data.
That separation feels more useful to me than putting all manufacturing knowledge directly inside CAD or hiding it in a separate spreadsheet next to the configurator.
A configurable product should not only be valid on screen.
Eventually, it should also be valid in the workshop.