How is a modular configurator different from a bundle builder?

A bundle builder groups commercially related items. A modular configurator also models how component instances form one product or technical system. It can enforce adjacency, sequence, connection types, spatial constraints, repetition, end conditions and derived parts. If the relationship between items has no physical, functional or structural meaning, a bundle workflow may be sufficient.

Modular product configurator

Every module fits. Every relationship makes sense.

Configurix turns governed components into one valid, visual and commercially complete assembly. Connection points, neighbours, sequence, positions, repeat counts, derived parts, live pricing and BOM or order handoffs remain tied to the same saved revision.

Discuss your modular product Classify the assembly

Current assembly

Outdoor kitchen · OK-24

Valid system

Drawer

Sink

Grill

End

4 modules · 3 joints

Ports resolved

Topology

Linear run

Modules

4 selected

Derived parts

3 joints · 2 ends

Services

Installation

Live price

€9,420

Rules

Accepted

3D assembly

Synchronized

Order

Revision 11

Governed modules

Every component has stable identity, revision and lifecycle status.

Typed interfaces

Ports, slots, orientation and occupancy make relationships explicit.

Derived structure

Connectors, supports, fillers and services follow the accepted assembly.

One revision

3D, price, quote, BOM and order consume the same saved state.

Category definition

A modular product is more than a list of compatible options.

The assembly itself carries meaning. Module instances occupy positions, connect through typed interfaces, affect their neighbours and produce derived structure. Separating variants, bundles, modules and parameters prevents both over-engineering and missing logic.

Variant configurator

Selects one predefined product or SKU and its permitted options. It may enforce compatibility, but the result does not need an assembly of separately identified module instances.

Use when every sellable result already exists as a governed variant or option set.

Bundle builder

Collects products into one commercial package. A bundle can enforce inclusion rules, but its items do not necessarily connect, occupy positions or form one technical product structure.

Use when the commercial relationship matters more than physical assembly behavior.

Modular product configurator

Creates one valid product or system from governed module instances. Rules control interfaces, neighbours, order, orientation, counts, positions, dependencies and derived connecting parts.

Use when the composition and relationship between components define the sellable result.

Parametric configurator

Uses continuous inputs such as width, height, angle or capacity to derive valid geometry, quantities and price. Parametric and modular logic often combine in one product architecture.

Use when dimensions or calculated values materially change the product state.

Interactive assembly classifier

Choose the assembly model before choosing the interface.

Select the real topology, placement control and required handoff. The result identifies what the structured state must store and which evidence the implementation needs to prove.

Assembly topology

Placement control

Required handoff

Recommended assembly architecture

Bay and grid modular configurator

Store row, bay, level or cell ownership plus span, orientation and group identity. Empty and occupied cells need deliberate behavior.

Expose compatible free ports, enforce port type and occupancy, and keep 3D anchors bound to the structured relationship.

Define sales BOM versus configured order versus manufacturing BOM, then map instances, connectors, quantities and units to governed identities.

Assembly rule

The structured assembly is authoritative. The interface, 3D scene, price, quote, BOM and downstream payload all consume the same versioned module instances and relationships.

Canonical module contract

Twelve fields keep every component explainable across the workflow.

A thumbnail in a component library is presentation. The module contract is product data: it lets rules, 3D, price, saved projects and downstream systems interpret the same instance and relationship.

Stable module ID

A durable product or component identity independent of its screen label.

CAB-BASE-600

Module class

The semantic family used by rules, search, placement and downstream mapping.

base cabinet

Revision and status

The released catalogue version, effectivity and lifecycle state used by the assembly.

rev 14 · released

Ports and slots

Named interfaces a module provides, consumes or occupies.

left.side · right.side · wall

Interface type

A typed connection contract including gender, size, profile, service or protocol where relevant.

rail-40 · compatible

Orientation

Permitted rotations, reflections, handedness and mounting direction.

0° · 90° · left/right

Envelope and clearance

Bounding dimensions plus access, service, safety or movement zones.

600 × 580 × 720 mm

Cardinality

Minimum, maximum, repeat and uniqueness rules for the module or slot.

0…8 · repeatable

Dependencies

Required, optional, excluded or automatically derived modules and services.

requires plinth

Visual binding

The runtime asset, node hierarchy, anchors, materials and state behavior.

asset CAB600 · anchor rear

Commercial mapping

Price identity, quantity basis, market availability, services and lead-time context.

price item 44102

Output mapping

Configured-order, BOM, CAD, document, ERP or production identities and units.

ERP material 100184

Assembly rule architecture

Compatibility is only one layer of a valid modular system.

A useful rule model explains which module is available, where it connects, what may surround it, how many times it can appear and which additional structure the relationship creates.

Eligibility

Defines which modules are available for the product family, market, customer, role, project or selected base system.

A commercial controller is available only for the supported voltage and region.

Port compatibility

Checks whether the provided and required interfaces match by type, size, profile, service, orientation or another governed characteristic.

A 60 mm rail cannot attach to a connector released only for the 40 mm profile family.

Adjacency

Controls which module classes or specific modules may be neighbours and on which side or interface.

A corner cabinet permits an end panel on the outer side and a standard base cabinet on the inner side.

Sequence

Validates ordered systems where the preceding or following module changes the allowed next step or complete flow.

An inspection station must follow processing and precede reject handling or outfeed.

Position and orientation

Restricts slots, grid cells, levels, directions, handedness, mirroring, rotation and mounting faces.

A left-hand door module cannot be mirrored if its hardware kit and certification are handed.

Cardinality and repetition

Controls minimum, maximum, uniqueness, repeat counts and group-level quantities.

A system needs exactly one controller, at least one drive module and no more than twelve powered sections.

Spatial and clearance

Evaluates envelope, overlap, access, service zones, door swings, support intervals and surrounding project boundaries.

A drawer cannot open through an adjacent return, and a service panel needs its maintenance zone clear.

Derived structure

Adds connectors, fillers, supports, transitions, hardware, services or technical review from the accepted assembly context.

Joining two bays inserts a coupling set; the final open edge adds an end cap automatically.

Assembly data model

Model modules as instances and relationships—not as screen order.

A saved assembly needs enough structure to survive editing, localization, asset replacement and downstream processing. An ordered array alone is insufficient when products contain branches, slots, groups, corners or repeated subassemblies.

Assembly root

System identity · catalogue revision · market · customer · project

Module instance

Instance ID · module ID · characteristics · status · origin

Relationship

Parent · source port · target port · slot · order · orientation

Derived instance

Creating rule · source relationship · quantity · unit · revision

Representation

Asset binding · node instance · transform · material · view state

Commercial state

Price context · lines · services · currency · calculation revision

Output state

Quote · configured order · BOM · job · acknowledgement · release boundary

JSON Schema can validate arrays, object structure, uniqueness and conditional fields; domain rules still define whether two real modules can form a sellable product.

3D assembly architecture

The scene should represent the assembly—not become its hidden database.

Runtime assets can be reused, instantiated and transformed efficiently. Product identity, interfaces, rules and downstream meaning still belong in governed configuration data.

Reusable module assets

Prepare one governed visual asset per module state or family. Normalize units, origin, hierarchy, pivots, materials and levels of detail so repeated instances do not need duplicated source models.

Anchors bound to ports

Map named visual anchors to structured ports and permitted orientations. A snap in 3D should be a representation of an accepted relationship, not the only record that the relationship exists.

Atomic scene updates

Add, remove, replace and reorder from one accepted assembly revision. Reject stale geometry and price responses so a slower previous request cannot overwrite the latest configuration.

Instances and repetition

Reuse meshes and materials where practical, while retaining unique assembly-instance identity for selection, analytics, price, BOM and saved-project behavior.

Envelope and clearance

Configured elevations, schedules, quantities, quote, BIM or CAD reference and controlled technical acceptance

Live pricing

Price the relationships as well as the modules.

A credible modular price includes the selected components and the commercial consequences of how they connect, repeat, finish and reach the customer.

Module price

A governed item price for every selected instance, quantity and applicable commercial context.

Interface price

Connectors, transitions, joints and dependent kits priced from actual relationships—not guessed totals.

Position or finish price

Surcharges for corners, end conditions, orientation, material, colour, treatment or position-specific work.

Derived service price

Installation, delivery, engineering, commissioning or survey requirements calculated from the accepted assembly.

Account and market context

Currency, channel, customer, price list, region, tax, discount authority and validity retained with the result.

Revision evidence

The quote records both the assembly revision and price calculation context so reopening remains explainable.

End-to-end state flow

One accepted assembly should drive every representation and output.

The flow prevents the component picker, 3D scene, price calculation and downstream systems from becoming competing versions of the product.

Choose the base system

Identify product family, market, catalogue revision, project context and the initial assembly root.

Expose valid modules

Filter the module library by role, system, position, available ports, neighbours and current constraints.

Place a module instance

Create an instance with stable identity, parent or connection, slot, orientation, quantity and user intent.

Resolve the assembly

Validate interfaces, neighbours, order, counts, space and dependencies as one atomic state change.

Derive supporting structure

Insert connectors, fillers, supports, caps, services or review flags from the accepted relationships.

Render the same revision

Build or update browser 3D from explicit module instances, anchors, materials and assembly bindings.

Calculate price and outputs

Price selected and derived items, then create the quote, configured order or BOM from the same revision.

Save, approve and hand off

Persist history, customer or sales approval, downstream acknowledgements and any technical release boundary.

Implementation blueprint

Prove one representative assembly before scaling the catalogue.

A representative build exposes identity, interface, rule, asset, pricing and downstream assumptions early. Use accepted evidence from it to plan the wider product system.

Select a representative assembly

Choose one product that contains repetition, an interface, a corner or branch, a dependency and at least one invalid combination.

Define authority and identifiers

Assign ownership for modules, characteristics, rules, price, assets, BOM, order data and technical release. Replace labels with stable IDs.

Model the assembly graph

Define roots, module instances, parent relationships, ports, slots, edges, orientation, order, grouping and derived items.

Formalize constraints

Convert expert knowledge into testable eligibility, interface, adjacency, sequence, count, spatial and review rules with clear messages.

Prepare modular 3D assets

Normalize units, origins, pivots, anchors, node hierarchy, materials, levels of detail and reusable assets for every governed module.

Connect commercial calculation

Map selected and derived instances to price items, quantities, services, account context, currency and calculation revisions.

Define downstream contracts

Specify configured-order, BOM, document, CAD, ERP, PLM or MES payloads, idempotency, acknowledgements and error ownership.

Test assemblies and changes

Cover empty, first, repeated, maximum, reordered, replaced, incompatible, historical, rapid-edit and downstream-failure cases.

Publish with governance

Release catalogue, rules, assets, prices and mappings together; monitor failures and preserve old project behavior through explicit version policy.

Acceptance evidence

Twelve tests for a modular product configurator.

A polished demonstration is not enough. Test structure, rules, 3D, commercial calculation, historical behavior and receiving-system contracts together.

TEST 01

An empty or initial assembly has a deliberate state and cannot produce a misleading completed quote.

TEST 02

Every visible module instance maps to a stable module identity and unique assembly-instance identity.

TEST 03

Compatible ports connect in every permitted orientation, and incompatible interfaces fail with an actionable reason.

TEST 04

First, repeated and maximum counts resolve the correct positions, joints, caps, supports, quantities and price.

TEST 05

Adding, removing, replacing or reordering a module updates rules, 3D, derived parts, price and outputs atomically.

TEST 06

Corners, branches, transitions, ends and mirrored or handed modules behave correctly at every supported boundary.

TEST 07

Clearance, collision, opening and service zones remain valid in the representative project environment.

TEST 08

Rapid edits and slow geometry or price responses cannot overwrite a newer accepted assembly revision.

TEST 09

Saved projects reproduce their historical module, rule, asset and price context or follow an explicit migration decision.

TEST 10

Quote line items reconcile to selected and derived module instances, services, quantities, units and commercial context.

TEST 11

Configured-order or BOM payloads use governed downstream identities and record acknowledgement, rejection or retry state.

TEST 12

Role, market, tenant and product permissions prevent unavailable modules, prices and technical details from leaking.

Failure patterns

Eight shortcuts that break modular configuration.

Each shortcut may look convincing in a small demo. The failure appears when modules change, projects reopen or commercial and production systems need the exact accepted assembly.

A shopping cart presented as an assembly

Items can be added together, but the system has no ports, positions, neighbours, order or product-level validity.

3D snap points as the rule engine

Geometry appears connected while commercial and downstream systems cannot explain why the relationship is valid.

Labels used as identifiers

Renaming or translating a module breaks prices, saved projects, analytics, BOM mappings and integrations.

Independent visual and BOM structures

The scene shows one assembly while the order payload uses a separately maintained component list.

Missing derived connectors

The visible modules are priced, but joints, supports, fillers, fasteners, caps or services are omitted.

One giant prebuilt model

Every combination is embedded in a heavy asset, making updates, performance and product-data bindings fragile.

No atomic state transition

Partial updates leave an old price, invalid neighbour or stale geometry after a module is changed.

Historical assemblies silently reinterpreted

A catalogue or rule update changes an accepted project without explicit migration, review or revision evidence.

Primary references

Implementation guidance for component and part identification, included as one external reference for durable identities across systems.

Open primary source

Related technical guides

Connect modular assembly to rules, assets, price and downstream data.

Parametric product configurator Product configurator rules engine Product configurator data model 3D asset pipeline Configurator BOM generation Product pricing engine Configure-to-order software CAD product configurator Configurator testing and QA

Frequently asked questions

Modular product configurator questions, answered precisely.

The answers separate module composition, variants, bundles, parameters, browser 3D, live pricing, BOM, APIs and technical review.

A modular product configurator is a guided application that creates one valid product or system from governed component instances. Each module has stable identity, permitted interfaces, positions, orientations, neighbours, counts, dependencies, visual bindings and commercial or downstream mappings. The configurator validates the assembly, renders the accepted revision in 3D, calculates its price and can create a quote, configured order or BOM from the same state.

A variant configurator chooses among predefined products or option combinations. A modular configurator creates an assembly whose composition and relationships are part of the result. Two assemblies containing the same module types may still differ because their order, positions, orientations, ports or derived connectors differ. Many solutions combine fixed variants for each module with modular logic for the complete system.

Parametric inputs can define an envelope or calculate module counts, while modular logic selects and connects the actual components. For example, overall width may derive the number and size family of bays; the assembly then inserts the permitted bay modules, joints, posts and end conditions. Save continuous inputs, normalized values, derived composition, module instances and output revision together so neither model becomes an independent truth.

Strong candidates include kitchens, wardrobes, furniture systems, storage, pergolas, verandas, carports, façades, partitions, fences, gates, railings, solar arrays, HVAC systems, electrical packages, industrial machinery, production lines, conveyors and packaged equipment. The common factor is a repeatable catalogue of components whose allowed relationships can be governed. Fully bespoke engineering can remain a review or engineer-to-order path.

A port is a named, typed interface through which one module can connect to another module, a parent system or a project surface. It can carry position, direction, orientation, profile, size, service, capacity, gender, compatibility class and occupancy. A 3D anchor can visualize a port, but the authoritative interface belongs in structured product data so rules, price, BOM and integrations can interpret it.

Represent each module instance and its relationship explicitly. Adjacency rules name the permitted neighbour classes, module IDs, sides, ports or contexts. Sequence rules evaluate ordered predecessors and successors, required stages and forbidden patterns. Keep these rules versioned, explainable and testable. JSON Schema can validate payload structure and conditional fields, but domain-specific product logic still needs an application rule model.

Yes. Derived rules can add joints, brackets, fillers, end panels, supports, adapters, caps, hardware, controls, cables, services or review tasks from accepted relationships. Derived parts should keep provenance: which rule and assembly relationship created them, their quantity and unit, price identity, downstream identity and revision. Users should understand material changes without needing to configure every fastener manually.

Yes. A runtime can instantiate prepared module assets, attach them to governed anchors, apply allowed transforms, repeat sections and update materials or states. glTF supports hierarchical scenes, nodes, transforms, meshes and materials for runtime delivery, but it does not define product rules. The configurator must keep 3D nodes bound to structured module and assembly identities and test performance with representative maximum assemblies.

Use governed envelopes, opening zones, service zones, installation space and collision groups appropriate to the product. Test not only visible overlap but also door swings, drawer travel, maintenance access, operator or safety zones and project boundaries. Collision can prevent or warn, but it does not independently prove structural, regulatory, ergonomic or installation acceptance unless the required method is explicitly implemented and validated.

Yes. Price can include selected module instances, interface kits, derived parts, finishes, position or orientation effects, quantities, installation, delivery, engineering and other services. Retain currency, market, account, price-list or calculation revision, discounts, tax context and validity. The visual assembly, quote line items and saved project must reference the same accepted configuration revision.

It can create a sales BOM, configurable BOM result or structured configured order when selected and derived module identities map deterministically to governed downstream items and quantities. A manufacturing BOM may add engineering structure, substitutions, effectivity, routings or release control in PLM or ERP. Define the exact BOM class, owner, unit mappings, reconciliation tests and approval boundary before calling an output production-ready.

Store both the stable module definition ID and a unique assembly-instance ID. The instance record should include parent or connected instance, port or slot, position, orientation, quantity, selected characteristics, user or derived origin, applicable revisions and status. Do not use translated labels, array position or 3D node names as the only identity because editing, localization and asset changes can break them.

Exchange an assembly root, unique module instances, typed relationships, stable product IDs, characteristics, units, revisions, commercial context and status through versioned contracts. Use idempotency for create, calculate and handoff operations; reject stale results; record acknowledgements and errors; and distinguish user-selected from derived items. OpenAPI and JSON Schema can document and validate structure, while product semantics remain governed by the implementation.

Publish catalogue, rules, assets, prices and mappings through an explicit release process. Existing saved, quoted or ordered assemblies should reproduce their historical state or follow a documented migration, substitution or review decision. Never silently reinterpret old instance IDs against a new module definition. Record supersession, effectivity, compatibility and the owner who accepts any change to open business.

Test empty, first, repeated, maximum, reordered, replaced, corner, branch, end, mirrored, incompatible, missing-dependency, review-required and historical assemblies. Reconcile instance identity, interfaces, 3D placement, derived parts, price, quote, configured order, BOM and receiving systems. Include rapid edits, slow responses, retries, role and market restrictions and catalogue changes. Retain input and output revisions as regression evidence.

Route to review when the assembly depends on project-specific structural, thermal, electrical, process, safety, regulatory, site or application conditions outside instant catalogue approval. Preserve the configured state, visualization and commercial context, but make the review boundary visible. Define the trigger, reviewer, evidence, effect on price and lead time, approval result and which outputs must be regenerated.

Timing depends on catalogue quality, number of module classes, interface complexity, rule ownership, 3D asset readiness, pricing, outputs, integrations and review capacity. A guided linear assembly differs from a spatial layout with collision, CAD generation and manufacturing outputs. Start with one representative assembly containing repetition, an interface, an invalid combination and a derived part; use accepted evidence from that build to estimate the wider catalogue.

From module library to accepted system

Prove the complete workflow with one real modular assembly.

Bring the module catalogue, connection logic, source models, price examples and required quote, BOM or order handoff. Configurix can map a representative assembly around evidence your product, sales and technical teams can inspect.

Scope the representative assembly