---
slug: constraint-type-identification
type: pattern
summary: "Name a constraint's type before acting on it, because whether it is physical, policy, paradigm, or market determines which intervention applies."
created: 2026-05-21
updated: 2026-06-02
related:
  constraint:
    relation: specializes
    note: "Constraint Type Identification refines the bare term *constraint* into the operational categories that determine which exploit, subordinate, and elevate moves apply."
  five-focusing-steps:
    relation: part-of
    note: "Constraint Type Identification is the discipline applied at Step 1 of the Five Focusing Steps; without naming the type, Steps 2 and 4 cannot be chosen."
  policy-constraint:
    relation: specializes
    note: "Policy is one of the four types the identification produces, and the type most commonly missed once visible physical bottlenecks have been improved."
  subordination:
    relation: enables
    note: "Subordination's mechanism depends on the constraint type identified: a rope schedule for a physical constraint, an aligned rule for a policy constraint, an aligned belief for a paradigm constraint, a sales-side discipline for a market constraint."
  exploitation-without-elevation:
    relation: complements
    note: "Exploitation is type-specific: the exploit move for a physical resource is operational, the exploit move for a policy is to write a different rule, the exploit move for a paradigm is to run the Thinking Processes, the exploit move for a market is a Mafia Offer."
  breaking-wrong-constraint:
    relation: prevented-by
    note: "Breaking the Wrong Constraint is the failure mode of skipping or rushing type identification; the pattern is the explicit defense."
  current-reality-tree:
    relation: enables
    note: "Once the constraint is identified as a policy or paradigm, the Current Reality Tree becomes the tool that traces from the visible undesirable effects back to the binding rule or belief."
  evaporating-cloud:
    relation: enables
    note: "Once a policy or paradigm constraint has been traced, the Evaporating Cloud is the tool for resolving the underlying conflict that keeps the rule or belief in place."
  decisive-competitive-edge:
    relation: enables
    note: "Once the constraint is identified as the market, the Decisive Competitive Edge is the move that exploits it."
  cost-world-thinking:
    relation: detects
    note: "Cost-world thinking is itself usually a paradigm constraint; once the type is named, the corrective is the Thinking Processes, not another efficiency project."
  buffer-management:
    relation: detects
    note: "Buffer Management's red-event traces are the most reliable signal that the physical constraint has moved, prompting a re-run of identification."
---

# Constraint Type Identification

[Common Trunk (Foundations)](learning-tracks.md#common-trunk): [prev: Process of Ongoing Improvement (POOGI)](poogi.md) -> Constraint Type Identification -> [next: Subordination](subordination.md)

> **Pattern:** A named solution to a recurring problem.

*Before exploiting or elevating a constraint, name its type — physical, policy, paradigm, or market — because the type determines which intervention applies.*

The most expensive wrong turn in TOC implementation is buying capacity when the binding constraint is a rule someone could change at no cost. The second-most expensive is running the Thinking Processes against a physical bottleneck. The third is staffing through breaks at the constraint resource when the system is market-constrained and the extra hours produce inventory the market will not buy. All three repeat the same diagnostic error: skipping the question of *what kind of constraint this is* and defaulting to the intervention the practitioner already knows how to run.

## Context

Step 1 of the [Five Focusing Steps](five-focusing-steps.md) instructs the practitioner to identify the system's constraint. The instruction is necessary but underspecified: identifying that "the assessment step is the constraint" or that "demand is the constraint" does not yet say which TOC toolkit should be brought to bear. A physical resource takes operational moves; a written rule takes a different rule; a shared belief takes the Thinking Processes; a market takes a sales-side offer. The category dictates the toolkit.

This distinction travels across every TOC application. The production chapters of the *TOC Handbook* assume the practitioner is working a physical constraint; the strategy chapters assume the constraint has shifted to the market; the Thinking Processes chapters assume a policy or paradigm constraint has been traced. The chapter-by-chapter partition hides what the type identification step makes explicit: each toolkit is the intervention for one kind of constraint, and applying the wrong toolkit does not move system throughput.

The field's vocabulary on this point is contested, and the contest is worth naming. The *TOCICO Dictionary* (Sullivan, Reid, and Cartier 2012) takes the position that "policy constraint," "measures constraint," "management constraint," and "material constraint" are common *misnomers*: bad policies and bad measures *hinder* exploitation of the real physical or market constraint rather than being constraints themselves. Goldratt's later writings, Dettmer's 1997 treatment, and much practitioner literature treat policy and paradigm constraints as canonical types alongside physical and market. This book follows the four-type canon because it carries operational consequences the Dictionary's narrower stance does not. The intervention for "a rule preventing exploitation" is a different rule, regardless of whether the field calls the rule itself the constraint or the obstacle to exploiting one. The Dictionary's stance is named for traceability; the operational distinction is what the intervention decision depends on.

## Problem

Without a named type, Step 1 of the Five Focusing Steps produces a result that under-specifies the next step. "The assessment step is the bottleneck" can describe a physical constraint: the room has only so many bays, or the clinician has only so many hours. It can describe a policy constraint: the standing rule says no patient may be discharged from assessment without a senior sign-off, and the senior becomes the bottleneck the rule creates. It can describe a paradigm constraint: the unwritten belief is that assessment protects the rest of the system from upstream errors, and that protective belief drives the queue length. It can also describe a hybrid, where the policy and paradigm reinforce the physical capacity into a binding limit. Each diagnosis points at a different intervention; conflating them at Step 1 commits the practitioner to whichever intervention seems most obvious. That is usually the physical one, because physical capacity is the most visible part of the system.

The visibility asymmetry is the structural reason type identification gets skipped. Physical constraints leave material traces: pile-ups, queue lengths, missed deadlines that correlate with one resource. Policy constraints leave records (the rule is written down somewhere) but the records are typically held by a different function from the one suffering the symptom. Paradigm constraints leave only patterns of decision-making that look like common sense to the people inside the system. Market constraints leave a single trace, finished-goods inventory that the system is not shipping, and the trace is usually read as a sales-side problem rather than a system constraint.

## Forces

- **Capital is available; rule-changing authority is not.** It is often easier for an operations team to authorize a capacity-expansion project than to authorize a change to a measurement rule, even when the rule change costs nothing and the capacity costs millions. The asymmetry pulls the diagnosis toward the type whose intervention sits inside the operations team's authority.
- **Tool familiarity locks the diagnosis.** A practitioner trained in DBR sees physical constraints; a practitioner trained in the Thinking Processes sees paradigm constraints; a practitioner who arrived through *The Phoenix Project* sees policy constraints in queue-and-handoff terms. Each is sometimes right, but the diagnostic frame each carries shapes what they will look for first.
- **Type ambiguity is the steady state, not the exception.** Pure-type constraints are rare. Most real binding constraints are a physical resource whose exploitation is also impeded by one or two policies and one or two paradigms; the question is which layer presently binds the most. Identification has to produce an ordering, not a single answer.
- **The cost-world measurement system disguises the type.** Cost accounting allocates overhead to products and resources, which makes every non-constraint look more expensive than it is and every constraint look like a candidate for outsourcing. The measurements pull the diagnosis toward "the constraint is the high-cost resource," which is rarely the actual binding limit and is sometimes a non-constraint the cost-world frame has made the team want to eliminate.
- **The constraint moves under intervention.** A physical constraint that is exploited and elevated stops binding; the next binding element is often a different type. Identification is not a one-time act; it has to be re-run whenever the system has moved through the Five Focusing Steps' loop.

## Solution

Run identification as a three-question test before deciding which exploit and elevate moves to authorize. The test produces a type and a defensible diagnosis that the practitioner can present to a sponsor under cross-examination.

**Question 1 — Where does inventory accumulate, and where is capacity rarely idle?** This is the physical-constraint test. Walk the operation and look for the pile-up: material, work-in-process, queued patients, queued tickets, or queued projects accumulating immediately upstream of one resource and thinning out downstream. Walk the system again and look for the resource that is rarely idle even briefly while other resources have visible slack. If both signals point at the same resource, the candidate diagnosis is a physical constraint. Confirm with the buffer-penetration trace: in a system running Drum-Buffer-Rope or its simplified variant, the [Constraint Buffer's](constraint-buffer.md) red events should originate from a consistent set of upstream resources serving one downstream point. If the inventory signal is missing, or the busy-resource signal points somewhere else, the constraint is probably not only physical.

**Question 2 — Is the physical resource's capacity sufficient when the rule, measurement, or sequence is changed?** This is the policy-constraint test. If a written rule, a measurement, a procedure, or an incentive structure prevents the physical resource from running at the rate it could deliver, the binding limit is the rule, not the resource. Examples include quality inspection placed downstream of the constraint, batch sizes calculated by economic order quantity rather than by constraint protection, commission structures rewarding revenue without regard to throughput per constraint-unit, and approval workflows that delay constraint-exploiting work. The Goldratt-era worked example is *The Goal's* heat-treat furnace: the physical capacity was sufficient, but the rule placing quality inspection after the furnace meant the furnace's hours were sometimes spent on material that would later be rejected. The corrective was a rule change (move inspection upstream), not a capacity expansion.

**Question 3 — Is the rule itself held in place by a belief the organization treats as common sense?** This is the paradigm-constraint test. Policies are typically the operational expression of beliefs the organization no longer notices it holds. In cost-world organizations, the belief is often that every resource should run at full capacity. In plan-driven organizations, the belief is often that variability is a defect to be eliminated rather than a fact to be absorbed. In safety-critical organizations, the belief is often that the assessment step protects the rest of the system from upstream variability. Each belief sustains the policy that produces the binding constraint. If the policy change in Question 2 is refused or reverses itself within months, the binding limit is the paradigm under the policy, not the policy itself.

If the physical signals from Question 1 are absent and the system has visible excess capacity throughout, the constraint has shifted to the market: demand is the binding limit, and exploitation moves to the sales side. The pattern is to identify the type at the front of the cycle and then re-identify at the end, because the move through Steps 2 through 4 usually shifts the binding limit somewhere else.

The central instruction is to defer the intervention choice until the type is named. The Five Focusing Steps' loop is not "identify the bottleneck, then improve it"; it is "identify the constraint *and its type*, then use the toolkit that matches the type." A team that has skipped the typing step cannot defend its capacity-expansion proposal under TOC discipline. The proposal might still be right, but the diagnosis that authorized it is missing the diagnostic step.

## How It Plays Out

In the canonical UniCo case from *The Goal*, identification names the NCX-10 and the heat-treat furnace as physical constraints, but the operational improvements come from two type-specific moves rather than one type-blind one. For the NCX-10, the exploitation move is physical and operational: staff through breaks, sequence the queue, pull inspection upstream, reduce setup time. For the heat-treat furnace, the binding limit turns out to be the inspection policy placed downstream of the furnace, and the exploitation move is to rewrite that rule. The same identification cycle produces two interventions, one of each type, because the practitioner did not stop at "physical bottleneck."

In the First Solar case Barnard and Immelman document (Cox and Schleier 2010, Ch. 16), the implementation team identified throughput as the system's measurement frame and held it against cost-world recommendations from the CFO as they arose. The chapter records the CFO proposing a new set of accounting rules that the CEO refused on the explicit ground that the rules would introduce a policy constraint affecting the throughput of the organization. The refusal is type identification operating in reverse: the team has named, in advance, what *would* be a policy constraint and how it would form, and uses that naming to refuse the rule before it binds.

In healthcare implementations the Handbook documents (Wright on large-scale healthcare in Ch. 32; the Oxfordshire Radcliffe Hospital A&E case cross-cited in the TOC healthcare literature), the binding limit at the assessment step in the A&E pathway is repeatedly found to be a hybrid: a physical clinician-capacity component, a policy component (the standing rule that no patient may be discharged from assessment without senior sign-off), and a paradigm component (the unwritten belief that assessment protects the rest of the hospital from upstream errors). The four-hour target was met in roughly two months, with no added staff, because the implementation worked on all three layers: exploiting the physical capacity through scheduling, changing the policy on who could sign off discharge, and naming the paradigm explicitly so the policy change would not reverse itself. A type-blind diagnosis would have stopped at "add clinicians."

## Consequences

Naming the type produces three operational consequences worth declaring.

The first is that capital is held back until the type permits it. Step 4 (elevate) authorizes new capacity only after Steps 2 and 3 are complete, and the type-specific exploitation move at Step 2 is what determines whether new capacity is even the right kind of intervention. A policy constraint that is fully exploited (the rule has been changed) requires no capital at Step 4; the resource that was constrained by the old rule is now constrained by something else, and the next identification cycle is what names what. A paradigm constraint resolved through the Thinking Processes likewise requires no capital. Capital flows where the type dictates, not where the original symptom appeared.

The second consequence is that the Thinking Processes have a defined entry point. The [Current Reality Tree](current-reality-tree.md), the [Evaporating Cloud](evaporating-cloud.md), and the rest of the TP family are designed for policy and paradigm constraints; they are not general logic exercises and they are not substitutes for DBR. The type identification step is what selects them. A system whose constraint is type-identified as physical does not need a CRT; a system whose constraint is type-identified as paradigm cannot be moved without one.

The third consequence is that the diagnosis is defensible across the cost-world boundary. A CFO who reads cost-world reports will not be persuaded by "the constraint is here, we have to elevate it" without the typing logic underneath. With the typing logic in place (physical resource X is the binding limit, the exploit moves at X are A, B, and C, the policy rules that prevent A, B, and C are documented and changeable, the rule changes are estimated at zero capital, the residual constraint after the rule changes is still X but at a higher rate), the proposal can be defended on its own terms even to a reader who does not share the throughput-world paradigm.

The pattern has two costs worth naming. The first is time at Step 1: typing the constraint takes longer than naming a bottleneck and moving on, and operations teams under quarterly pressure resist the delay. The second is that the typing produces uncomfortable diagnoses. When the binding constraint turns out to be a paradigm the organization holds dear, the implementation has to work on the paradigm before the throughput will move; the cases the *TOC Handbook* documents as durable are the ones where the team accepted that and worked the unfamiliar territory, and the cases the literature documents as failed are the ones where the team typed the constraint as paradigm and then went back to physical-resource interventions because those were the ones they knew how to run.

## Sources

- Goldratt and Cox, [*The Goal*](https://openlibrary.org/works/OL2463051W) (1984; revised 1986, 1992) — the originating treatment. The NCX-10 (physical constraint, exploited by operational moves) and the heat-treat furnace (physical capacity bound by a downstream inspection policy, exploited by rewriting the inspection rule) are the canonical worked examples of two different constraint types yielding two different exploitation moves inside the same plant.
- Goldratt, [*What Is This Thing Called Theory of Constraints and How Should It Be Implemented?*](https://openlibrary.org/works/OL4186015W) (1990) — formalizes the Five Focusing Steps and gives the operational specification of Step 1 that this entry refines.
- Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 1 (Goldratt, "Introduction to TOC — My Perspective"), Ch. 16 (Barnard and Immelman, "Continuous Improvement and Auditing the Process"), and Ch. 23 (Mabin and Davies, "The TOC Thinking Processes: Their Nature and Use") — the contemporary canonical treatments. The Barnard and Immelman chapter documents the First Solar case in which the CEO refuses a CFO accounting-rule change on the explicit ground that the rule would introduce a policy constraint. The Mabin and Davies chapter pairs the CRT with policy constraints and the EC with policy-or-paradigm conflicts, placing the Thinking Processes toolkit as the intervention for the non-physical types.
- Dettmer, [*Goldratt's Theory of Constraints*](https://openlibrary.org/works/OL1827619W) (1997) — extended treatment with explicit handling of policy and paradigm constraints alongside physical and market. The chapters on the Thinking Processes are organized around the proposition that non-physical constraints require the TP toolkit, which is the operational rationale for the four-type framing.
- Mabin and Balderstone, [*The World of the Theory of Constraints*](https://openlibrary.org/works/OL13537037W) (2000) — meta-review of more than 80 documented implementations across production, projects, supply chain, and services; the cases that worked on the type-correct intervention versus the cases that defaulted to physical-resource moves are the empirical basis for the claim that type identification carries operational weight.
- Cox, *TOCICO Dictionary* (2nd ed., 2012), entries "constraint," "policy constraint," "market constraint," "material constraint," "management constraint," "measures constraint," "cost-world paradigm," "throughput-world paradigm" — the certification-grade definitions this entry cross-checks against. The Dictionary takes the position that "policy," "measures," "management," and "material" are misnomers because the named items hinder exploitation of the real constraint rather than being constraints in themselves. This book follows the four-type canon for the operational reasons named above; the Dictionary's stance is cited here so certification-track readers can locate the field's actual disagreement. The Dictionary is distributed through TOCICO membership rather than the trade book channel and does not carry an Open Library record.

---

- [Next: Subordination](subordination.md)
- [Previous: Process of Ongoing Improvement (POOGI)](poogi.md)