The picture is possible, the product is not
A customer selects a finish, a frame and an accessory. The preview looks convincing, and the basket accepts it. Production later explains that the accessory cannot attach to that frame. The configurator has sold an image instead of a valid product.
Start with the rules that make a selection buildable. Visual quality matters, but it cannot compensate for a configuration that pricing and fulfilment interpret differently. The uncomfortable part is that this work often resembles catalogue maintenance more than interactive design.
For a hypothetical furniture configurator, a finish may depend on the chosen material, while an accessory depends on the frame. Those relationships should be explicit product knowledge, not incidental conditions scattered through interface components.
Keep the commercial configuration outside the scene
A scene can display a selection without becoming the authority for whether it may be ordered. Give the commercial configuration stable option identifiers and a clear validation result. The viewer consumes that result and renders the corresponding state.
Khronos defines glTF as a delivery format for runtime assets, and its material variants extension describes mappings that switch an asset's materials. Neither description supplies the merchant's compatibility policy. The extension specifies the visual mechanism.
Our design recommendation is to maintain an explicit mapping between commercial options and visual assets. A label such as oak should not be the only link between the catalogue and a material embedded in a file. Labels can be translated or renamed while the underlying choice remains the same.
Explain invalid choices before checkout
The interface must decide what happens when a customer changes an option that makes another selection invalid. Silently replacing the accessory produces a plausible picture, but it also changes the product without a clear decision. Leaving it selected produces an impossible order.
A better response is to explain the dependency at the point of change. Show which selection needs attention and offer compatible alternatives. Preserve unrelated choices so correcting the problem does not feel like starting over.
There is room for defaults, provided they are visible and reversible. For a guided configuration, the product team might choose a compatible starting set and show which choices remain provisional. That is different from quietly rewriting a customer's finished selection to satisfy hidden rules.
Revalidate the promise when it becomes an order
A saved configuration can outlive a catalogue update, supplier change or expired quote. Reopening it should identify the rule version and explain any changes needed before purchase. A shareable link should reproduce an intelligible selection, not merely a camera angle.
When the order is submitted, validate the configuration against the applicable commercial rules and calculate the accepted price on the trusted side of the application. Store the agreed configuration with the order so later catalogue edits do not rewrite what was sold.
The fulfilment handoff needs the same clarity. A warehouse or production team should receive the identifiers and instructions required to supply the product, not a screenshot to interpret. If the order can only be understood by looking at the preview, the configuration model is incomplete.
Test incompatible combinations this week
Choose a representative product and gather its actual compatibility rules from the people responsible for supply. Write examples of valid selections, impossible selections and selections that become invalid after a change.
Run each example through the viewer, basket, saved link and order output. Compare the meaning, not just the labels. Then modify a catalogue rule and reopen a saved configuration. The system is ready when it can explain the conflict, preserve unaffected choices and produce an order that operations can fulfil without interpretation.