Constraint-Satisfaction Solver Pass¶

Constraint-solver tool — instantiates Incompatible Requirement Set Resolution

Encodes the commitments as a formal constraint model and runs a solver that propagates them to a reduced feasible region — or mechanically detects that no joint solution exists.

Some incompatibilities are invisible to a human reading the requirements one at a time: every pair looks fine, yet the set as a whole has no joint solution. Constraint-Satisfaction Solver Pass is the automated tool that finds this out by construction. It encodes each commitment as a constraint over variables and domains, hands the model to a solver or rules engine, and lets the engine propagate — repeatedly narrowing each variable's domain by removing values that some other constraint forbids. What comes back is either a shrunken feasible region (the combinations that still survive all constraints) or a domain wipeout: some variable's set of allowed values collapses to empty, which is the machine telling you the commitments, exactly as written, cannot all hold. Its defining move is that it operates the model mechanically and returns what is still possible — it does not judge which commitment is wrong or which should yield.

Example¶

A university registrar must schedule 300 final exams across five days, forty rooms, and a fixed slot grid, under constraints that read as obviously reasonable: no student sits two exams at once, room capacity is never exceeded, lab courses need lab rooms, and three departments have blackout mornings. Nobody can eyeball whether all of this fits. The registrar encodes each exam as a variable whose domain is every (day, slot, room) triple, writes the constraints, and runs a solver pass.

Propagation goes to work: the moment a lab course is pinned to lab rooms, non-lab rooms drop out of its domain; the no-clash rule prunes slot combinations that would collide for any co-enrolled cohort. On the first run the domains shrink from millions of triples to a workable few per exam — a feasible region the scheduler can now search inside. On a second run, after the registrar adds a well-meant "no exams after 3pm on Fridays" rule, one heavily-constrained cohort's exam domain wipes out to empty. That empty domain is the result: the constraints as stated have no joint schedule, and the problem now moves to which rule to relax — not to more manual shuffling.

How it works¶

The pass is constructive narrowing, not a verdict search:

Encode each commitment as constraints over finite-domain (or typed) variables — the shared model every constraint is checked against.
Propagate with consistency filtering (forward-checking, arc consistency): each constraint deletes from its variables' domains any value with no consistent partner, and the deletions cascade until nothing more can be pruned.
Return the surviving region so downstream design proceeds inside what is still feasible — or, if a domain empties during propagation, flag the wipeout as a detected conflict, cheaply, before any full search.

Because propagation is global, it catches set-level conflicts that pairwise review never would; because it returns domains rather than a single answer, it leaves room to choose.

Tuning parameters¶

Consistency level — how hard it propagates: forward-checking is cheap and prunes little; arc- or path-consistency prunes far more but costs more per pass. Stronger filtering catches subtler conflicts and slows every run.
Encoding granularity — how finely commitments are modeled as variables and domains. Finer models expose conflicts a coarse one hides, at the price of a model that can blow up in size.
Propagate-only vs. full search — stop after propagation (fast, returns reduced domains) or continue to search for an actual witness solution (slower, proves feasibility concretely).
Hard-only vs. soft-aware — treat every constraint as hard (crisp feasible / wipeout) or admit weighted soft constraints (hands the ranking off to an optimizer rather than answering yes/no).
Effort budget — a cap on propagation/search time; an incomplete pass may return "unknown" rather than a proven-empty region, which must not be read as "feasible."

When it helps, and when it misleads¶

Its strength is mechanizing what humans cannot hold in their heads: it surfaces global conflicts invisible to pairwise inspection, and instead of a bare yes/no it hands back the actual surviving region for the design to work within. Conflict detection is close to free, because a contradiction shows up as a domain wipeout during propagation^[1] long before a full solution search.

Its verdict, though, is only ever as true as its encoding — a mis-modeled or over-tight constraint produces a confident but false "infeasible," and an under-propagated pass can return a non-empty region that still has no complete solution. The classic misuse is treating a wipeout as the answer — "the solver says it's impossible, so we give up" — when the pass has localized nothing about which commitment to loosen or under whose authority. The discipline that keeps it honest is to validate the model against intent before trusting either result, and, on infeasibility, to route the model to core-extraction and relaxation rather than declaring defeat.

How it implements the components¶

Constraint-Satisfaction Solver Pass realizes the modeling-and-feasibility machinery of the archetype — the parts a solver actually operates:

joint_satisfiability_model — it encodes the commitments into the single formal constraint model that joint satisfaction is evaluated on.
feasible_set — its output is the feasible region: the reduced surviving domains, or their emptiness.
consistency_criteria — propagation operationalizes the definition of "jointly consistent," applying it across the whole model at once rather than pair by pair.

It does not extract the smallest conflicting subset or issue a checkable proof of impossibility — that is Minimal Unsatisfiable Core Extraction and SAT/SMT Satisfiability Check; nor does it choose which constraint yields, which belongs to Constraint Relaxation Experiment and Pareto Frontier Analysis.

Instantiates: Incompatible Requirement Set Resolution — the solver pass supplies the mechanical feasibility check the whole resolution hangs on.
Sibling mechanisms: SAT/SMT Satisfiability Check · Minimal Unsatisfiable Core Extraction · Compatibility Matrix · Requirements Traceability Matrix · Proof Checking · Constraint Relaxation Experiment · Pareto Frontier Analysis · Scenario Sensitivity Sweep · Scope-Boundary Stress Test · Stakeholder Frontier Review · Impossibility-Theorem Instantiation Review · Weighted MaxSAT or Soft-Constraint Optimization · Decision Record with Residue

Notes¶

The solver pass answers whether the set is jointly satisfiable and what survives — deliberately not why it failed. When it reports a wipeout, the "why" (the minimal conflicting core, a human-readable explanation) is a separate job; keeping the two apart is what lets a team trust the feasibility verdict without waiting on the diagnosis, and re-run the pass cheaply each time a constraint is edited.

References¶

[1] Constraint propagation — repeatedly enforcing local consistency (e.g. arc consistency, as in the classic AC-3 algorithm) so that impossible value-combinations are pruned before search. A contradiction manifests as a domain reduced to empty; this is why a solver can often report infeasibility without ever enumerating a full assignment. ↩