--- slug: constraint type: concept summary: "The single element whose limit caps what the whole system can achieve, distinct from a bottleneck and the term every TOC tool is calibrated against." created: 2026-05-21 updated: 2026-06-02 related: throughput: relation: complements note: "The constraint sets the system's throughput, and throughput is how the constraint is measured at the system level." goal: relation: depends-on note: "A constraint is only definable relative to the goal the system is trying to achieve." five-focusing-steps: relation: enables note: "The Five Focusing Steps are the operational discipline applied once a constraint has been identified." constraint-type-identification: relation: refined-by note: "Constraint Type Identification refines the bare term into physical, policy, paradigm, and market categories that dictate the intervention." policy-constraint: relation: specializes note: "A policy constraint is the constraint type most commonly missed once physical capacity has been improved." ccr: relation: contrasts-with note: "A capacity-constrained resource is close to becoming a constraint without being one, and the distinction prevents misdiagnosis." local-optimization: relation: violated-by note: "Local Optimization is what happens when improvement effort is directed anywhere other than the constraint." breaking-wrong-constraint: relation: prevented-by note: "Naming the constraint precisely prevents the antipattern of elevating a resource that only appeared to be one." --- # Constraint [Common Trunk (Foundations)](learning-tracks.md#common-trunk): [prev: System](system.md) -> Constraint -> [next: Inherent Simplicity](inherent-simplicity.md) > **Concept:** Vocabulary that names a phenomenon. *The single element that limits what the whole system can achieve.* A *constraint* is not a synonym for *bottleneck*. The conflation is so common in operations vocabulary that the distinction can sound pedantic, but the cost is visible in misdirected improvement projects: a team spends months relieving what it called the bottleneck, and the system's output does not move. The Theory of Constraints gives practitioners a precise enough vocabulary to refuse that effort before it is spent. ## Context The concept anchors the foundations of TOC. Before throughput, inventory, and operating expense can be defined as system measures, and before the Five Focusing Steps can prescribe action, the practitioner needs a term for the element that determines what the whole system can deliver. Goldratt named that element the constraint. Every later TOC tool (Drum-Buffer-Rope, Critical Chain, Throughput Accounting, the Evaporating Cloud) assumes the practitioner can point at the system's constraint and say which one it is. The concept is system-relative. The constraint of a job shop differs from the constraint of a hospital emergency department, and both differ from the constraint of a sales organization whose product is ready but the market is not buying. The vocabulary doesn't change; the referent does. ## What It Is The *TOCICO Dictionary* defines a constraint as "the factor that ultimately limits the performance of a system or organization. The factor that, if the organization were able to increase it, more fully exploit it, or more effectively subordinate to it, would result in achieving more of the goal." Two clauses carry the weight: *ultimately limits* and *relative to the goal*. *Ultimately limits* picks out one element from the many that influence performance. A factory has thousands of resources, dozens of policies, and a market full of customers. Most affect output to some degree. The constraint is the one presently binding the system: the element whose extra hour of capacity, exploitation, or attention would convert directly into more of the goal. Everything else has slack relative to the constraint, even when it looks busy. *Relative to the goal* is what makes the concept usable across domains. For a for-profit firm, Goldratt fixed the goal as making money now and in the future, and the constraint is whatever limits that. For a hospital, a non-profit, or a government function, the goal must be named before constraints can be identified at all. A hospital that has not decided whether its goal is patient throughput, clinical quality, financial sustainability, or some weighted combination cannot answer "what's the constraint?" — the question is malformed until the goal is. Constraints come in four types: physical (a machine, a person, a piece of equipment, a unit of space), policy (a rule, procedure, measurement, or incentive that prevents a physical resource from being exploited), paradigm (a shared belief that makes the policy seem natural), and market (demand insufficient to challenge internal capacity). The type determines the intervention. A physical constraint takes operational changes: exploitation, subordination, eventual elevation. A policy constraint takes a decision-making move and no capital. A paradigm constraint takes the Thinking Processes. A market constraint shifts the system to outward-facing work: selling, repositioning, and building offers the market can't refuse. Treating a policy constraint as physical, and buying capacity when the binding limit is a rule someone wrote, is the expensive wrong turn [Constraint Type Identification](constraint-type-identification.md) is designed to prevent. ## How It Is Measured or Recognized The constraint is the resource, rule, paradigm, or market position whose extra hour of capacity, full exploitation, or released cycle would increase system throughput. Operationally, that is the test. If a practitioner cannot identify any internal place where an additional hour would produce more throughput, the constraint has moved to the market. Several practical signals point at a physical constraint: - **Inventory accumulates immediately upstream.** Material, work-in-process, or pending requests pile up in front of the constraint resource and thin out downstream of it. The pile-up is the system's own diagnostic. - **The resource is rarely idle, even briefly.** Other resources have visible slack across a shift; the constraint does not. - **Due-date misses correlate with disturbances at one specific resource.** When that resource is delayed, the system is late; when other resources are delayed, the system absorbs the variation. - **Buffer penetration concentrates at one feeding chain.** In a system running Drum-Buffer-Rope or its simplified variant, red events trace back to a consistent set of upstream resources serving one downstream point. A capacity-constrained resource (CCR) shows several of these symptoms without being the system constraint; the distinction is real and not academic. See [Capacity-Constrained Resource](ccr.md). For policy and paradigm constraints, the recognition signal is different: physical capacity is sufficient, but a written rule or shared assumption prevents the system from using it. A common case is a quality inspection step placed downstream of the constraint, which means the constraint sometimes works on material the inspection later rejects. The constraint's output is degraded by a policy decision about where inspection sits. Another case is a sales commission structure that rewards revenue without regard to throughput margin: salespeople bring in orders that consume constraint time disproportionately to the throughput they generate. For market constraints, the recognition signal is the simplest of all: the system's internal capacity exceeds the orders the market is placing. ## Why It Matters Without a precise word for the constraint, operations vocabulary collapses two distinct ideas: *bottleneck* (any resource with insufficient capacity for the demand placed on it) and *the constraint* (the bottleneck currently limiting system output). A system can have several bottlenecks at once. It has at most one or two binding constraints at a time, and improving anything that is not the constraint does not improve system throughput. That distinction is what allows TOC's economics to work. If improving the constraint by an hour produces an hour more of system throughput, and improving a non-constraint by an hour produces no additional throughput, then improvement effort directed at non-constraints is by definition wasted relative to the system's goal, even when the non-constraint resource ends the period more efficient than it started. The Local Optimization antipattern is the operational shape of failing to honor this distinction. The concept also gives the certification-track practitioner a defensible vocabulary for explaining why a successful efficiency project in one department did not move the company's throughput. The honest answer is that the department was not the constraint, and TOC's prediction was that an efficiency gain there would not move system performance. That defense requires *constraint* to mean something more specific than "wherever we found a problem." ## Common Misunderstanding **"The constraint is whichever resource is busiest."** It often is, but not always, and acting on that assumption without verification produces the Breaking the Wrong Constraint antipattern. A resource may be busy because of poor scheduling, unsubordinated upstream behavior, or an efficiency-trap measurement system that pushes it toward full utilization. The constraint is the resource whose extra capacity would yield more throughput, not the resource whose appearance is most stressful to walk past. **"Constraint and bottleneck are the same word."** They are not, in TOC. A bottleneck is any resource with insufficient capacity for the demand placed on it. The *constraint* is the one bottleneck whose capacity determines the system's throughput at this moment. The *TOCICO Dictionary* keeps the entries separate because the distinction changes the diagnosis. **"The constraint stays the same once we find it."** It does not. When the binding constraint is exploited, subordinated to, and eventually elevated, it stops being binding and another element becomes the constraint. Step 5 of the Five Focusing Steps exists to handle exactly that case. A TOC implementation that doesn't expect the constraint to move is one that breaks the first time it does. **"Every system has a constraint."** Every system has one — the question is whether it is internal or external. A system whose internal resources all have slack relative to demand has a market constraint, not an absence of constraint. The intervention shifts to the market; the concept still applies. **"A constraint is a problem to be eliminated."** It is not, and the assumption produces capital-spending plans that don't deliver. The constraint is the system's pacemaker: the element whose throughput rate the rest of the system is built to support. The TOC discipline is to choose where the constraint lives, often deliberately on a resource the business wants to invest in, and to manage the system around it. Elevating the constraint is step 4 of the Five Focusing Steps for a reason: it is authorized only after exploitation is complete and insufficient. ## Sources - Goldratt and Cox, [*The Goal*](https://openlibrary.org/works/OL2463051W) (1984) — the originating treatment, dramatized through Alex Rogo's plant; the NCX-10 and the heat-treat furnace are the canonical worked examples. - Goldratt, [*What Is This Thing Called Theory of Constraints and How Should It Be Implemented?*](https://openlibrary.org/works/OL4186015W) (1990) — formalizes the concept and names the Five Focusing Steps as the operational discipline applied to it. - Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 1 (Goldratt, "Introduction to TOC — My Perspective") — the contemporary authoritative treatment, with the chain metaphor restated and the constraint/bottleneck distinction made central. - Cox, *TOCICO Dictionary* (2nd ed., 2012), entry "constraint" — the certification-grade definition this entry cross-checks against. The Dictionary is distributed through TOCICO membership rather than the trade book channel and does not carry an Open Library record. - Dettmer, [*Goldratt's Theory of Constraints*](https://openlibrary.org/works/OL1827619W) (1997) — extended treatment of policy and paradigm constraints, which the Dictionary names but does not develop. --- - [Next: Throughput](throughput.md) - [Previous: System](system.md)