Constraint Matrix¶
Feasibility matrix — instantiates Problem Space Mapping
Cross-references candidate options against every constraint in one grid, so the feasible region — and which combinations are simply ruled out — becomes visible at a glance.
A Constraint Matrix lays out candidate options (or states, or paths) along one axis and the constraints they must satisfy along the other, then fills each cell with a pass / fail / conditional verdict. Its defining job is not to describe the options and not to pick a winner — it is to make the feasibility structure of the space visible: which options survive every constraint, which are eliminated, and — crucially — which constraints are doing the eliminating. Because every option meets every constraint in the same grid, the matrix exposes patterns a prose discussion hides: a single constraint that quietly kills half the field, or a "requirement" that, once written in a column and tested, turns out to be a preference no one can source. It is the mechanism you reach for when the problem is not which option is best but which options are even allowed.
Example¶
A university lab is choosing subsystems for a shoebox-sized CubeSat. There are five candidate onboard computers down the left column; across the top are the hard constraints: mass budget, peak power draw, radiation tolerance for the target orbit, flight-heritage requirement, and unit cost. They fill the grid. Board A passes everything but blows the power budget under full load. Board B is radiation-hardened but has no flight heritage. Board C passes every column — the only one that does.
The grid earns its place twice over. First, it draws the search boundary without argument: three of the five boards are outside the feasible region and can be set aside, shrinking the choice to two. Second, it exposes a trap — the team had been treating "flight heritage" as a hard requirement, but the matrix makes visible that it eliminates their most capable board while the actual mission risk is low; written as a column and inspected, "heritage" turns out to be an inherited assumption, not a real constraint. Reclassifying it reopens Board B. The matrix did not choose the computer; it showed exactly which walls of the room were real.
How it works¶
- List candidates down one axis. Options, configurations, or candidate paths — whatever the units of the decision are.
- List constraints across the other. Separate genuinely hard limits from soft limits, and label each column as which it is; a matrix that blurs the two is worse than none.
- Score each cell. Pass, fail, or conditional (with the condition noted). Conditional cells are where hidden dependencies live.
- Read the columns for eliminators. A column of mostly-fails is a binding constraint; if it also kills your best options, it is the first candidate for "is this really hard, or an assumption we inherited?"
- Read the rows for survivors. Rows that pass every column define the feasible region; everything else is marked out of bounds.
Tuning parameters¶
- Hard vs. soft partition — how strictly you sort constraints into "must" and "prefer." A strict partition gives a crisp feasible region but can wrongly exclude; a loose one keeps options alive but muddies the boundary.
- Cell resolution — binary pass/fail is fast and legible; graded or conditional cells capture nuance but slow the read and invite false precision.
- Constraint completeness — how many constraints you admit as columns. More columns catch more infeasibility but risk over-constraining a space into emptiness.
- Assumption-flagging — whether each column is tagged with its source/evidence. Tagging surfaces the assumption-masquerading-as-constraint trap; skipping it is faster but leaves those traps armed.
- Re-scoring cadence — a one-time screen versus a living grid re-run as constraints are challenged or relaxed.
When it helps, and when it misleads¶
Its strength is turning a fog of "we can't do that because…" into an inspectable feasibility structure, and above all in flushing out assumptions mistaken for constraints — the column that, once written down and sourced, dissolves and reopens the space. This is the direct antidote to the archetype's premature pruning failure, where a favored answer survives only because the walls that would have challenged it were never drawn.
Its own failure mode is the opposite over-reach: a matrix implies that feasibility is the whole problem, so a team can screen a space down to two "allowed" options and forget that neither actually reaches the goal — feasibility is necessary, not sufficient. A related misuse is treating a soft preference as a hard column to manufacture a clean elimination.[n1] The guarding discipline is to keep the hard/soft partition explicit and sourced, and to remember the matrix answers which options are allowed, never which is best or how to get there.
How it implements the components¶
constraint_set— the mechanism's spine: it captures the hard and soft constraints as columns and, by forcing each to be written and sourced, separates real limits from inherited assumptions.search_boundary— the set of rows that pass every column is the in-scope feasible region; failing rows are marked out of bounds.dead_end_and_trap_marker— infeasible cells flag combinations that lead nowhere, and a binding column that kills the best options flags an assumption-trap worth challenging.
It does not model how moves chain into paths (state_transition_map) — that navigable structure is the State / Action Map's — nor does it name which target you are steering toward (goal_state), which the Strategic Option Map supplies.
Related¶
- Instantiates: Problem Space Mapping — makes the feasibility structure of the space explicit and inspectable.
- Consumes: Option Map — supplies the catalogue of candidate options the matrix screens against constraints.
- Sibling mechanisms: State / Action Map · Design Space Map · Search Space Diagram · Diagnostic Possibility Map · Strategic Option Map · Option Map · Unknowns and Assumptions Register
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Cross-references candidate options against every constraint in one grid, so the feasible region — and which combinations are simply ruled out — becomes visible at a glance, making its operative form a computation, comparison, model, or analytic representation used to infer, estimate, or choose.
Independent corroboration: The frozen evidence defines Constraint Matrix as 'Cross-references candidate options against every constraint in one grid, so the feasible region — and which combinations are simply ruled out — becomes visible at a glance', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Decision analysis and operations research cohered option-by-constraint matrices that expose the feasible region before ranking alternatives.
Related originating lineages:
- Engineering & Design — Requirements engineering uses compliance matrices to trace which candidate designs satisfy each hard requirement.
Review resolution: Operations-research feasibility matrices provide the primary method, with requirements compliance matrices as a genuine engineering lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The grid form echoes Fritz Zwicky's morphological analysis (the "morphological box"), which crosses parameters against their possible values to expose the space of feasible combinations. The technique's own caution is that a poorly chosen or over-strict set of constraints can black out cells that are actually workable — which is why sourcing each column matters. ↩