CP-Solver Architectures

• CP-Solver is a software system that uses constraint-based solving, coordinating propagation, search, and state restoration over structured domains.
• It spans a spectrum from educational minimal solvers like Kiwi to high-performance engines like ACE, emphasizing design trade-offs in architecture and heuristics.
• Portfolio solvers such as SUNNY-CP and learning-guided variants like SeaPearl leverage multicore execution and machine learning to enhance performance and adaptability.

Searching arXiv for the cited CP-solver papers to ground the article in current indexed records. {"queries":[{"q":"id:0701109"},{"q":"id:(Amadini et al., 2017)"},{"q":"id:(Lecoutre, 2023)"},{"q":"id:(Hartert, 2017)"},{"q":"id:(Amadini et al., 2015)"},{"q":"id:(Downing et al., 2013)"},{"q":"id:(Chalumeau et al., 2021)"},{"q":"id:(Wang et al., 23 May 2026)"}]} A CP-solver is a software system for solving problems expressed in the Constraint Programming paradigm, where decision variables range over finite or otherwise structured domains and constraints progressively reduce those domains until a solution, proof of infeasibility, or optimum is obtained. Across the literature, the term covers markedly different artifacts: spreadsheet-fronted systems such as ExSched, educational kernels such as Kiwi, generic open-source engines such as ACE, multicore portfolio solvers such as SUNNY-CP and SUNNY-CP2, optimization-oriented extensions based on unsatisfiable cores, reinforcement-learning-guided solvers such as SeaPearl, and, in a distinct but terminologically adjacent sense, competitive-programming code-generation agents such as CP-Agent 0701109. The common denominator is the orchestration of propagation, search, and model-specific or instance-specific control, but the concrete mechanisms differ substantially in architecture, interface, and theoretical emphasis.

1. Constraint-programming solvers as a systems category

In the core CP sense, a solver maintains variables, domains, constraints, and a search procedure. ACE presents this structure explicitly through packages for problem, variables, constraints, solver, propagation, learning, heuristics, and optimization, with parsing driven by main.Head and options managed by dashboard.Control (Lecoutre, 2023). SeaPearl describes the same abstraction through a Julia-based CPModel containing variables, constraints, and an objective, together with a global search object that tracks the current node, best objective bound, and statistics (Chalumeau et al., 2021). Kiwi reduces the architecture to three main subsystems—state restoration, constraint propagation, and search—precisely to expose the minimal skeleton of a solver (Hartert, 2017).

The basic computational workflow is also stable across implementations. Domains shrink as constraints propagate or decisions are posted; when a contradiction is detected, the solver backtracks and restores an earlier state. ACE frames search as depth-first, chronological backtracking with periodic restarts, and gives a generic node cycle of variable selection, value selection, commitment, propagation to fixpoint, recursion on success, and backtracking on failure (Lecoutre, 2023). Kiwi expresses the same logic with an explicit propagation queue and an iterative DFS over stacks of decisions and node markers (Hartert, 2017). SeaPearl similarly uses DFS by default and creates two child nodes, “$x \leftarrow v$” and “$x \neq v$,” for each branching decision (Chalumeau et al., 2021).

This suggests that “CP-solver” is best understood not as a single algorithmic design, but as a family of solver architectures sharing a propagation-and-search core while differing in representational choices, heuristics, integration surfaces, and cooperation models.

2. State restoration, domains, and propagation kernels

A central implementation issue is state restoration. Kiwi adopts a generic trailing mechanism with a global Stack[Change] for undo closures and a Stack[Int] of node markers; backtracking pops the saved trail size and calls undo() on stored changes until the trail is restored to that point (Hartert, 2017). SeaPearl also uses a “trailing” mechanism, explicitly noting inspiration from OscaR, Choco, and MiniCP, and invokes a fix-point procedure that repeatedly calls each constraint’s propagator until no further reduction is possible (Chalumeau et al., 2021). ACE uses reversible structures more aggressively in its domain layer: VariableInteger domains are represented by a reversible “dancing links” structure, SetLinkedFinite, with specialized classes for contiguous ranges, arbitrary enumerations, and binary domains (Lecoutre, 2023).

Propagation itself ranges from generic arc consistency to dedicated global filtering. ACE enforces Generalized Arc Consistency through a generic AC3^rm engine and dispatches more efficient propagators when available via SpecificPropagator.runPropagator(evt) (Lecoutre, 2023). For extension constraints, it supports Valid-Allowed, Simple Tabular Reduction variants, and Compact-Table, with the latter achieving bit-parallel filtering in $\mathcal{O}(\lceil e/w\rceil + d)$ and reported as often $2\text{–}5\times$ faster than STR3 on benchmark suites with up to $n \approx 10^4$ variables and tables with $e \approx 10^6$ tuples (Lecoutre, 2023). For global constraints, ACE lists specialized propagators for allDifferent, cumulative, sum, knapsack, element, channel, precedence, and others, with concrete complexity statements such as Régin-style allDifferent filtering in $O(n\sqrt{n})$ time and sum reductions in linear time (Lecoutre, 2023).

Kiwi shows the same ideas in stripped-down form. Variables expose watcher registration for domain events such as lower-bound or upper-bound changes, and propagators are enqueued only when relevant events occur (Hartert, 2017). The example LowerEqual(x,y) constraint demonstrates event-driven propagation by updating x.max and y.min while subscribing to just those changes that can affect consistency (Hartert, 2017). A plausible implication is that Kiwi’s design isolates the essential semantics of event-driven propagation without the algorithmic breadth of industrial engines.

3. Search control, heuristics, and optimization mechanisms

Search in CP-solvers is shaped not only by branching order but also by restart policies, conflict treatment, and optimization strategy. ACE employs depth-first search with geometric or Luby restarts and implements many variable-ordering and value-ordering rules (Lecoutre, 2023). Its documented variable heuristics include dom/wdeg^CACD, frba/dom, pick/dom, randomized selection, degree, impact, and activity, while value heuristics include First, Last, Rand, Robin/RunRobin, and BIVS (Lecoutre, 2023). The --rr mixed strategy rotates among early-, midway-, and late-conflict treatments, and in the 2024 XCSP3 competition the ACE-mix version outperformed the default ACE across satisfaction, optimization, and unsatisfiable tracks (Lecoutre, 2023).

Optimization in generic CP-solvers is frequently realized by Branch-and-Bound. ACE formalizes this through an Optimizable constraint $\mathtt{obj} < B$, with OptimizerDecreasing initializing $B \gets +\infty$, tightening it to $c-1$ whenever a solution of cost $x \neq v$0 is found, and continuing until the last found solution is optimal (Lecoutre, 2023). It also provides increasing and dichotomic alternatives (Lecoutre, 2023). SeaPearl supports minimization by default in the model object and allows reinforcement learning to guide value selection while the underlying CP engine still performs exact search and can prove optimality (Chalumeau et al., 2021).

Unsatisfiable-core methods alter this optimization picture for soft constraints. In the LCG setting, each soft constraint is reified by an indicator $x \neq v$1, and the objective is written as

$x \neq v$2

Because every failure in the CP propagator chain becomes a SAT conflict, the solver can extract an unsatisfiable core over the currently enforced indicators (Downing et al., 2013). The paper adapts WPM1/MSU1 and MSU3 to this setting and reports that, on soft-precedence RCPSP benchmarks with a $x \neq v$3 s time limit and $x \neq v$4 GB memory, both WPM1 and MSU3 inside CPX outperformed plain branch-and-bound by one to two orders of magnitude on nearly all relaxed cases $x \neq v$5, with many instances dropping from minutes or time-outs to sub-seconds (Downing et al., 2013). This demonstrates that, within CP-solvers equipped with Lazy Clause Generation, optimization can be driven not only by incumbent improvement but also by conflict-structured relaxations borrowed from MAXSAT.

4. Portfolio and multicore CP-solvers

A major line of research treats a CP-solver not as a single engine but as a portfolio controller over heterogeneous constituent solvers. SUNNY-CP is described as a parallel, black-box portfolio solver for Constraint Programming that repeatedly won the Open class of the MiniZinc Challenge, with gold medals in 2015 and 2016 (Amadini et al., 2017). Its portfolio typically contained 10–14 solvers spanning pure Finite-Domain engines, Lazy Clause Generation solvers, MIP back-ends, SAT/SMT hybrids, and proof-producing engines (Amadini et al., 2017). For each MiniZinc instance $x \neq v$6, it computes a feature vector $x \neq v$7, retrieves $x \neq v$8-nearest neighbours under Euclidean distance, and constructs a sequential schedule $x \neq v$9 whose total time is $\mathcal{O}(\lceil e/w\rceil + d)$0 (Amadini et al., 2017).

When multiple CPU cores are available, SUNNY-CP maps that sequential schedule to a parallel execution plan by assigning the first $\mathcal{O}(\lceil e/w\rceil + d)$1 promising solvers to dedicated cores and packing the remaining solvers onto the last core with linearly widened time slices (Amadini et al., 2017). For optimization problems, it adds a bound-sharing mechanism: when one solver finds a tighter bound, other solvers may be interrupted and restarted with that bound if they have not improved recently or their incumbent is strictly worse (Amadini et al., 2017). The paper identifies strengths such as robustness on very small and heterogeneous test sets and synergy among FD, LCG, MIP, and SAT paradigms, but also limitations including vulnerability to incorrect constituent solvers, scheduling overhead on easy instances, and restart-induced loss of internal search progress (Amadini et al., 2017).

SUNNY-CP2 generalizes the same idea to a multicore, dynamic, cooperative, and simultaneous execution framework for CSPs and COPs written in MiniZinc (Amadini et al., 2015). Its architecture has two phases: pre-solving, which may launch a static schedule while feature extraction and neighbour computation proceed in parallel, and solving, where the dynamic schedule computed by SUNNY is parallelized across $\mathcal{O}(\lceil e/w\rceil + d)$2 cores (Amadini et al., 2015). The solver uses a waiting threshold $\mathcal{O}(\lceil e/w\rceil + d)$3 and a restarting threshold $\mathcal{O}(\lceil e/w\rceil + d)$4 so that active improving solvers are not interrupted prematurely, while stale solvers can be restarted with the global incumbent bound (Amadini et al., 2015). Empirically, with 4 cores it solved $\mathcal{O}(\lceil e/w\rceil + d)$5 of CSP instances versus $\mathcal{O}(\lceil e/w\rceil + d)$6 for sequential sunny-cp, with average time approximately $\mathcal{O}(\lceil e/w\rceil + d)$7 s versus $\mathcal{O}(\lceil e/w\rceil + d)$8 s; on COPs, with 8 cores it solved $\mathcal{O}(\lceil e/w\rceil + d)$9 versus $2\text{–}5\times$0 for sunny-cp, achieved a score of $2\text{–}5\times$1 versus $2\text{–}5\times$2, and an area of $2\text{–}5\times$3 s versus $2\text{–}5\times$4 s (Amadini et al., 2015). The reported RCPSP case study, where bound sharing reduces total solving time to approximately $2\text{–}5\times$5 s, illustrates how a portfolio CP-solver can outperform even an oracle that always chooses the best single constituent solver (Amadini et al., 2015).

5. Interfaces, modeling surfaces, and educational minimalism

Not all CP-solvers present themselves as low-level engines. ExSched defines a markedly different interface paradigm by implementing a general tool as a plug-in for Microsoft Excel [0701109]. The traditional spreadsheet model attaches arithmetic expressions to cells; ExSched generalizes this so that finite-domain constraints can be attached to individual cells and solved directly [0701109]. The target problem class is explicitly “constraint satisfaction problems that can be modeled as 2D tables,” including scheduling problems, timetabling problems, and product configuration [0701109]. ExSched is further characterized as a spreadsheet interface to CLP(FD) that hides the syntactic and semantic complexity of CLP(FD) and enables novice users to solve many scheduling and timetabling problems interactively [0701109].

At the opposite end of the design spectrum, Kiwi is a minimalist solver specifically designed for education and deliberately not meant to replace full-featured engines (Hartert, 2017). Its scale—approximately 200 lines of Scala—and its emphasis on clarity, conciseness, and maximal modularity are central design facts rather than incidental implementation choices (Hartert, 2017). New variable types, new constraints, and new heuristics can be added by implementing small abstract interfaces, without changing large amounts of framework code (Hartert, 2017). The contrast with industrial solvers is explicit: Kiwi has only interval domains, a single binary constraint example, and a single search strategy, whereas systems such as Gecode, Choco, and OR-Tools provide dozens of global constraints, richer variable types, advanced search, optimization, learning, and parallelism (Hartert, 2017).

SeaPearl occupies an intermediate position. It is not presented as an industrially dominant engine, but as a pure-Julia proof of concept that provides a flexible and open-source framework for studying the hybridization of CP and machine learning (Chalumeau et al., 2021). Its modeling API exposes solver construction, variable declaration, posting of constraints such as NotEqual and LessOrEqual, objective assignment, and a solve! entry point (Chalumeau et al., 2021). This suggests a recurrent design tension in CP-solver research: whether the primary objective is accessibility for domain users, didactic transparency for students and researchers, or raw solving performance.

6. Learning-guided and feedback-driven extensions

Machine learning enters CP-solvers in multiple ways. In portfolio systems such as SUNNY-CP and SUNNY-CP2, learning appears as algorithm selection based on instance features and $2\text{–}5\times$6-nearest neighbours over a historical corpus (Amadini et al., 2017, Amadini et al., 2015). In SeaPearl, learning moves inside the search process itself. The solver embeds a generic reinforcement-learning environment $2\text{–}5\times$7 directly in CP search, where state includes original-problem features, current CP-model state, and solver statistics; actions select a value for a chosen variable; transitions post the branch and rerun propagation; and rewards can be either a constant step penalty or a two-phase objective-sensitive shaping (Chalumeau et al., 2021). The paper uses a Q-network $2\text{–}5\times$8, deterministic Bellman targets, replay buffers, minibatch updates, target-network synchronization, and $2\text{–}5\times$9-greedy exploration (Chalumeau et al., 2021).

The empirical picture is mixed but technically informative. For Graph Coloring, after 600 training episodes and 13 h, the Q-agent’s average nodes per instance decreased from approximately $n \approx 10^4$0 to approximately $n \approx 10^4$1, matching the Min-value heuristic; for TSPTW, after 3,000 episodes and 6 h, the Q-agent explored about $n \approx 10^4$2 fewer nodes than the “closest-city” greedy heuristic, but raw solving time remained higher due to neural inference cost at each node (Chalumeau et al., 2021). The limitation is therefore not completeness but control overhead.

A terminological complication arises with CP-Agent. Despite its name, it is not a constraint-programming solver; “CP” denotes competitive programming (Wang et al., 23 May 2026). Its object of study is feedback-driven code generation by LLMs, modeled as a calibrated stopped process with certificate state $n \approx 10^4$3, residual false-admission score $n \approx 10^4$4, and structural certificate

$n \approx 10^4$5

Its mechanisms—Dual-Granularity Verification, Test Augmentation, and Experience-Driven Self-Evolving—raise Pass@1 on LiveCodeBench Pro from $n \approx 10^4$6 to $n \approx 10^4$7 and improve Refine@5 on ICPC-Eval by $n \approx 10^4$8 without parameter updates (Wang et al., 23 May 2026). The inclusion of CP-Agent under the lexical umbrella “CP-solver” is therefore potentially misleading. A common misconception is to read all “CP” systems as instances of Constraint Programming; the competitive-programming usage shows that the acronym alone is not semantically decisive.

7. Comparative perspective and recurrent design trade-offs

The surveyed systems reveal several recurring trade-offs.

Dimension	Representative systems	Reported emphasis
Interface-centric CP solving	ExSched [0701109]	Spreadsheet paradigm, 2D tables, CLP(FD) hidden behind Excel
Educational minimal core	Kiwi (Hartert, 2017)	Generic trailing, modular variables, propagator-driven DFS
Generic high-performance engine	ACE (Lecoutre, 2023)	Table/global propagators, restart-based search, optimization
Portfolio multicore control	SUNNY-CP, SUNNY-CP2 (Amadini et al., 2017, Amadini et al., 2015)	Algorithm selection, time-sharing, parallelism, cooperation
Learning-guided branching	SeaPearl (Chalumeau et al., 2021)	RL inside CP search
Soft-constraint optimization via cores	LCG + WPM1/MSU3 (Downing et al., 2013)	Unsatisfiable-core guidance
Competitive-programming agent	CP-Agent (Wang et al., 23 May 2026)	Risk-controlled feedback-driven code solving

A first trade-off is between solver internals and solver orchestration. ACE invests in strong propagators, domain structures, and heuristics inside a single engine (Lecoutre, 2023), whereas SUNNY-CP and SUNNY-CP2 assume constituent solvers are black boxes and seek gains through instance-specific scheduling and multicore coordination (Amadini et al., 2017, Amadini et al., 2015). A second trade-off is between simplicity and feature richness: Kiwi is intentionally small and intelligible, while ACE is package-rich and competition-oriented (Hartert, 2017, Lecoutre, 2023). A third trade-off concerns learned control versus runtime overhead: SeaPearl shows node reductions but also inference costs (Chalumeau et al., 2021). A fourth concerns correctness and robustness in portfolios: SUNNY-CP explicitly notes that unsound answers from constituents can propagate to the portfolio unless post-validation is applied (Amadini et al., 2017).

Taken together, these works show that the modern CP-solver is not a monolithic artifact. It may be a domain-facing interface to CLP(FD), a research kernel for propagation and backtracking, a full generic solver with specialized propagators and optimization support, a multicore portfolio over heterogeneous engines, or a hybrid search system guided by machine learning. The term therefore denotes a broad technical class whose defining feature is constraint-based solving, but whose most important distinctions arise from architecture, control strategy, and intended research or application setting.