---
name: Constraint Mapping
status: draft
territory: decision-making-under-uncertainty
msi_territory: decisions-under-uncertainty
sources:
  - title: "Goldratt, Eliyahu M. & Cox, Jeff (1984), The Goal: A Process of Ongoing Improvement, North River Press"
    url: https://openlibrary.org/works/OL2463051W
  - title: Dantzig, George B. (1963), Linear Programming and Extensions, Princeton University Press
    url: https://openlibrary.org/works/OL3299025W
---

# Constraint Mapping

## Why it matters

When a choice is hard, the instinct is to start weighing the options — list the pros, list the cons, score them, pick a winner. But a great many decisions feel hard for a different reason: the options on the table are not actually the options that are available. Some are ruled out by a hard wall you have not named — the budget, the deadline, the law, the laws of physics — and some apparent freedoms are not free at all. Constraint mapping is the move you make *before* you weigh anything: map what actually bounds the choice. What is fixed and cannot move, what is merely preferred, and where the real room to maneuver is. Done honestly, it usually shrinks the decision dramatically — or shows that the whole thing turns on one wall everyone was arguing around.

For example: a team is choosing a database for a new product and the debate runs for weeks across five candidates, each with passionate advocates. Map the constraints first and three of the five evaporate in an afternoon — two cannot meet a hard data-residency requirement the legal team had already stated, and one cannot be staffed because nobody on the team knows it and hiring is frozen for the year. What looked like a five-way judgment call was a two-way one, and the two survivors differed on a single axis. The weeks of comparison were spent inside a decision space four-fifths of which was never actually open.

- **What it reveals.** The true shape of the decision space — which options are genuinely available once the hard walls are drawn, which "constraints" are only preferences in disguise, and where the actual degrees of freedom lie.
- **How it changes the read.** You stop asking *"which option is best?"* and start asking *"what is even on the table, and what single thing is doing the most to bound this choice?"*
- **When to foreground it.** A choice that feels overwhelming or contested where the options are concrete but the limits are fuzzy — many alternatives, real tradeoffs, no probability arithmetic at the center — and you suspect the field is smaller (or larger) than the argument assumes.
- **What you'd miss without it.** That the decision may already be nearly made by a wall nobody stated, that options under heated debate may be infeasible, and that one binding limit may dominate while everything else is slack you are free to ignore.
- **Where it misleads.** Treat a soft preference as a hard wall and you amputate good options for no reason; treat a hard wall as negotiable and you map a feasible region that does not exist. The whole method lives or dies on getting that one distinction right.

## Realtime examples

See real, dated analyses where this mode mapped the constraints around a choice in the news → **[Constraint Mapping on Main Street Independent](https://mainstreetindependent.com/analyses/technique/decisions-under-uncertainty/constraint-mapping)**

## How to invoke it in Ora

You have several concrete options and a decision that feels harder than it should — real tradeoffs, but no genuine probability arithmetic at the center. You want the terrain laid out side by side rather than the choice made for you.

Name the options and the dimensions that matter, and ask:

> "Compare alternatives for [decision] — [option A], [option B], [option C]. Map the tradeoffs across [cost], [the second axis], and [the third]."

The phrases *compare alternatives*, *map the tradeoffs*, and *what are the pros and cons of each option* are what route you here. Bring the options concretely and bring the dimensions you care about — "compare our cloud strategies" works, but "compare AWS-only, multi-cloud, and hybrid across cost, lock-in, and team skill" gives the map its axes — and state any hard limits you already know, because a stated wall is what lets the mapping rule options in or out honestly.

One boundary worth knowing. This mode maps the terrain; it does not pick the winner. If genuine probabilities and the value of waiting for more information are the heart of the choice, that is a heavier decision mode; if you want the options *scored* against weighted criteria, or the whole decision *structured* across stakeholders and risk, those are different modes too. Constraint mapping gives you the field the choice is played on — and, by default, leaves the choosing to you.

## How it works

Start with a picture from operations research, because that is where the intuition was made precise. Imagine you run a small workshop that makes two products, and you are deciding how many of each to build this week. You could draw the plan as a point on a graph — chairs along one axis, tables along the other. Now draw in the limits. You have only so many labor-hours, so points above a certain line are impossible. Only so much lumber, another line. A standing contract to deliver at least a dozen chairs, a third line. Each limit is a wall, and what they fence off together is a shape — the set of every plan you could actually carry out. Mathematicians call that shape the *feasible region*, and the whole apparatus of linear programming, formalized by George Dantzig in the 1940s, is built on one observation about it: the best plan is never in the middle of the shape. It is always at a *corner*, where walls meet. The decision is governed by its boundaries, not its interior.

That is the first move of constraint mapping, stripped of the math: before you compare options, draw the walls and see what region is left. And the moment you do, a distinction appears that is the heart of the whole method — the difference between a wall you are pressed against and a wall you are nowhere near. In the workshop, suppose at the best plan you have lumber to spare but not a single labor-hour left. Then labor is *binding* — it is actively holding you back, and any extra hour of it would let you make more. Lumber is *non-binding*, or slack — you could lose some and it would not change your plan at all. This is the single most useful thing the method surfaces: usually one constraint is doing almost all the work of limiting you, and the rest are slack you can stop worrying about.

Eliyahu Goldratt built an entire management philosophy on exactly that asymmetry. In his 1984 business novel *The Goal*, a plant manager saves a failing factory by realizing that its output is set by one machine — the slowest step, the *bottleneck* — and that improving anything else is wasted motion. An hour saved at the bottleneck is an hour of extra output for the whole plant; an hour saved anywhere else just builds inventory in front of the bottleneck. Goldratt's name for this, the Theory of Constraints, is the same insight as Dantzig's binding constraint wearing work clothes: find the wall that is actually holding you back, because it, and almost nothing else, determines what is possible. Pour your attention there.

So the method has a shape. First, list everything that bounds the choice and sort it honestly. *Hard* constraints are walls that cannot move within the decision — the regulation, the cash on hand, the ship date, the physics. *Soft* constraints are preferences flying false colors — "we'd rather not," "it would be nicer if" — and the discipline is to demote them, because every one you mistake for hard erases options you could have had. Then there are the *fixed points*, things simply given and not up for debate, and against them the *degrees of freedom* — the dimensions where you genuinely get to choose. Second, draw the feasible region those hard walls leave and throw out the options that fall outside it, however much anyone likes them. Third, find which surviving constraint is binding — the bottleneck — because that is where the decision actually turns and where any effort to relax a limit pays off.

The payoff is almost always a decision that has changed shape. Sometimes the feasible region is far smaller than the debate assumed and the choice nearly makes itself — only two options were ever real, and they differ on one axis. Sometimes it is *larger*: a wall everyone treated as fixed turns out to be a soft preference, and a whole quadrant of options reopens. And very often the real finding is not which option to pick at all, but *which constraint to attack* — that if you could move the one binding wall, the entire choice would dissolve. That is why the move comes first. Weigh options inside a space you have not mapped and you may be optimizing carefully within a region that does not exist, while the one wall that governs everything sits unexamined off to the side.

## Framework & implementation

*This section uses Ora's own terms for the parts of an analysis, so that if you open the actual mode file they line up. Each is glossed in plain language on first use.*

### Pipeline execution

Constraint Mapping is an **atomic mode** in the **decision-making-under-uncertainty** territory — a single mapping pass, not a composite of sub-analyses — and it is the lightest-depth member of that family, the one for choices that have real tradeoffs but no probability arithmetic at their center. It runs at **Gear 4**, Ora's most thorough setting: a **Depth analyst** and a **Breadth analyst** work the choice in parallel and then critique each other (**cross-adversarial evaluation**) before a consolidator integrates the result — depth pressing each option's tradeoffs to testable thresholds, breadth widening the option set so the map is not just the options the user walked in with.

The pass does a few things in order. It **names the decision** and lists its constraints, tagging each **hard** (a wall that must be satisfied) or **soft** (a preference) — the load-bearing sort, since a mis-tagged constraint distorts the entire feasible region. It **assembles the alternatives**, requiring at least three viable options where three exist (a two-option map when a third is real is the named **false-dichotomy** failure) and requiring at least one **analyst-generated** alternative the user did not name — the breadth marker that the option space was widened. It then runs the **symmetric per-alternative analysis**: every option gets the same four slots at the same depth, because one option examined more deeply than the others is **advocacy-asymmetry**, the analyst tilting the map toward a favorite without saying so. Finally it surfaces the **no-lose elements** — actions worth taking under *every* option, things you can do before you decide — and renders the **cross-alternative comparison** in whichever of three forms fits the case, with the format choice stated and justified rather than defaulted.

The mode carries **no required lens**. Optional reasoning layers ride in its **`ANALYTICAL PERSPECTIVES`** block — the lenses it can load as it works — drawn from the strategy tradition when the options are strategic (Richard Rumelt's strategy-kernel framing) and the strategic **2×2 matrix** tradition when the options plot cleanly on two orthogonal axes. A foundational layer (the Knightian distinction between measurable risk and true uncertainty) is used mainly to *confirm the routing* — to check that the choice really is a deterministic tradeoff that belongs here, rather than a probabilistic one that belongs in the heavier decision mode.

### Output contract

The deliverable is a fixed set of sections, so the map is auditable rather than a narrative: **Decision** (the choice, named in one paragraph), **Constraints** (each tagged hard or soft — the feasible region's walls), **Alternatives at a Glance** (the option set, with analyst-generated options marked), **Per-Alternative Analysis** (each option's four parallel slots — **Success conditions** and **Failure conditions** stated as testable propositions with thresholds, **Uniquely gained**, and **Forfeited**), a **Cross-Alternative Comparison** in one named form (a strategic 2×2, a four-quadrant per-alternative table, or a pro/con tree), an **Analytical-Depth-Symmetry note** (the explicit check that no option was mapped more deeply than the rest), **No-Lose Elements** (actions valuable under every option, or an explicit statement that none exist), **Cross-Alternative Differentiating Factors** (where the options diverge most sharply), and a **Recommendation** slot that reads *empty* by default — populated only if the user explicitly asked for a final choice. The empty recommendation is the contract's signature: mapping the terrain is the job; choosing is not, unless asked.

### Origin and evidence

The intuition has two roots that turn out to be the same insight. The mathematical one is **linear programming**: George Dantzig's *Linear Programming and Extensions* (1963) is the canonical account of the method he developed in the 1940s, in which a decision bounded by linear constraints carves out a *feasible region* and the optimum always sits at one of its corners — the formal statement that a choice is governed by its boundaries, and that some boundaries (the binding ones) matter while others (the slack ones) do not. The managerial one is Eliyahu Goldratt's **Theory of Constraints**, dramatized in the business novel *The Goal* (1984, with Jeff Cox), whose central lesson — a system's output is set by its single bottleneck, so that is the only place improvement pays — is the same binding-constraint asymmetry rendered as practical advice. Constraint mapping inherits from both: from Dantzig the picture of hard walls fencing a feasible region, from Goldratt the discipline of finding the one wall that actually governs. The broader decision-theoretic frame — separating measurable risk from true uncertainty, and demoting biases that masquerade as constraints — sits underneath as the surrounding tradition.

### Applications and common uses

- **Technology and platform selection.** Vendors, cloud strategies, frameworks, or stacks where hard requirements (compliance, budget, in-house skill) quietly rule out half the field before any scoring begins.
- **Capital and infrastructure choices.** Build-versus-refurbish, plant siting, or equipment decisions where physical, regulatory, and budget walls define a feasible region and one binding limit usually dominates.
- **Household and personal decisions.** Major purchases, home-energy upgrades, schooling or gap-year options — choices with several real alternatives and concrete limits but no need for probability math.
- **Operations and throughput.** Finding the bottleneck in a process — the Goldratt use directly — so improvement effort lands where it actually raises output rather than building slack elsewhere.
- **Strategy framing.** Laying out a small set of strategic options against the constraints that bind them, to see which are genuinely open and where the option space could be widened.

### Failure modes and when not to use it

- **Hard/soft mis-tagging.** The whole method rests on the hard-versus-soft sort. Promote a preference to a wall and you delete viable options; demote a real wall and you map an impossible region. The mode states the tag for every constraint so the sort is visible and challengeable.
- **The false dichotomy.** Reducing a real multi-option choice to two impoverishes the map. The mode requires at least three viable options where three exist, and at least one the analyst generated, precisely to resist the two-camp framing the debate often arrives in.
- **Advocacy by asymmetry.** A map can be tilted without a single false statement, just by examining a favored option more thoroughly than the rest. The symmetric four-slot template and the explicit depth-symmetry check are the guard against a thumb on the scale.
- **Mapping that quietly becomes deciding.** A constraint map that ends in a confident single recommendation the user never asked for has slipped from mapping into choosing. The empty-by-default recommendation slot keeps the mode honest about which job it is doing.

**When not to reach for it.** When the options are clear and the real task is to **score them against weighted criteria**, that is multi-criteria-decision analysis, not constraint mapping. When the job is to **structure the whole decision** — orchestrating stakeholders, sequencing, risk, and the future together — route to a decision-architecture mode. And when the heart of the choice is **probability-weighted outcomes** and the value of waiting for more information, that is a decision-under-uncertainty mode; constraint mapping deliberately leaves the probability arithmetic out, and forcing it in is using the wrong tool.

## Related

- **Decision Architecture** — the molecular sibling for when the choice is not just a set of options to map but a whole decision to structure across stakeholders, sequencing, risk, and the future.
- **Multi-Criteria Decision Analysis** — the sibling for when the options are already clear and the task is to score them against several weighted criteria rather than draw the walls around them.
- **Decision Under Uncertainty** — the depth-thorough sibling for when probabilities, expected value, and the worth of waiting for more information are the center of the choice — the boundary this mode hands off across.
- **2×2 Matrix** — the lens this mode reaches for when the options plot cleanly on two orthogonal axes and the comparison wants a quadrant grid rather than a table.

## Sources

- [Goldratt, Eliyahu M. & Cox, Jeff (1984), The Goal: A Process of Ongoing Improvement, North River Press](https://openlibrary.org/works/OL2463051W)
- [Dantzig, George B. (1963), Linear Programming and Extensions, Princeton University Press](https://openlibrary.org/works/OL3299025W)