Constraint

A constraint, in the context of variant management and product configuration, is a rule that restricts which combinations of options or characteristics are simultaneously valid in a product configuration. Constraints eliminate invalid, unbuildable, or commercially meaningless combinations from the variant space Variant Space (ˈver-ē-ənt ˈspās) n. A variant space is the complete set of all valid product variants that can be derived from a product family, defined by its variation points and the constraints between them. , leaving only the set of configurations that are technically feasible and permissible to offer.

Without constraints, a product with ten options each having three values has 3¹⁰ = 59,049 theoretical combinations. After applying constraints — rules derived from engineering logic, commercial decisions, and regulatory requirements — the actual valid variant space may contain only a fraction of that number. This reduction is not a limitation; it is the point. Constraints make the product family manageable by making its boundaries explicit.

Types of constraints

Constraints in variant management fall into several categories based on their origin and structure:

Technical constraints Derived from engineering reality. Certain component combinations are physically incompatible, structurally unsafe, or functionally invalid:

• “If engine = Electric, then exhaust system = None” (physical incompatibility)
• “If axle load class = Heavy, then frame reinforcement = Required” (structural dependency)
• “If housing material = Aluminium, then seal type ≠ PTFE-only” (material incompatibility)

Commercial constraints Derived from business decisions. Certain combinations are not offered for pricing, positioning, or strategic reasons:

• “Option X is only available in the Premium tier, not the Standard tier”
• “Regional variant EU excludes features reserved for US-only certification”

Regulatory constraints Derived from legal or standards requirements:

• “ATEX-certified variants may not include standard (non-ATEX) electrical components”
• “CE marking requires safety relay option when rated above 750W”

How constraints are expressed

Constraints are formally expressed using Boolean algebra Boolean Algebra (ˈbü-lē-ən ˈal-ji-brə) n. Boolean algebra provides the logical operators (AND, OR, NOT) used to define valid product configurations and constraints in variant management and CPQ. — the same logical operators (AND, OR, NOT, IMPLIES) that describe any logical condition:

• Requires (implication): “If A is selected, then B must also be selected” → A → B
• Excludes: “A and B cannot both be selected” → ¬(A ∧ B)
• Conditional availability: “C is only available if both A and B are selected” → C → (A ∧ B)

This formal representation allows constraints to be processed automatically by SAT solvers SAT Solver (ˌes-ˌā-ˈtē ˈsäl-vər) n. A SAT solver determines whether a Boolean formula is satisfiable — used in variant management to validate configurations and navigate large variant spaces. and constraint propagation engines — enabling real-time validation in configurators and automated analysis of the full variant space.

Constraints in configurator systems

In practice, constraints appear under different names depending on the system:

• Dependency rules / configuration rules — In SAP LO-VC and similar ERP-based configurators
• Exclusion and inclusion rules — In CPQ systems
• Cross-tree constraints — In feature models (PLE)
• Procedural variant rules Procedural Variant Rule (prə-ˈsē-jər-əl ˈver-ē-ənt ˈrül) n. Procedural variant rules govern feature models and variant BOMs by executing IF-THEN logic in sequence. Unlike constraints, the result depends on which rules fire first. — IF-THEN constructs that both validate combinations and determine which BOM components apply

The constraint model is the core of any product configurator. Its quality — whether it is complete, consistent, and correctly reflects engineering and commercial reality — determines whether the configurator reliably produces valid, buildable configurations.

Constraint model quality

A constraint model has several failure modes, each with practical consequences:

• Missing constraint — An invalid combination is not excluded; the configurator allows customers to order configurations that cannot be built. Discovered at production time.
• Contradictory constraints — Two constraints together make a previously valid option combination impossible. Detected by SAT solver SAT Solver (ˌes-ˌā-ˈtē ˈsäl-vər) n. A SAT solver determines whether a Boolean formula is satisfiable — used in variant management to validate configurations and navigate large variant spaces. analysis as a dead feature or void configuration.
• Outdated constraint — An engineering change made a constraint obsolete, but the configurator was not updated. The configurator now rejects valid configurations or permits configurations that no longer reflect current engineering.

Managing constraint model quality — keeping it synchronized with engineering changes and regularly validated for consistency — is an ongoing operational requirement in any CTO environment.

Examples

• Office chair configurator — A constraint prevents selecting a mesh back with the heated seat option (the heating element requires a foam back). This constraint is invisible to the customer — the mesh back option simply disappears from the selection when heated seat is chosen — but it prevents an order that could not be manufactured.
• Software platform — A SaaS configurator uses constraints to enforce tier logic: analytics add-ons require at least the Business tier, SSO requires the Enterprise tier, and certain integrations are mutually exclusive with specific compliance modules. Constraints ensure that every configured subscription is commercially and technically valid.

Frequently asked questions