Skip to main content

​
Overview

The Configurator handles configure-to-order products: walk an option tree, make selections, pin material attributes, and land a concrete parts list for one real-world order. You can walk it yourself, picking options in the app, or hand it to Dexter, which reads the order document, maps it onto the template, and proposes each decision one at a time for you to confirm. You can override any decision at any point. It operates on three layers: Configurator in the sidebar opens the BOM configurator, a module template. Choose Use this template on it to keep your own copy of the module, which you can ask Dexter to change. The configuration itself holds no state — every fact lives on a revision, and the latest (highest-numbered) revision is the active state. The latest revision is editable in place; committing or revising it copies it forward as a new latest revision, and every earlier revision is read-only. For how this group of artifacts fits together, see the BOMs & Configuration overview.
A configuration template here is its own artifact type, distinct from a Data Pipeline — they are separate entries in the product’s artifact catalog. This page never means a pipeline when it says “template.”

​
The Decision Model

A template presents decisions as option classes — shown in the app as decisions, added with Add category — each with a Selection type:
  • Select one — exactly one option must be chosen
  • Select many — zero or more options may be chosen
  • Select at least one — one or more options must be chosen
Options can carry their own nested materials and option classes. Nested classes only become reachable once the containing option is selected — picking diesel-engine can expose a nested turbo-configuration class that was invisible until then. Once options are decided, each reachable material needs its attributes pinned. Each attribute value uses the same condition types as BOM variant conditions: true/false, a text value, a number value, or a range.
At revision time, prefer fully-pinned values: a single value, or a concrete true/false. A range on a revision usually means a decision is unresolved — treat it as the trigger to ask, not something to leave in place.

​
Phases and Progress

A revision moves through four phases: Picking an option that unlocks nested classes returns the run to selecting_options until the new decisions land. ProDex recomputes where a revision stands from the template and the revision’s current contents after every change:
  • The next decisions — the open option classes and the materials still waiting on values
  • Stale entries — selections or assignments that are no longer reachable given the current upstream selections
  • Errors — structural problems such as unknown option classes or materials, cardinality violations, or unknown entities
  • The resolved parts list implied by the current selections
In the configuration tree, decisions that still need a choice show Needs selection, and materials show Needs values, Assigned, or Stale.
Stale entries and errors must both be resolved before a revision can reach completed. When Dexter drives, it drops stale entries on its own and applies an error repair directly only when there is exactly one valid fix (an obvious typo) — anything ambiguous becomes a decision for you, gated through the same ask-confirm loop.

​
Creating a Configuration

Open Configurator, open a template and choose New configuration. The dialog asks how you’d like to start:
  • Manual — name the configuration and Create it. You land on an empty revision and pick options yourself, one decision at a time, then fill each material’s attribute values along with its Source and Notes.
  • With Dexter — optionally choose an Order document and add Instructions, then Send to Dexter. Dexter reads them in your current chat and writes the configuration.
When Dexter drives, the walk goes like this:
  1. Selecting options. Dexter proposes one option-class decision per round-trip — ask, then write. On confirmation it records the selection, rechecks progress, and moves to the next class. Newly reachable nested classes appear as they unlock.
  2. Assigning materials. For each reachable material, Dexter pins the attribute values. Source-batching: when one grounded source (an ERP extract, an order PDF, a mapping CSV) supplies values for many materials, a single confirmation authorizes the batch and one write lands them all — each assignment citing the same Source. When a value can’t be grounded in a shared source, Dexter falls back to asking per material.
  3. Complete. When the phase reports completed, the resolved parts list is final for this revision.
On Dexter’s path, every selection, every material assignment, and every mid-run template edit is gated by an ask-confirm turn — nothing is written without your confirmation. However a change is made, it lands on the latest revision, which stays editable until you commit or revise it.

​
Provenance: Source, Notes, Revision notes

Three fields carry three different kinds of provenance:
An empty Source is an audit-trail gap — nothing blocks a revision on it. But the whole point of the field is downstream traceability: an assignment no one can trace can’t be evaluated at reconfiguration time. Fill it anyway.

​
Working With Revisions

The bar above the configuration carries the revision actions: Earlier revisions open read-only, showing their resolved parts list.

​
Reconfiguring

When a completed revision needs to change — the customer revised the order, a sourced value turned out wrong, a template edit cascaded — Revise it. The new revision starts as a copy of the latest one:
  1. Keep every unchanged selection and assignment.
  2. Remove the entries that are changing — they become the open decisions.
  3. Resolve any new stale entries or errors, then walk the open decisions to completed exactly like an initial run.
Revision numbers never change, and the numbered chain of revisions is the audit trail.
Prune more rather than less when carrying state forward — remove anything the change might cascade into, even if it’s “probably still right,” and let the walk bring values back with fresh verification. A new revision is cheap, and the revision chain is the audit trail, so keep reconfiguring within it rather than starting over.

​
Mid-Run Template Edits

When an order doesn’t fit the current option set, the template can be edited during the run:
  • With Dexter, the structural change is gated through ask-confirm, written to the template, and a one-line entry is appended to the template’s change log. The walk then resumes against the updated template.
  • In the app, Add custom (the Add custom option dialog), Add category, Add option, and Add material write straight to the template. No change-log entry is added.
Either way, the edit changes the template for every configuration built on it. Flag known gaps at the start of a run — mid-run edits are supported, but they slow the walk.

​
Relationship to BOMs, Planning, and Simulation

  • Configuration Templates are not BOMs — they can’t be used directly in planning or simulation. If something needs to feed the optimizer, build a BOM.
  • Templates produce revisions; each revision carries a per-order parts list.
  • Planning consumes BOMs; simulation references entities directly through model nodes. Neither reads templates or revisions.
  • Feeding a completed revision’s resolved parts list into planning demand is a manual or pipeline-mediated step — completing a revision does not auto-create demand orders.

​
Best Practices

  • Shape the option tree around the customer’s decision sequence, not the manufacturing BOM structure.
  • Keep nesting shallow (2–3 levels). Deep trees are hard to walk and hard to reconfigure.
  • Use Select one only when a “none” option is genuinely invalid — otherwise Select many is more forgiving.
  • Correct early, not late. A wrong selection near the top of the tree cascades through every nested class beneath it.
  • Structured order documents make runs faster. Include part numbers in the order document or a companion file when the ERP can’t be queried live.
  • Let source-batching do its job during material assignment; don’t confirm per material when one source covers many.
  • Fill Notes and Source diligently — they are the audit trail.
  • Write Revision notes as the delta, not the final state.
  • Keep entity definitions in sync with templates — especially a part-number attribute on every referenced entity (see template authoring).