Modular work has its own language. Positions, interfaces, modules, variants and attributes. Share that language between engineering and sales and you build a product model that lasts for years. We explain it with two images everyone understands. A jigsaw puzzle and a workbench.
The product as a jigsaw puzzle
The empty slot is the position. It stays put and waits for a piece. The tab and the recess together form the interface. If they match, any piece that follows the shape clicks in. The piece is the module, and usually several pieces fit the same slot. Alternatives and variants. A piece may itself be a small puzzle, modules may contain modules, as long as the tabs are frozen there too.
Five layers, one language
The test that keeps everything simple.does it have a physical interface? The drawer block screws to the frame, module. Colour connects to nothing, attribute. This stops everything from becoming a heavyweight module.
The position stays fixed, the module changes
The interface belongs to the position, not to the module. Any module that follows the interface fits, including the module you invent next year. Note the wide piece that claims both slots at once. Such a drawer is only selectable when left and right are both free. Rules like these a configurator polices flawlessly. A human does not.
The interface is the contract
Ninety percent of modular work lives in the connections, not the blocks. Capture every connection on an interface card. Mechanical (bolt holes, centre distances), electrical, and the attributes every module must report. Cards carry a status, a version and an owner, and together form the interface register, known in industry as the interface control document. Frozen means frozen. Changes only happen through a new version with an impact check.
Who supplies the value of an attribute?
The position demands that an occupied width is reported. The module promises its versions will do so. But the actual number comes from the variant, that is where the dimensions are pinned down. Global attributes (like exterior colour) are set once. Tagged parts read along, and a deliberate override stays possible.
Colour remains one property in the model. Does your ERP want its own article code per colour? Fine, the system generates it at order time. The point is not that the code must not exist, but that your engineer no longer creates it by hand.
From if-then rules to one attribute
Workbench example. The skirting must match whatever hangs on its side. Naively that becomes a web of if-then rules, unmanageable by the tenth module. The clean approach works differently. Every module reports one value to its position (the occupied width), and each skirting reads only its own side. A 300 mm block on the left? Left skirting = 3,000 − 300 = 2,700 mm. A new module next year? It only reports its width. Zero new rules.
The discipline in three steps.design the dependency away (one length with a filler), otherwise absorb it into the interface (a published attribute), and only as a last resort a managed rule in the rule register, with an owner, a version and a reason.