Procedural Variant Rule

A procedural variant rule is a conditional statement — typically expressed as an IF-THEN construct — that governs a configurable product’s feature model or variant BOM by executing actions in a defined sequence. In variant management, this sequential execution model is the defining property of procedural rules: unlike constraints Constraint (kən-ˈstrānt) n. A constraint is a rule that restricts valid option combinations in a variant configuration model, turning a theoretical variant space into a set of buildable configurations. , which express valid configuration relationships independent of evaluation order, procedural variant rules produce results that depend on the order in which they fire.

How procedural variant rules work

A procedural variant rule has the general form:

IF [condition based on current configuration state]
THEN [perform action: set value / include component / restrict option]

When a configuration selection is made, the rule engine evaluates all applicable rules in a defined sequence. Each rule may change the configuration state — setting characteristic values, enabling or disabling options, including or excluding BOM components — and those state changes become visible to rules that execute later in the sequence.

This is what makes these rules procedural: they describe a procedure, a sequence of steps that transforms the current configuration state, rather than a declarative statement about what is and is not valid.

The order-dependency problem

Because each rule can read and modify the same configuration state that other rules act on, the sequence in which rules execute determines the outcome. Two rules that interact through a shared characteristic will produce different results depending on which fires first.

Example:

Rule 1: IF Power_Class = HighVoltage  THEN SET Insulation_Grade = Class_H
Rule 2: IF Insulation_Grade = Class_H THEN INCLUDE high-temp winding assembly

If Rule 1 executes before Rule 2, the high-temp winding assembly is correctly included for every HighVoltage configuration. If Rule 2 executes before Rule 1, Insulation_Grade has not yet been set to Class_H, the condition is false, and the assembly is not included — even though the configuration ultimately satisfies both conditions.

This order-dependency has several practical consequences:

• Adding a rule changes the system at the insertion point. A new rule placed at the wrong position in the sequence can override earlier rules or fail to react to state set by later ones.
• The configuration space cannot be formally analysed from the rules alone. To determine which configurations a rule set actually produces, the rules must be executed — not just read. Formal methods that work well on declarative constraints, such as SAT solvers, cannot directly analyse a procedural rule set.
• Coverage is difficult to verify. Whether the rule set covers all valid configurations — i.e., produces a correct and complete feature model state or BOM for every valid input — cannot be established by inspection. It requires testing representative configurations explicitly.
• Circular dependencies are possible. Rule A can set a value that causes Rule B to fire, which resets a value that Rule A reads. Cycles produce unpredictable or system-specific results.

Procedural rules versus declarative constraints

Constraints Constraint (kən-ˈstrānt) n. A constraint is a rule that restricts valid option combinations in a variant configuration model, turning a theoretical variant space into a set of buildable configurations. in variant management are declarative: they state what is valid without specifying how validity is computed. A constraint such as Engine = Electric → Exhaust_System ∉ valid_options defines a relationship that holds regardless of the order in which constraints are evaluated. A SAT solver can determine, for any partial configuration, which options remain valid — and can verify that the full constraint set is consistent.

Procedural variant rules trade formal analysability for implementation simplicity. A rule IF Engine = Electric THEN EXCLUDE exhaust system is easy to write and directly executable — but the system cannot automatically answer “what configurations lead to exhaust system exclusion?” without simulating the rule sequences explicitly.

Property	Procedural variant rules	Declarative constraints
Execution order matters	Yes — results depend on sequence	No — order-independent
Bidirectional reasoning	No — input → output only	Yes — propagates in both directions
Formal consistency check	Not directly possible	Possible with SAT solvers
Coverage verification	Requires test execution	Can be computed analytically
Implementation effort	Lower	Higher (requires constraint engine)

In practice, many variant management implementations use procedural rules for both BOM derivation and configuration control — because implementing a full constraint engine is expensive and most rule sets are small enough that order-dependency can be managed through documented sequencing conventions.

Examples

• Electric motor family — A configurable motor has rules that set insulation class based on power rating, then include the appropriate winding assembly based on insulation class. Rule sequence is documented and enforced by the configuration tool; reordering the rules produces incorrect BOMs for high-power variants.
• Automotive options — A vehicle configurator uses procedural rules to enable or hide option groups based on prior selections. Selecting “Sport package” triggers rules that restrict paint colours, disable certain interior options, and include sport-specific components. The sequence of these rules determines which options are visible at each configuration step.

Frequently asked questions

Why do procedural variant rules produce order-dependent results?

Procedural variant rules read and modify a shared configuration state in sequence. If Rule A sets a value that Rule B reads, Rule B must execute after Rule A to see the correct state. When rules interact through shared characteristics or BOM positions, execution order determines the result — and the same rule set with a different sequence can produce different configurations or bills of materials.

What is the difference between a procedural variant rule and a constraint?

A constraint declares a relationship between configuration options that holds independently of evaluation order — a SAT solver can analyse all constraints simultaneously to determine what is valid. A procedural variant rule executes an action given the current configuration state and produces an output; the result depends on when the rule fires relative to other rules. Constraints support bidirectional reasoning; procedural rules are inherently directional.

Can procedural variant rules replace declarative constraints?

Procedural rules can perform the same exclusions and inclusions that constraints express, but without the formal guarantees. A rule that excludes an option can silently fail if it fires before the condition that triggers it has been set by a preceding rule. Constraints propagate automatically in both directions; procedural rules require explicit sequencing and are harder to verify for completeness and consistency across the full configuration space.