Complex Product Configuration Requires a Constraint-Based Approach
Why rules and decision trees can't deliver the maintainability or the flexible, AI-ready interaction that complex products demand.
Founder & CEO
Predictika.ai
Email: sanjay@predictika.com
Executive summary
Most “configure price quote” technology was built for products that are essentially lists of options: pick a few choices, apply some pricing rules, generate a quote. For that class of products, it works well. But an important and growing class of products is not like that. Industrial machinery, telecommunications systems, medical devices, and at the extreme end, AI data center infrastructure are deeply structured; their choices interact across subsystems; they are bound by hard physical and engineering limits; and a configuration that is subtly wrong is expensive or impossible to build. For these products the conventional approach, a guided decision tree backed by a growing body of special case rules, fails in two specific and predictable ways. It becomes unmaintainable as the product grows, because the logic multiplies with the combinations rather than the features. And it forces a rigid, fixed order interaction that neither expert users nor modern AI assistants can work within.
This paper makes the case for a different foundation: a constraint-based configuration engine. Instead of encoding the sequence of decisions, a constraint engine works with a description of the product itself, the parameters that compose it and the constraints that relate them, and uses propagation and backtracking to keep every configuration valid no matter what is chosen, in what order, or from which direction. Using a real configuration model for AI data center halls, we show why the architecture that makes a complex model maintainable also makes its user interaction flexible, and why that engine is now the natural deterministic backbone beneath LLM driven configuration assistants.
“Configuration” is two different problems
Configuring products during the sales process (the C of CPQ) really represents a spectrum based on the complexity of the products involved. At one end, guided selling handles products that are fundamentally a short list of compatible options, a laptop with a processor, a memory tier, and a warranty. The choices barely interact, a handful of compatibility and pricing rules suffice, and the interaction is naturally a short, ordered flow.
At the other end, configuring complex products brings new challenges. These products have four properties that change everything: deep structure (a thing built of things built of things); cross cutting constraints (a choice in one subsystem limits a choice in another, several levels away); aggregate quantities (total power, weight, cost, footprint) that must remain inside hard budgets; and a high cost of error, because an invalid configuration is not just suboptimal but unbuildable, unsafe, or stranded.
An AI data center is the archetype: components compose into servers, servers into racks, racks into rows, rows into halls; a single accelerator choice ripples into power, cooling, weight, and network needs; and the aggregate power draw must land inside an envelope that, in 2026, is the single scarcest resource in the industry. The trouble is that most configuration technology treats this second problem as if it were a bigger instance of the first. It isn’t. It is a different problem, and it needs a different engine.
How conventional configurators encode the problem, and where they break
The dominant pattern encodes a configuration as a decision tree - a guided sequence of questions - augmented by procedural rules of the form “if this option is chosen and that one is not, enable this, adjust the price, hide that.” For shallow logic this is transparent and fast to build. It breaks on depth, in three distinct ways.
Maintainability. n a procedural rule base, complexity grows with the number of option combinations, not the number of options. Each new choice can interact with many existing ones, so the rules and branches multiply roughly combinatorially. Logic gets duplicated across branches; a special case fixed in one path silently reappears in another. We have repeatedly seen real configurators accumulate hundreds of hand-maintained special case rules to cover interactions that a declarative model captures in a handful of relations. In one commercial product line, hundreds of hardcoded edge cases collapsed to a compact declarative model. The deeper cost is not just the authoring effort. It is that the model becomes unchangeable: no one can predict every path a change will touch, so every change is risky, and the configurator ossifies.
Rigidity. A decision tree fixes the order of questions, but complex deals do not arrive in a fixed preset order. A serious buyer says, “I need thirty megawatts in this footprint, under this budget, using these accelerators”, an answer to questions that sit several levels apart in any tree, some of them outputs (megawatts) rather than inputs. A tree cannot accept a goal first, partial, or out-of-order specification. It cannot run its logic backward, choose a part and infer its properties, or set a property and narrow the parts. And it cannot answer the question every expert configurator asks: given everything chosen so far, what is still possible? Each of those is a different traversal of the same product, and a tree encodes exactly one traversal.
Silent gaps. A relationship between two choices is not stated once in a tree. It must be re-encoded as a guard in every branch where both are reachable. Miss one branch and that combination stays reachable, and nothing announces the omission: the configurator behaves normally and produces a quote. The defect surfaces downstream, at order entry, in engineering review, or on the factory floor, where it is far more expensive to correct. Testing does not close the gap, because the paths multiply combinatorially and only a fraction can ever be exercised. A constraint model has no branches to forget. The relation is stated once over the parameters it governs, and propagation applies it on every path through the product by construction.
The constraint-based alternative: encode the product, not the decisions
A constraint-based approach starts from a different premise: do not encode the decisions; encode the product. A constraint model is a declarative description of the parameters that make up a product and the constraints, relationships that must always hold, among them. Compatibility, capacity, redundancy, price, and power are each stated once, as relations, independent of the order in which anyone fills things in.
Mechanically, every parameter carries an optional domain, the set of values still possible for it. A constraint relates parameters. When a value is chosen or a domain narrows, the engine propagates the consequences: it narrows other domains, recomputes dependent quantities, and, if a choice has made the configuration unsatisfiable, backtracks to a consistent state. Propagation runs until nothing more changes (a fixpoint), and because domains only ever narrow, the process is monotonic, logically sound and terminates. The engine never sits in an invalid state, and always knows what remains possible. Parameters without explicit domains are initially unbounded but constraints can narrow the domain as they are applied.
A hallmark of constraint-based systems is that a single constraint works in every direction at once. Write “total power must not exceed the provisioned envelope,” and the engine should simultaneously flag an overdraw, cap how many more servers can be added, and remove from selection any server that would breach the limit. You state one relationship; the engine derives every use of it. This is why a constraint model supports interactions a tree cannot: any order, any direction, partial input, and goal first design
One model can then be operated in either of two modes. The engine can drive the conversation itself, ask the next open question and offer only the choices that are still valid, or it can sit silently behind another interface, including a large language model, and validate or repair whatever that interface proposes. The same constraints serve both.
Constraints come in two flavors that matter in practice. Some are advisory: when a situation arises - a power budget exceeded, an incompatible pairing - the engine surfaces guidance that explains what is wrong and why, without blocking the user. Others are hard requirements: violate one and the engine backtracks to keep the configuration buildable. Authors choose, per rule, whether a constraint guides or enforces, which is how one model can be both a forgiving advisor and a strict guarantor.
A worked example: configuring an AI data center
Consider a configuration model for AMD based AI data center infrastructure that we built from publicly available specifications, the kind of model that has to be 100% correct because the cost of error is measured in stranded megawatts.
Structure. The physical hierarchy is expressed as a nested object model. A hall contains rows; a row contains racks; a rack contains servers; a server contains components: CPUs, GPUs, network cards, power supplies, etc. Each level is a model with its own parameters, and a parameter’s value can itself be another model, so the entire design is a tree of objects rather than a flat form.
Rollups. Aggregate quantities flow up that tree. A rack’s peak power is the sum of its servers’ draws; a row’s is the sum of its racks’; a hall’s is the sum of its rows’. Cost, weight, and rack unit consumption roll up the same way. Each aggregate is stated once, as a relation between a level and the level below it, and the engine recomputes it automatically whenever anything underneath changes.
Illustrative declarative form (not product syntax):
Hard constraints. On top of the rollups sit the physical limits: rack unit capacity (the components must fit the rack’s height), the power budget (peak draw must stay within the provisioned and cooling envelope), weight and clearance limits, and matching constraints that pair network ports to switch ports, power supply capacity to load, and redundancy to policy (N+1, 2N). Each is one relation; together they keep every proposed design buildable.
Power as the centerpiece. In 2026 the binding constraint on AI infrastructure is not silicon or capital but electrical power: grid interconnects and transformers run years long, and capacity that cannot be energized is stranded. The model computes peak power at every level of the hierarchy and holds it against the provisioned envelope, so an overdraw is caught while the hall is still being designed, not discovered at energization, after the capital is committed.
Scale and inversion. Because the engine propagates local relations rather than enumerating global combinations, the same model handles a few racks or tens of thousands of entities without a change in approach. And because the constraints run in any direction, the model can be inverted: rather than configuring a design and reading off its power, an author can specify targets - a megawatt figure, a rack count, a budget, a redundancy level - and let the engine search for a valid design that meets them, certifying when none exists. That is the leap from validate my design to design to my goal, and it falls out of the same constraints, written once.
A note on authoring: this model was itself drafted and extended with substantial help from a frontier language model, working from public specifications under human direction. We return to this topic in Section "The LLM’s other role: assist in authoring the models".
Why a constraint model is maintainable
The maintainability argument reduces to a single contrast in how the two approaches grow. A decision tree or rules configurator grows with the number of option combinations, which is multiplicative. A constraint model grows with the number of distinct relationships, which is additive. Add a new server type to a constraint model and you add a catalog entry; it immediately inherits the rollups and constraints that apply to its level, and you touch nothing else. Add the same server to a procedural configurator and you must find and update every branch and rule it could interact with, and hope you found them all.
This follows from three properties. Each fact about the product is stated once, at the level it belongs to, a single source of truth. Constraints are local relationships that compose, with the engine, not the author, responsible for their global interaction. And because the engine guarantees validity by construction, authors reason about relationships in isolation rather than about the exponential space of their combinations.
Declarative modeling has some failure modes one needs to tool around. A constraint that refers to a parameter which never gets bound (through a typo, or because the catalog does not actually carry the attribute the constraint tests) will quietly never fire. It looks identical to a constraint that is simply still waiting for input. We have hit this more than once: a single difference in letter case between a model parameter and a catalog field silently suspended a live constraint, with no error and no obvious symptom. The lesson is not that the paradigm is wrong but that it must be supported by tooling: static analysis and an authoring environment that flag unbound references, type and case mismatches, and constraints that can never activate, before a model ships. This is a tractable engineering problem, and exactly the kind of safeguard a mature constraint platform provides.
There is a related discipline the approach demands: the catalog must be reason grade, not simply transact grade. A configurator can only enforce what its data carries. A parts catalog built for ordering might typically include features such as name, part number, prices, and finishes; a configurator that must reason about fit needs the functional attributes too, such as power draw, thermal output, height, port counts, and redundancy class. Keeping the catalog rich enough for the constraints to act on is part of maintaining a constraint model, and it is far cheaper than maintaining the combinatorial rule base it replaces.
Why a constraint model enables flexible interaction
The architecture that makes the model maintainable makes its interaction flexible, and for the same underlying reason: the model is a set of relations, not a fixed path through them.
Because there is no prescribed order, information can arrive in any order. A user (or an upstream system) can lead with a goal, supply a partial specification, or answer a late question first, and the engine keeps everything consistent and reports what remains possible. Because constraints are bidirectional, inference runs both ways: choose a specific part and its properties propagate outward; set a desired property and the set of admissible parts narrows. The same relations serve both directions, so the author never writes the “reverse” logic.
This is what makes a genuinely mixed initiative dialog possible. The engine can volunteer the next meaningful question, present only the options that are still valid, explain why an option is unavailable by naming the constraint that excluded it, and let the user revise an earlier choice at any time, because revision is simply re-propagation, not a restart. None of this is bolted on; all of it is a consequence of encoding the product instead of the path.
And it is precisely this property that lets a large language model sit on top. The model is fluent at the messy, natural, out-of-order conversation that real configuration requires; it is not, by itself, sound: it will confidently propose configurations that cannot be built. Place the constraint engine beneath it and the division of labor is clean: the language model interprets intent and carries the conversation; the engine guarantees that whatever is proposed is valid, repairs it when it is not, and hands back precise, constraint level reasons that the model can relay in plain language. You get the fluency of the model and the correctness of the solver. For products where errors are costly or regulated, neither is sufficient alone, and the constraint model is what makes the combination trustworthy.
Why an LLM front end makes order independence non negotiable
Section Why a constraint model enables flexible interaction showed that a constraint engine can take information in any order and still guarantee a valid result. With a large language model as the front end, that order independence stops being a convenient capability and becomes a hard requirement, the property without which the interface cannot function at all.
When the interface was a form or a guided flow, the software set the order of the conversation and the user answered in the sequence it posed. A natural language front end inverts that control. The user speaks first, in their own words and their own order, and the model’s job is to honor what they said, not to herd them back into a script. In practice a user will lead with a goal (“I need thirty megawatts in this footprint”), give a lopsided partial specification (several details about cooling, nothing yet about networking), state constraints before selections (a budget and a redundancy policy before any specific part), volunteer facts out of order, change their mind midway, and ask “what are my options now?” in the middle of it all. None of this arrives in an order anyone could have designed for in advance.
This is not a question of interface polish; it is a hard requirement on whatever sits behind the model. The language model translates free form intent into a stream of values and constraints and passes them to the configuration engine in the order they were expressed. If that engine can accept input only in a predetermined sequence - the defining characteristic of a decision tree or a wizard - it cannot consume the stream. A free order interface has been bolted onto a fixed order engine, and the two do not fit. The usual workaround is to have the model quietly collect answers and replay them into the wizard’s expected sequence, but that discards the very flexibility that made the model worth adopting and brings back the scripted, brittle experience it was meant to remove.
A constraint engine has no expected order. It absorbs each value or constraint as it arrives, propagates the consequences at once, and sits in a consistent, fully evaluated state after every input. The model can therefore relay whatever the user said, whenever they said it, and the engine simply takes it in. Partial input is first class: at any moment the engine reports what is now determined, what remains open, and what is no longer possible: exactly the running picture the model needs to carry the conversation forward, ask the right next question, confirm a narrowing, or surface a conflict in plain language. Revision works the same way: when the user says “actually, make it forty megawatts,” the engine re-propagates from the changed value and repairs the configuration instead of restarting from the top of a tree. Natural conversation is full of revision, and an engine that cannot absorb it gracefully cannot host a natural conversation.
The consequence is that the choice of configuration engine is not independent of the decision to put a language model in front of it. Adopting a natural language interface is, implicitly, committing to an order independent engine underneath. A constraint-based engine is that substrate; a decision tree, however well built, is the wrong shape for the work, which is why a constraint engine is not only the better foundation for LLM driven configuration but very nearly a precondition for it.
The LLM’s other role: assist in authoring the models
The language model appears at both ends of the configuration lifecycle. At runtime it is the front end the previous section described. At authoring time it is increasingly the modeler’s collaborator, and this matters, because the limiting cost of constraint-based configuration has never been the engine, even though a proper constraint-based engine is a complicated piece of software that very few have mastered. It has been the human effort of building and maintaining the model.
A constraint model is only as good as the relationships someone takes the trouble to express and the catalog data that stands behind them. Authoring a rich model for a complex product is skilled, painstaking work, and that effort, not just the engine’s capability, has always set the ceiling on what the approach could reach. The power of the technology has been bounded as much by the constraints engine as by the modeling labor it demands.
Large language models change that economics, and they are unusually well suited to the task because it plays to their strengths while being guarded against their weaknesses. Their strength is that they can read specifications, datasheets, catalogs, and existing models and propose the parameters, domains, and constraints that capture them, turning prose and tables into candidate model fragments far faster than a person working from a blank page. Their weaknesses, such as hallucination, inconsistency or unsound reasoning are contained, because the output is not an answer delivered to a customer; it is a model that the engine itself then checks. A proposed constraint that is malformed, refers to an unbound parameter, or contradicts another is caught by the same static analysis and propagation machinery that governs the runtime. The human curates and reviews rather than writing every relation by hand, and the engine, not the language model, remains the arbiter of correctness.
The data center model based on AMD is an example of exactly this. It was drafted and extended with heavy assistance from a frontier model, working from public specifications under human direction: the human owned the relationships and the judgment; the model accelerated their expression. It is a preview of how complex constraint models will be built and maintained going forward
This also closes the loop on maintainability. The two recurring costs of a constraint model are authoring the relations and keeping the catalog reason grade, and language-model assisted authoring attacks both, proposing relations from source material and flagging where the catalog lacks the attributes the constraints will need. What remains essential is human review and the tooling that makes review reliable: the static checks that catch unbound references, type and case mismatches, and constraints that can never fire before a model ships. Language-model drafting paired with deterministic checking is what finally makes rich constraint models affordable to build and safe to change, and it points toward an authoring environment in which the model proposes and the engine continuously verifies, compressing what once took months of expert modeling into a guided, checked workflow. That is how the historical bottleneck of the constraint approach is removed without surrendering its guarantees.
Why this matters now
Two trends converge in 2026. The products being configured are growing more complex and more expensive to get wrong, with AI infrastructure the extreme case: power is the binding constraint, and a hall configured past its envelope strands capital at a scale the industry has never seen. At the same time, the interaction layer is shifting to language models, which are fluent but not sound and therefore need a deterministic engine beneath them wherever correctness matters. A constraint-based configuration engine sits exactly at that intersection: it is both the right core for complex products and the right validator for AI driven configuration.
The market context reinforces the timing. Large configuration platforms are mid migration, which reopens the question of what the configuration core should be; and a constraint engine has the additional virtue that it can be introduced as a validation layer on top of an existing CPQ stack, catching invalid configurations without a disruptive rip-and-replace.
Conclusion
For simple products, a decision tree is perfectly adequate; there is no reason to reach for more. For complex products involving interacting choices, hard physical limits, high cost of error, the decision tree and rules approach fails on exactly the two dimensions that matter: it cannot be maintained as the product grows, and it cannot be interacted with flexibly. A constraint-based engine encodes the product rather than the decisions, and from that single declarative model it delivers both properties at once: maintainability, because relations compose instead of multiplying; and flexibility, because the same relations run in any order and any direction, with a language model on top when natural interaction is wanted. The data center example demonstrates this at the hardest end of the spectrum. The same engine serves the rest of the complex product world.
Suggested Further reading
Requirements for a Constraint Server Behind an LLM Front End
Logic Engines to Guide LLMs for Accurate and Reliable Reasoning — Predictika White Papers (2025)
Guiding AI Agents to Reason Correctly
U.S. Patents in Conversational AI, Symbolic Reasoning, and LLM Governance (granted 2023–2024)
About Predictika
Predictika builds a patented constraint-based configuration engine for complex products, pairing a declarative modeling language with a logic core whose lineage runs from foundational AI research at Xerox PARC to proven, large scale enterprise configuration at Selectica. The company applies that engine both as a configuration core for complex products and as a deterministic validation layer beneath LLM driven assistants, giving natural language systems the soundness that high-cost-of-error domains require.
About the author
Dr. Sanjay Mittal is the founder and CEO of Predictika and the architect of its constraint-based reasoning engine. He began his career as a research scientist at Xerox PARC (1982–1990), with pioneering work in artificial intelligence and constraint reasoning. He went on to found Selectica, which defined enterprise sales configuration (CPQ) for large organizations, building it from inception to a $5 billion IPO in 2000 and serving customers such as IBM, Cisco, Dell, GE, Hitachi, Disney, AT&T, and Reliance. Dr. Mittal was the inventor of Selectica’s industry leading configuration engine and holds six patents from that work. At Predictika he has carried the constraint- based approach into the era of large language models, with further patents - including U.S. Patents 11,544,475 and 11,914,970 - covering the deterministic validation of LLM driven systems. He holds a B.Tech. from IIT Kanpur and a Ph. D. from Ohio State University.
Copyright © Predictika Inc. 2026