Not All Constraint-Based Systems Are the Same


A Practitioner's Framework for Evaluating Configuration Engines

 

Sanjay Mittal

Founder & CEO
Predictika.ai

 

Email: sanjay@predictika.com

 

 

Executive summary

 

“Constraint-based” is not one technology and treating it as one is the single most common mistake in evaluating configuration software. Oracle, Tacton, Configit, and Predictika all describe themselves this way. So, in a looser sense, did SteelBrick's successors. But underneath that shared label sit genuinely different architectures, and the differences aren't cosmetic — they determine what you can model, how reliably the engine reasons about it, what happens when two rules disagree, and whether the system can survive being talked to in natural language rather than clicked through a wizard. We read the patents — Oracle's, Tacton's, Configit's, and our own — and this paper reports what they say, not what the marketing pages imply.

 

We organize the comparison around four questions, in order, because each one builds on the last: what can you model, how does the engine reason about it, who wins when rules conflict, and can any of that survive a conversational front end. The fourth question is where this stops being an academic exercise — an LLM-driven interface doesn't ask questions in the order a wizard was authored to ask them, and every architectural choice in the first three questions either supports that or quietly breaks under it.

 

This isn't a new argument

 

TThe case this paper makes has a longer history than a single comparison exercise might suggest, and it's worth tracing briefly, because the lineage isn't a private claim — it shows up directly in the record of the very companies compared below.

 

The starting point is COSSACK (Frayman & Mittal, 1987), among the first systems to frame product configuration explicitly as a constraint-satisfaction problem rather than a decision tree or a set of hand-written rules. Its companion paper, “Towards a Generic Model of Configuration Tasks” (Mittal & Frayman, IJCAI 1989), generalized that framing into the model the field still uses — a 2014 literature review in the International Journal of Production Research names it one of exactly two “pioneering articles” that founded academic configuration research, the other being McDermott's 1982 R1 paper on XCON. That's an independent scholarly verdict, not a self-assessment.

 

A year later, “Dynamic Constraint Satisfaction Problems” (Mittal & Falkenhainer, AAAI 1990) generalized the reasoning itself: constraints don't all apply from the start, fixed and static, the way a textbook CSP assumes — they activate as the parts of a structure they govern become relevant, which is exactly the behavior a real, growing configuration needs and exactly the behavior Section 5 below asks each engine to demonstrate. A separate, parallel thread — “Virtual Copies — At the Boundary Between Classes and Instances” (Mittal, Bobrow, Kahn, OOPSLA 1986) — gave the field one of its two foundational papers on prototype-based object orientation, the architectural root of representing a product as structured, inheriting objects rather than a flat list of variables, which is exactly the question Section "What can you model?" opens with.

 

None of this is being retold for its own sake. Every company examined in this paper sits downstream of it, and most say so directly, in their own words, not ours:

 

So, when this paper compares Predictika against Oracle, Tacton, and Configit, it isn't one vendor asserting lineage over its rivals for rhetorical effect. It's closer to comparing several later implementations that all grew from the same well-documented root — some crediting it explicitly — and asking how far each one carried the original argument forward. The rest of this paper is that comparison.

 

1 Not surprising, given that I was behind both the research at PARC and the founding of Selectica.

 

The label problem

 

“Constraint-based” earned its reputation by contrast with the earlier paradigm pioneered by McDermott and his team: rule-based CPQ systems that react to a user's click with an if-then check, discover a conflict only after the fact, and have no way to tell a rep why a choice is unavailable before they make it. Against that baseline, anything that reasons about a whole configuration jointly — rather than clicking through a sequence of isolated checks — looks like a different category of tool, and it is. We made exactly this argument in our first paper in this series; Complex Product Configuration Requires a Constraint-Based Approach.

 

What that argument doesn't tell you is that “constraint-based” covers a wide range of actual engineering: a precompiled Boolean structure representing every possible configuration at once (Configit's Virtual Tabulation), a branch-and-bound optimizer walking a fixed sequence of sub-problems (Tacton), a dynamic constraint-satisfaction solver decomposing a hierarchy into pieces (Oracle's own configurator, distinct from the rules-based product it acquired via BigMachines), and an incremental, change-triggered reasoning server maintaining a persistent object graph (Predictika). All four are honestly, defensibly “constraint-based.” They are not interchangeable, and a buyer who stops at the label has learned almost nothing about which one they're getting.

 

Four questions that separate them

 

We'll take these in turn, each with a worked example and a direct citation to what the patents themselves say — not a paraphrase of a sales page.

 

  1. What can you model? Does the engine have a real object model — classes, instances, inheritance — or a flat set of variables? If it has inheritance, does a subclass inherit only attributes, or constraints too? Can a constraint reference something several levels away in an object tree, or only its local variables?
  2. How does it reason? Does the engine propagate partial information as it becomes available, or only validate a completed selection? Does it re-examine a constraint automatically when something it depends on changes, or only once, or only on an explicit re-run? Does it know the difference between “no solution found yet” and “no solution exists”?
  3. Who wins when rules conflict? When two rules could both apply and disagree, is precedence a declared relationship between them, or an accident of which one happened to load, run, or get selected first?
  4. Can it keep up with how people talk to it? If the order in which information arrives isn't the order the model's author anticipated — which is the normal case for a natural-language front end — does the engine still reach the right answer?

What can you model?

 

The clean test is inheritance: does a component defined once propagate both its attributes and its constraints to every place it's reused, and can a more specific version override either? Every constraint-satisfaction patent we read — Oracle's part-whole hierarchy solver, Tacton's part-of hierarchy engine, Configit's Virtual Tabulation — organizes a product as parts or product variables related by structure or type. None of the three describes a class hierarchy with inheritance. Configit comes closest, with nested record types, but that's a type system for organizing a schema, not a mechanism for one component definition to hand both its behavior and its constraints down to every place it's used, or for a more specific version to override them.

 

Our own patent describes something different: models nest inside other models “to provide reuse such as inheritance, composition, iteration, and recursion,” and “each model has its own entity parameters and constraints. The logic engine applies constraints within each model when it becomes active as well as constraints that span models.” Constraints are inherited alongside parameters, not left behind as a separate concern — and, in practice, a subclass can override either: a parameter's entire shape (symbolic to numeric, a different set of allowed values, a different cardinality) or a constraint's behavior, including turning it off entirely for that subclass.

 

Constraints spanning the object tree

 

A second, related gap: every one of the three competitor patents ties a constraint to a component's immediate relationship to its parent. Oracle's part-whole hierarchy gives each part exactly one formula — quantity equals the parent's quantity times a relative quantity. There's no general way for a constraint anywhere in the tree to reach an arbitrary parameter several levels away. Tacton's decomposition patent goes further in the other direction: it splits a large model into separately solved sub-problems specifically because reasoning about the whole tree jointly didn't scale, and a 2023 product feature (System Configuration) makes the same tradeoff explicit for large systems, connecting the pieces with reactive rules rather than shared constraints.

 

Predictika pioneered a path-expression mechanism, where a constraint can walk an arbitrary chain through the object graph and roll up or expand across a list at any point along that path. There is no equivalent in any of the three patents we examined — and that's not surprising. Tree-spanning constraint reasoning isn't an isolated feature; it requires propagation, backtracking, and object-oriented inheritance all working together, layered on top of each other, which is precisely why it's hard to get right. It's revealing that this capability didn't exist even at Selectica, an earlier constraint-based configurator built by the same team — the research ideas were there from Xerox PARC, but building it to commercial-grade reliability is a different undertaking than having the idea.

 

How does it reason?

 

Correctness and completeness, precisely

 

Two properties define what it means to have solved a configuration problem. A constraint system is correct when every constraint evaluates to true once the information it depends on is available — a constraint whose inputs aren't yet known doesn't fail, it suspends. A solution is complete when every parameter marked as required has been assigned a value, which means the modeling language itself must carry an explicit notion of “required” for the engine to judge this at all. Correctness says nothing is wrong; completeness says nothing needed is missing. Worth crediting where it's due: Oracle's patent does carry an explicit required/optional distinction per part, so completeness in this narrow sense isn't unique to us. What none of the three competitor patents describe is propagation and completeness working together as one substrate, which is the point the next two sections turn to.

 

A different sense of “completeness,” worth disambiguating: Configit's Boolean Decision Diagram approach has a real completeness guarantee too, but of a different kind — not “is this one solution finished” but “can the solver always say for certain whether any valid configuration remains at all.” Because the compiled structure represents every consistent configuration exactly, it can definitively count what's left or prove nothing is, rather than search and possibly miss one. Genuine strength, with a genuine cost: the patent's own text states multiplication is only supported when one operand is a constant, ruling out ordinary variable-times-variable arithmetic — a quantity-times-price rollup, for instance — from the core encoding.

 

Propagation, in both directions

 

Take the simplest possible constraint, x = y. If both are known, checking it is trivial. The useful case is when only one is known: the engine can infer the other, reasoning from x to y or from y to x with no preferred direction. Without that, an engine can do nothing until a user happens to supply both values — and because the user rarely knows the hidden relationships in a genuinely complex product, they're likely to pick values that conflict, so the engine can only say “invalid selection” and configuration degrades into guessing. With propagation, the moment one value is chosen, the other is fixed automatically and explainably. In practice, a user needs to make only a handful of key decisions; the rest fall out through propagation, because real products carry enough internal structure to determine them.

 

All three competitors do real propagation at some level — this isn't a place where the comparison is lopsided. Oracle's most sophisticated patent in this area describes exactly the behavior you'd want from a real constraint solver:

 

“For each of the created runtime constraints, the solver propagates the constraint and determines if the propagation generates a conflict. If the propagation generates a conflict, the solver dismisses the constraint and reverts the model to a state before the constraint was propagated.”
— US Patent 8,165,981 (Oracle)

 

Worth being precise about scope: that patent's stated purpose is preserving a solving session's structure when a new session starts or is duplicated, not a demonstrated claim that every constraint anywhere in a live session keeps re-firing indefinitely as any parameter changes. Tacton's engine does re-solve when a user goes back and changes an earlier answer, but only through an explicit, separately-modeled “backing command” — nothing re-fires unless that specific mechanism is invoked. Configit's approach is different in kind: because the whole configuration space is precompiled into one Boolean structure ahead of time, each new selection restricts that structure freshly from an unchanging source of truth, rather than incrementally propagating from whatever just changed.

 

Our own engine's mechanism is automatic and change-triggered: a constraint re-fires the moment a parameter it depends on changes, in a sweep that itself repeats until nothing further changes. The distinction that matters isn't “does it propagate” — all four do, to varying degrees — it's whether that propagation is something the engine does by construction, or something that must be explicitly invoked, or re-derived fresh each time.

 

Backtracking is a separate capability, and it's where the gap is sharpest

 

Propagation earns its power at a cost: chaining inferences offers no guarantee the result stays consistent, and a sequence of individually valid steps can drive the system toward a contradiction — an attempt to assign two different values to the same parameter. An engine that propagates must be able to recover, by maintaining a context tree of the free choices made along the way and backtracking to the last logically consistent state the instant a contradiction appears. This isn't optional bookkeeping. From a contradiction, logicians have a name for what follows — ex falso quodlibet, a false premise entails every conclusion — and an engine that can silently sit in an inconsistent state is worse than one that can't reason at all: it asserts nonsense with full confidence.

 

Measured against that specific bar — automatic, contradiction-triggered backtracking to the responsible choice point, not just “the user can undo” — the comparison sharpens further. Oracle's propagate-and-revert, quoted above, is real automatic backtracking within one propagation cycle, and deserves credit as the closest of the three to this bar. It’s worth noting we don’t actually know which version Oracle ships commercially — the patented CSP engine described here, or the BigMachines-derived rules product, which is fundamentally the older, less capable paradigm. Tacton's recovery is manual: a contradiction doesn't trigger anything on its own; the user must invoke the backing command, which then re-solves forward from wherever they chose to step back to. Configit's architecture doesn't really need to backtrack in the inference sense at all — because nothing is inferred through a chain of intermediate steps, a conflicting selection is simply rejected outright and the prior state is kept, which sidesteps the problem rather than solving it the way genuine dependency-directed backtracking does. Of course, the price ConfigIt pays is that it cannot handle numerical expressions very well: it's suitable for discrete enumerated values.

 

What the substrate makes possible

 

Once correctness, completeness, propagation, and backtracking are all in place, a family of higher-order services follows from the same machinery rather than needing to be built separately — and it's worth being fair about which of these the competitors already have some version of, rather than claiming the whole list as uncontested.

 

The pattern is less “we alone have these” and more that each competitor has built one or two of these services well, on its own substrate, without the other three — whereas on our engine they're the same underlying mechanism (propagate, detect contradiction, backtrack) exercised four different ways, which is what lets them compose rather than requiring separate tooling per service.

 

Hard and soft constraints

 

Oracle's patent is the most explicit of the three competitors on this point, defining a soft constraint directly: “a constraint that is not mandatory and can represent a preference on the part of a modeler when, for example, selecting defaults.” Our own engine draws the same line more granularly — chosen per constraint, by whether its consequence is checked (a soft violation that produces an explanatory message) or asserted (a hard requirement that fails and triggers backtracking) — which lets a modeler decide, rule by rule, whether a violation should block the interaction or simply inform it. It's also the mechanism that lets the engine cooperate with an LLM rather than simply gate it: a soft constraint's message can be routed back to the model as a re-prompt — “this choice doesn't work, try again” — rather than a hard failure the conversation can't recover from.

 

Who wins when rules conflict?

 

This is where a real, previously diagnosed production bug becomes the clearest illustration. In legacy Salesforce CPQ implementations, a negotiated Enterprise Agreement rate and a standard volume-tier discount can both apply to the same line item, and which one wins is determined entirely by an admin-configured rule-ranking field — nowhere declared, nowhere validated, resolved silently by whichever rule happens to be ranked higher. That's not a hypothetical; it's a documented, common source of wrongly stacked discounts, and wrong stacking is a revenue-recognition problem, not just a worse deal.

 

None of the three constraint-based competitors solves this cleanly either, and it's worth being specific about why, since “we're constraint-based” is not by itself an answer to “how do you declare precedence”:

 

Our own engine resolves this with an explicit guard parameter, declared once as part of the model: a higher-priority constraint sets it when it applies, and a lower-priority constraint checks it before firing. Because both are evaluated in the same change-triggered sweep described in Section "What can you model?", the result doesn't depend on which fact happened to arrive first — it depends on what the model declares.

 

Can it keep up with how people talk to it?

 

This is the question the other three build toward, and it's the one a wizard-based UI never had to answer, because a wizard controls the order questions get asked. An LLM front end doesn't: a user might say “give me a large pepperoni and a Pepsi” in one turn, state something out of the sequence the model's author anticipated or revise a decision from several turns back. An engine that only reaches the right answer when information arrives in the order it was authored for will either force the LLM to walk the conversation through that fixed order — defeating the point of a natural-language interface — or produce results that silently depend on how the conversation happened to go.

 

Two of the three competitors are explicit about this in their own patent text, not by implication:

 

“The step instances are executed sequentially... solving the CSP of the step instance based on the user-committed settings and any variable values resulting from any preceding step instances in said sequence.”
— US Patent 8,078,562 (Tacton)

 

Tacton's architecture is sequential by design — a fixed order of steps, each seeing only what preceding steps already committed. Configit's conflict resolution, covered in Section "How does it reason?", is similarly order-sensitive: the same set of facts, given in a different sequence, can produce a different accepted-versus-rejected outcome. Oracle's core solver doesn't describe a fixed step order the way Tacton's does, which is a real point in its favor here, but the separate patent covering its “procedural constraint engine” wraps an explicitly named “stateless constraint engine” (an off-the-shelf solver, ILOG CP, named directly in the patent) with a hand-built layer that manually stores and checks results across calls — because the underlying engine itself carries no memory between them.

 

Our own engine's data-flow model — “constraints and rules are executed only when the data is available or changes and not in a pre-specified sequence” — paired with a persistent context tree that lets the engine navigate to any earlier choice and recompute consequences, is what lets a conversational front end supply information in whatever order the conversation actually takes, and still land on the same answer it would have reached any other way.

 

Why this matters now

 

Every one of the gaps above was survivable, or at least tolerable, behind a wizard UI, because the wizard itself imposed the order and absorbed the awkwardness. An LLM front end removes that buffer. It doesn't just add a new interface on top of the same engine — it stress-tests exactly the four properties this paper walks through, simultaneously, on every turn of every conversation. A system that models flatly, propagates only on explicit trigger, resolves conflicts by accident of arrival order, and only works in its authored sequence isn't a worse version of a conversational configurator. It's a different kind of system being asked to do a job it wasn't built for.

 

A short checklist

 

Five questions worth asking any vendor who describes their product as constraint-based, before assuming the label answers them:

 

Questions to ask a configuration vendor about constraint inheritance, cross-tree references, automatic re-checking, rule precedence and out-of-order input, and what a vague answer usually means

None of this is an argument that the other three are poorly built — Oracle's, Tacton's, and Configit's engines each solve real problems well, and each has at least one property worth crediting on its own terms, noted above rather than glossed over. It's an argument that “constraint-based” was never a sufficiently precise claim to evaluate a vendor by, and that the four questions above are a more useful place to start than the label.

 

 

 

About Predictika

 

Predictika.ai builds a patented constraint-based configuration and pricing engine rooted in a research lineage that runs from Xerox PARC through Selectica, the enterprise CPQ pioneer whose customers included IBM, Cisco, Dell, GE, Hitachi, Disney, and AT&T. Predictika's declarative modeling language, LVML, carries forward a distinctive prototype object-oriented architecture in which sub-entities inherit both parameters and constraints from the structures that contain them — a direct technical descendant of that PARC lineage. The company holds patents covering deterministic validation of LLM-driven systems (U.S. 11,544,475 and 11,914,970).

 

About the author

 

Dr. Sanjay Mittal is the founder and CEO of Predictika.ai. His work in constraint-based AI began at Xerox PARC and was first commercialized through Selectica, a company he founded in 1996 and led its IPO in 2000. At Selectica he helped build one of the first enterprise CPQ platforms architected for the internet. Predictika continues that lineage, applying constraint reasoning to configuration and pricing problems across data center infrastructure, cloud pricing, and other domains where interdependent decisions must be reasoned about jointly.

 

Suggested Further reading

 

" You May not Realize it, But Your Business has a Configuration Problem " – explains how to determine whether you have a complex enough configuration problem.

 

" Complex Product Configuration Requires a Constraint-Based Approach " — the technical case for constraint-based configuration, with architecture and object-model detail.

 

" The Business Case for Constraint-Based Configuration " — a condensed overview for CIO/COO/CRO audiences.

 

" Requirements for a Constraint Server Behind an LLM Front End " — the propagation, completeness, and consistency requirements referenced in Section "How does it reason?", in full technical depth.

 

" Pricing Is a Configuration Problem " - A Constraint-Based Approach to Enterprise Quote-Time Pricing, the Section "What can you model?" argument, developed at length with a Google Cloud worked example.

 

" Guiding AI Agents to Reason Correctly " – shows how Predictika constraint engine can act as a reasoning co-pilot to existing AI Agents to ensure correct behavior.

 

" Beyond SteelBrick: A Constraint-Based Path Forward for Salesforce CPQ Customers " — the same architectural comparison applied specifically to legacy Salesforce CPQ, with worked configuration and pricing examples.

 

Bibliography

 

Foundational papers

 

Predictika and Selectica patents

 

Competitor patents examined for this comparison

 

Selected literature citing this work

 


Copyright © Predictika Inc. 2026