Constraint Filtering¶

A screening method — instantiates Search Space Pruning

Removes any candidate that fails a hard, must-satisfy requirement using a cheap feasibility check, so expensive evaluation is spent only on options that could actually qualify.

Constraint Filtering narrows a space by applying hard requirements — the non-negotiable musts — and dropping everything that fails even one. Its defining feature is the pairing of an explicit constraint set with a cheap feasibility test that runs before any deep evaluation: rather than scoring a candidate and then noticing it was ineligible all along, it checks the disqualifying conditions first and spends the costly assessment only on survivors. Unlike Dominated-Option Removal, it never compares candidates to each other — a candidate is dropped purely for failing an absolute threshold, not for being worse than a rival. And unlike a heuristic screen, the criteria are meant to be genuine hard constraints (budget, capacity, compatibility, timing), so a pass/fail is decisive rather than suggestive.

Example¶

An engineering team is choosing a structural alloy for a component that will sit in a pump running at 260 °C under continuous load, from a materials database of ~4,000 alloys. Before running any of the slow, expensive fatigue-life and cost-of-machining models, Constraint Filtering applies the hard requirements: service temperature ≥ 300 °C rating, yield strength above the load spec, corrosion class compatible with the fluid, and available from an approved supplier. Each is a fast lookup or inequality. The filter drops every alloy that fails any one — roughly 3,900 of them — leaving ~90 that could qualify.

Only those 90 go into the costly simulations. The team never wastes a fatigue run on an alloy that would melt, and the pass/fail record shows exactly which requirement eliminated each reject. The point is not that the 90 are good — that comparison comes later — only that the other 3,900 were provably out of bounds.

How it works¶

State the hard constraints — the must-satisfy conditions, each a clear pass/fail, kept separate from mere preferences.
Order by cheapness and cut power — run the fastest, most-eliminating checks first so most candidates fall before any expensive test.
Test feasibility, not quality — each check asks only "could this candidate satisfy the requirement?", not "is it good?".
Drop on any failure — one failed hard constraint removes the candidate; survivors pass to deeper evaluation.

What distinguishes it is the sequencing: feasibility is established up front and cheaply, so the exclusion is an absolute gate, not a byproduct of scoring.

Tuning parameters¶

Constraint strictness — where each threshold sits. Tighter cuts more but risks excluding candidates that only marginally fail; looser keeps borderline cases at more downstream cost.
Hard vs. soft split — which requirements are true gates versus preferences that should only rank candidates. Misclassifying a soft preference as a hard constraint is the main way this filter over-prunes.
Test fidelity — how exact the feasibility check is; a cheap proxy check may wrongly pass or fail borderline candidates, trading accuracy for speed.
Check ordering — running the most-eliminating, cheapest constraints first minimizes total evaluation work.
Margin / tolerance band — whether candidates just inside a threshold are flagged for review rather than auto-passed or auto-cut.

When it helps, and when it misleads¶

Its strength is efficiency with a clean rationale: it removes the provably-ineligible early, concentrating scarce evaluation on candidates that could actually work, and every exclusion carries a specific failed requirement. When the disqualifiers are truly hard and cheaply testable, it is the first move to make.

It misleads when a soft preference is smuggled in as a hard constraint. Dressing "we'd prefer under $50k" as a gate silently deletes options that were merely expensive, not infeasible — the over-constraint failure mode, where an empty or impoverished survivor set traces back to thresholds that were never truly mandatory.^[1] It also inherits the error rate of its feasibility test: a coarse proxy check can cut a candidate that would have qualified on closer inspection. The guard is to keep the hard-constraint list honestly short, justify each entry as genuinely non-negotiable, and route borderline failures to review rather than straight to the bin.

How it implements the components¶

constraint_filter — it is the constraint filter: the explicit set of hard, must-satisfy requirements applied to every candidate.
feasibility_test — each requirement is a cheap up-front feasibility check that decides pass/fail before any deep evaluation.
pruning_rule — the elimination condition is absolute and per-candidate: fail any one hard constraint and you are out, no comparison to rivals needed.

It does not rank or compare survivors against each other — dominance-based cuts belong to Dominated-Option Removal — and it carries no diversity or audit machinery; false-negative checking is Sample Audit of Exclusions's job.

Instantiates: Search Space Pruning — Constraint Filtering is the hard-requirement screen that feasibly narrows a space before deeper work.
Sibling mechanisms: Dominated-Option Removal · Eligibility Screening · Branch and Bound · Beam Search · Decision Tree Pruning · Negative Keyword Filter · Red-Flag Screen · Safety or Compliance Exclusion · Sample Audit of Exclusions · Shortlisting · Triage Filter

Notes¶

Constraint Filtering is the general-purpose engine that several institutional siblings specialize. Eligibility Screening wraps it in accountability, appeals, and an audit trail for people-facing decisions; Safety or Compliance Exclusion applies it where the constraint is a safety or legal red line and the error preference is deliberately asymmetric. The bare method here supplies the filtering logic; those siblings supply the governance around it.

References¶

[1] In constraint-satisfaction terms, a problem is over-constrained when the requirements admit few or no solutions. An empty survivor set is usually a signal that a preference was mis-encoded as a hard constraint, not that no acceptable option exists. ↩