At first it can look like a list of parameters with a few rules between them. Width, height, material, motor, colour. Add some if/then logic and there is a configurator.
That can work surprisingly far.
But once the same model has to support engineering, pricing, geometry or manufacturing, a list of options is no longer enough. The model has to explain more clearly what the product consists of, what can vary, what has to remain valid and which outputs depend on those choices.
I therefore find it useful to separate the concepts inside the model.
Product structure
The first thing is structure.
A product is rarely one flat list of properties. It contains assemblies, components, modules and features that each have a role.
A work table can contain a frame, legs, a top and shelves. A door can contain a leaf, layers, a lock, hinges and a frame. A machine can contain functional modules that are present only for certain variants.
That structure matters because many rules are really about relationships between parts.
It is much easier to say that a shelf belongs inside a frame, or that a lock belongs to a certain door-leaf construction, when those concepts exist explicitly in the model.
Parameters
Parameters describe the things that can vary or that need to be calculated.
Some are customer choices: width, material, execution.
Some are engineering values: profile size, plate thickness, motor torque.
Some are derived values that the user never edits directly.
I prefer parameters to have a clear type and meaning instead of being arbitrary variables.
A width in millimetres is different from a material identifier. A boolean option is different from a calculated force. That distinction helps both people and software understand the model.
Domains
A parameter needs a domain: the values it can meaningfully take.
That may be a numeric range, a list of materials, a set of modules or another bounded space.
The domain is useful even before any rules exist.
It tells the system what is possible in principle.
Later, constraints can reduce that domain based on the current configuration.
Expressions
A lot of product logic is simply calculation.
Leg length can equal working height minus top construction.
Required motor torque can follow from load, radius and efficiency.
Price can contain a material quantity multiplied by a rate.
Those relations do not need to become rules or constraints when a direct expression is clearer.
Keeping calculations explicit makes the model easier to inspect and test.
Rules
Rules are useful where the relation has a natural direction.
If width exceeds a limit, add a support.
If an option is selected, include a component.
If a certain execution is chosen, use another assembly variant.
This is familiar from parametric CAD and automation because the flow is usually deterministic.
Rules are not a problem. The problem appears when every relationship is forced into directional rules even when the product itself is not directional.
Constraints
Constraints describe relationships that must remain valid.
They are especially useful when several choices influence each other and there is no obvious first input.
A plate length must remain within a process limit.
A motor must provide enough torque for the configured load.
A certain material and fire rating combination may be invalid.
A total width may have to equal the sum of several configurable parts.
A constraint says what must be true without necessarily prescribing the order in which the system reaches that state.
Materials
Material is more than a label if the model has to continue into engineering or manufacturing.
It can affect density, cost, available thicknesses, corrosion resistance, stock sizes, process compatibility and other downstream decisions.
That does not mean every material property has to live directly in the configurator.
It does mean the product model should refer to material as a real technical concept rather than only a text option.
Connections and relationships
A product model becomes much more useful when components are related explicitly.
A leg supports a frame.
A plate is attached to another component.
A profile terminates against a plate.
A component is aligned with or offset from another.
These relations should not immediately be confused with exact CAD mates or face references.
At the product level, the relation mainly explains intent.
The geometry layer can later decide how that intent is realised exactly.
This is particularly important for configurable geometry because the exact faces and coordinates may change between variants while the relationship remains the same.
Manufacturing intent
For me this is one of the most important additions beyond a classic configuration model.
A plate is not only geometry. It may need to be cut, bent and finished.
A profile may need a saw cut, tube-laser operation or mitre.
A hole may be punched, drilled or laser-cut depending on the process.
The product model does not necessarily have to contain a complete manufacturing plan, but it should be able to express enough fabrication intent that downstream software does not have to guess what the geometry means.
This is the layer I am experimenting with in my own geometry/fabrication kernel.
Commercial information
Pricing and commercial availability are part of configuration, but I prefer not to mix them invisibly with technical validity.
The model can reference price rules, market availability, options and commercial packages.
The important part is keeping clear whether a choice is technically invalid or simply not offered.
Those are different reasons and they often have different owners.
Manufacturing capability
Product intent and factory capability are related but not identical.
The product may require a bent plate.
The factory may have a press brake with a certain maximum length and thickness.
The product model should be able to ask whether the configured product can be realised with the available capability.
That capability may vary per workshop, site or supplier, so I would not hard-code every machine limit as an eternal property of the product.
Instead I prefer the product to describe what it needs and the manufacturing model to describe what is available.
Configuration can then compare the two.
Outputs are derived views
A configured product can produce many outputs:
- geometry;
- a bill of materials;
- drawings;
- a quotation;
- a cutting list;
- CNC or machine data;
- an ERP order structure.
I do not think those outputs should each become a separate version of the product.
They are better treated as derived views of one configured definition.
That is one reason I care about making the underlying model explicit. If the source stays coherent, different outputs can change without redefining what the product is.
Identity matters
Every important concept needs stable identity.
A component should not only be “the third item in an array”. A parameter should not depend on the label shown in one user interface. A relation should be able to refer to a component without relying on current geometry.
Stable IDs make translations, revisions, APIs and automated authoring much safer.
This becomes especially important when AI or external tools are expected to read and modify the model.
The model should be machine-readable
Human-readable documentation is useful, but a configurator needs formal definitions.
That is why I prefer typed structures and schemas for the core concepts.
If a system knows what a Profile, Plate, Parameter, Constraint or Material requires, validation becomes possible before geometry or pricing is generated.
The same schema can then guide a UI, API, authoring tool or AI agent.
Machine-readable does not mean obscure.
A good schema should make the product easier to reason about, not hide it behind technical ceremony.
Not every product needs every concept
This list can make a product model sound large.
It does not have to be.
A simple configurable product may only need structure, a few parameters, domains and expressions.
A more complex product may add constraints, materials, manufacturing intent and capability checks.
The important part is that the model can grow without forcing every new concern into a pile of ad-hoc rules.
For me, that is the real test of a configurable product model.
It should be simple when the product is simple, but still have enough structure to explain a complex product without losing the meaning behind it.