Theory of Constraints

Quick facts

Mechanism: Produces a constraint-intervention plan that names the single binding constraint capping a system’s throughput and attaches its exploit, subordinate, and elevate decisions, after testing capacity versus demand at each step to confirm that step is genuinely the rate-limiter rather than the loudest one.

Produces: constraint-intervention-plan

Evidence: P · Domain: Systems and Consequences

Use when a system has a clear flow (a pipeline, a funnel, a queue, an approval chain, a production line) whose output is capped by one step and improvement effort is being spread evenly across all steps instead of aimed at the bottleneck. Not for coverage questions (route to think-issue-tree), recurring deep-cause questions (route to think-iceberg-model), or accumulation-trajectory questions (route to think-stocks-and-flows-reasoning).

The throughput of a whole system is governed by one binding constraint - its rate-limiting step - so improving anything other than that constraint does almost nothing for the system as a whole. The default improvement instinct is the opposite: make every part faster, cheaper, more utilized. This skill refuses that reflex. It treats local efficiency at a non-constraint as waste, because a non-bottleneck working harder just piles inventory in front of the bottleneck, and it concentrates effort on the one step that caps the flow while subordinating (not optimizing) everything else. The single question it forces is whether one step limits the throughput of the whole, and whether effort is aimed there or scattered. The output is a constraint-intervention plan - the named binding step plus its exploit, subordinate, and elevate decisions - not a discussion. This is the Five Focusing Steps reduced to its working core; it is deliberately scoped to the bare bottleneck move, not the full Goldratt operational systems (Drum-Buffer-Rope, Critical Chain, Throughput Accounting).

When to Use

• A system has a clear flow - a pipeline, a funnel, a queue, an approval chain, a production line - that work items pass through, and its output is capped by one step.
• Improvement effort is being spread evenly across all steps, or aimed at the loudest, most-complained-about step, instead of at the step that actually caps throughput.
• Adding resources is not lifting output (“we keep adding salespeople but revenue is flat”), which suggests the constraint is elsewhere.
• There is appetite to wring more from the limiting step before spending to add capacity.

When NOT to Use

• No single binding constraint, or an unstable or non-flow problem. This method assumes one dominant, reasonably stable bottleneck governs the system. With several co-equal limiters, a constraint that shifts faster than you can act on it, or no flow at all (a one-off decision, a design question, a values trade-off), forcing a single-constraint frame manufactures a rate-limiter that is not really binding and aims effort at the wrong place. Say so and stop.
• Coverage or “have we considered every part?” questions go to think-issue-tree. Exhaustive decomposition (every category of cause or option, nothing left out) is the inverse move; coverage is this method’s failure mode, not its goal.
• Recurring or deep-structural-cause questions go to think-iceberg-model. “Why does this keep recurring, and where structurally do we intervene?” is leverage by causal depth (event to pattern to structure to mental model), which a bottleneck analysis does not provide.
• Accumulation-trajectory (“is the stock rising or falling?”) questions go to think-stocks-and-flows-reasoning. Whether a quantity is accumulating up or down is a net-flow reading, a different error from locating a rate-limiter.
• Treat the identified constraint as a hypothesis to test, never as found. A wrongly named bottleneck - the loudest step rather than the binding one - sends the whole exploit / subordinate / elevate sequence at the wrong target. The method does not itself prove which step is binding; the capacity-versus-demand test does.
• Do not subordinate healthy parts to a step that was never the true limiter. “Subordinate everything to the constraint” is correct only when one constraint really governs. Applied where it does not, it starves working parts of the system to feed a step that was never the rate-limiter.

Instructions

When asked where to unblock throughput in a system with a flow, follow these steps:

1. Confirm there is a flow with a plausible single rate-limiter. State the system as a sequence of steps that something passes through (work items, candidates, tickets, units). If there is no flow, or several co-equal limiters, or an unstable, shifting constraint, stop and route out (see “When NOT to Use”); do not manufacture a bottleneck.
2. Identify the candidate binding constraint as a hypothesis. Name the one step that appears to cap downstream output. Resist naming the loudest, most-complained-about, or most-visible step by reflex.
3. Test it with capacity versus demand, per step. For each step, state its capacity (how much it can process per unit time) against the demand placed on it. The binding constraint is the step where demand meets or exceeds capacity and the steps after it sit starved or idle. If the data does not single out one step, say the constraint is unproven and stop short of the exploit sequence.
4. Exploit the constraint. List how to get maximum useful throughput from that step with resources already on hand, before any spend (remove idle time, stop it doing work that is not throughput, feed it only good inputs, offload non-essential tasks).
5. Subordinate everything else. State how each non-constraint should run at the pace the constraint can absorb, not at its own local maximum. Name the local-efficiency habits that must be deliberately given up (a non-bottleneck running flat-out just builds queue in front of the constraint).
6. Elevate the constraint, only if still binding after exploit. State what added capacity would raise the constraint (hire, buy, parallelize, redesign the step), explicitly gated behind exploitation being exhausted.
7. Re-check. Note that elevating or exploiting can move the constraint to a new step; record the trigger to return to step 2, and the warning not to keep optimizing the old bottleneck out of inertia.
8. Emit the constraint-intervention plan per references/TEMPLATE.md. The deliverable is the plan, not prose.

Output Format

Use the template in references/TEMPLATE.md. The deliverable is the constraint-intervention plan - the named binding constraint, the capacity-versus-demand test, and the exploit / subordinate / elevate decisions with a re-check trigger - not a prose essay.

Quality Checklist

Before finalizing, verify:

• The system is stated as a flow (a sequence of steps work passes through), and if there is no flow or no single binding constraint, the skill said so and stopped.
• The binding constraint is named as a hypothesis, not asserted as found, and is not just the loudest or most-visible step.
• Capacity versus demand was tested per step, and the named constraint is the step where demand meets or exceeds capacity while downstream starves.
• Exploit (wring throughput with current resources) precedes elevate (add capacity); elevate is gated behind exploitation being exhausted.
• Non-constraints are subordinated to the constraint’s pace, not optimized to their own local maximum, and the local-efficiency habits to give up are named.
• The re-check trigger is recorded (what would move the constraint, and the warning not to keep optimizing the old one).
• No overclaiming: the bottleneck principle is operationally backed but has no controlled trial of this move and is transferred from human practice (see evidence/dossier.md).
• The output is the constraint-intervention plan artifact, not prose.

Evidence

Tier P (governing; honest floor and ceiling). The bottleneck principle is durable, broadly taught, and endorsed even by its critics (Mukherjee and Chatterjee, 2007, separate criticism of Goldratt’s rigour from criticism of the bottleneck approach), with a large, consistently positive operational record (Mabin and Balderstone’s review of 80-plus reported applications; Bacelar-Silva, Cox and Rodrigues, 2020, a systematic review of 42 healthcare implementations). But none of it is controlled comparative evidence for the cognitive move, and two cautions cap the grade: selection bias (Mabin and Balderstone report finding no documented failures - a literature of self-reported winners), and the move under test is not the move shipped (most evidence measures the full apparatus of Drum-Buffer-Rope, Critical Chain, and Throughput Accounting, not the bare identify-and-exploit step; the part closest to a standalone thinking method, the Thinking Processes, has the weakest evidence). Evidence is transferred from human teams in manufacturing, projects, and healthcare, not AI-validated. The impression that “the method always works” is an artifact of the no-failures-reported literature and is excluded from any claim. Full grading, sources, and caveats: evidence/dossier.md.

Examples

See references/EXAMPLE.md for a completed constraint-intervention plan on a real decision.

Deep dive: worked example

A full worked run (the shared Northwind scenario)

Constraint-Intervention Plan - Worked Example

A completed run of the theory-of-constraints skill on a real, consequential decision. This is the quality bar a generated plan should meet.

Uses the shared recurring scenario (Northwind, a B2B SaaS weighing a self-serve free-tier launch) so examples across skills read as one coherent product. Where iceberg-model would descend a recurring problem to its structural causes and stocks-and-flows-reasoning would read whether an accumulation is rising or falling, this skill takes the new-account activation pipeline that the free-tier launch is about to flood and finds the single step that caps how many accounts reach first value. See docs/internal/AUTHORING.md.

---

Problem under analysis

• Problem as given: “Activation is our bottleneck. New accounts take about six weeks to reach first value, and the free-tier launch is about to multiply signups. We are talking about hiring across onboarding, buying a better onboarding tool, and rewriting the docs. Where do we actually unblock throughput?”
• The user’s actual goal: Get many more new accounts to first value per week, fast enough that the free-tier launch grows activated users rather than a backlog.

Summary (top of the artifact)

Northwind’s activation pipeline is a clear flow, and the team is about to spread effort across every step at once. The capacity-versus-demand table singles out one binding constraint: the mandatory solutions-engineer (SE) provisioning review that every new account must pass, which clears about 20 accounts per week against roughly 50 arriving - while the steps after it (training, go-live) sit starved. The plan is to exploit that review before spending (stop routing self-serve free-tier accounts through it at all, batch the reviews, and feed the SE only complete intake) and only elevate (hire a second SE) if it still binds afterward. Hiring across onboarding or buying a tool would have poured money into non-constraints and changed nothing. The plan also flags that exploiting this step will likely move the constraint downstream to training.

System / flow

A new account passes through, in order:

1. Signup and intake - account created, intake form submitted.
2. Solutions-engineer provisioning review - an SE reviews each account’s setup, data model, and security questionnaire and approves it for configuration. Mandatory, every account.
3. Configuration - the account is configured against the approved plan.
4. Training and onboarding session - the customer is walked through their workspace.
5. Go-live / first value - the customer runs their first real workflow.

Capacity vs demand per step

Step	Capacity (per unit time)	Demand placed on it	Starved or saturated?
Signup and intake	~200 accounts/week (self-serve, automated)	~50 accounts/week now; far more after free-tier launch	Matched (under-loaded)
SE provisioning review	~20 accounts/week (2 SEs, manual, 4 hrs each)	~50 accounts/week	Saturated - queue building
Configuration	~60 accounts/week	~20/week (only what the SE releases)	Starved (idle, waiting on review)
Training session	~40 sessions/week	~20/week (only what clears review)	Starved (idle)
Go-live / first value	~as fast as accounts arrive configured	~20/week	Starved

Demand meets or exceeds capacity only at the SE provisioning review (50 arriving, 20 cleared). Every step downstream sits starved, idle while the queue in front of the SE grows - the signature of the binding constraint. Intake, the loudest source of complaints (“the form is clunky”), is not the constraint at all; it is under-loaded.

Binding constraint (hypothesis)

• The constraint: the mandatory solutions-engineer provisioning review (step 2).
• Evidence it binds: it is the one step where demand (~50/week) exceeds capacity (~20/week); the configuration, training, and go-live steps after it are starved and idle, waiting on releases; the queue and the six-week lead time are almost entirely time spent waiting for this review. The free-tier launch raises demand on this step most of all.
• If unproven: here the table singles out one step cleanly, so the analysis proceeds. (Had two steps both been saturated with the rest starved between them, the plan would have declared the constraint unproven and stopped before exploit.)

Exploit (before any spend)

Get maximum throughput from the existing two SEs before hiring or buying anything:

• Stop routing self-serve free-tier accounts through the SE review at all. Free-tier accounts are low-risk, single-user, on standard configuration - gate them with an automated checklist and reserve the human review for paid and enterprise accounts. This removes the bulk of the demand the launch would add.
• Batch the reviews. Group similar account types so the SE is not context-switching account by account; review standard setups in a single block.
• Feed the SE only complete, validated intake. Reject incomplete intake forms upstream automatically so no SE time is spent chasing missing data (today a large share of each review is back-and-forth on missing fields).
• Offload the security-questionnaire portion to a pre-filled standard response for low-risk tiers, so the SE reviews only genuine exceptions.

Subordinate (everything else)

• Run intake, configuration, training, and go-live at the pace the SE review can absorb, not flat-out. There is no value in the intake team driving signups through faster, or the configuration team clearing its queue to zero - that only piles more inventory in front of the SE.
• Local-efficiency habits to give up: stop measuring the intake and configuration teams on their own throughput or utilization (a busy non-constraint is not progress); stop the “rewrite the docs” and “buy a faster onboarding tool” initiatives aimed at non-constraint steps - they cannot lift system throughput while the SE review caps it.

Elevate (only if still binding after exploit)

Only if the SE review is still the binding constraint after the exploit moves above:

• Hire a second-tier SE (or train an existing configuration specialist to clear standard reviews), raising review capacity.
• Build tooling that automates the standard-configuration review entirely, leaving humans only the genuine exceptions.

Do not start here. If exploiting cuts paid-account review demand to within the existing two SEs’ capacity, no hire is needed and the spend is avoided.

Re-check trigger

Once the SE review is exploited (and free-tier accounts are routed around it), the constraint will very likely move downstream to training (capacity ~40 sessions/week), which becomes the new rate-limiter as far more accounts clear provisioning. Trigger: when the SE review queue stops growing and a queue starts building in front of training, return to step 2 and re-identify. Do not keep optimizing the SE review out of inertia once it is no longer the binding step.

---

Note how the value is in refusing to spread effort evenly and refusing to chase the loudest step: the problem arrived as “hire across onboarding and buy a tool,” and the loudest complaint was about the intake form. An unaided pass would have improved several steps at once. The capacity-versus-demand test singled out the one step that actually caps throughput, exploit-before-elevate avoided an unnecessary hire, the subordinate decision stopped wasted effort on non-constraints, and the re-check trigger flags that the win will move the constraint downstream rather than ending the problem.

Grounding: the full evidence dossier

What the research does and does not show, with graded sources

Evidence Dossier: Theory of Constraints

Single source of truth for the theory-of-constraints skill. The SKILL.md, sidecar, and evals derive from this. If a claim is not here, it does not belong in the skill.

Skill	thinking-framework-skills.theory-of-constraints (installable name think-theory-of-constraints)
Family	systems-and-consequences
Evidence tier	P governing (honest floor and ceiling - see “What the evidence shows”)
Confidence	High that the bottleneck principle is real and operationally useful; low that any controlled effect size for the bare cognitive move transfers to agents
Status	draft (admitted from the v0.5.0 catalog-expansion shortlist)

---

1. The mechanism (what actually does the work)

The Theory of Constraints starts from one claim: the throughput of a whole system is governed by a single binding constraint - its bottleneck - and so improving anything other than that constraint does almost nothing for the system as a whole. The durable cognitive move is the Five Focusing Steps: (1) identify the system’s one binding constraint, the step whose limited capacity caps the output of everything downstream; (2) exploit it, wringing maximum useful throughput out of that step with the resources already on hand before spending a cent; (3) subordinate every other step to that decision, so non-constraints run at the pace the constraint can absorb rather than at their own local maximum; (4) elevate the constraint, adding capacity to it only once exploitation is exhausted; and (5) repeat - when the constraint moves, return to step one and do not let inertia keep you optimizing yesterday’s bottleneck.

The move that does the work is the inversion of ordinary improvement instinct. The default is to make every part faster, cheaper, or more utilized; this method says that local efficiency at a non-constraint is waste, because a non-bottleneck working harder just builds inventory in front of the bottleneck. The single question it forces is whether one step limits the throughput of the whole, and whether effort is aimed there or scattered. The deliverable is the named binding constraint plus the exploit / subordinate / elevate decisions attached to it - a single-point intervention plan, not a coverage map.

Scope (load-bearing for the grade below). The method is broader than this core in practice. Goldratt built operational toolkits on top of it - Drum-Buffer-Rope for production scheduling, Critical Chain Project Management for projects, and Throughput Accounting for the money view - plus a separate logic-diagram toolkit, the Thinking Processes (Current Reality Tree, Evaporating Cloud / conflict resolution diagram, Future Reality Tree, Prerequisite and Transition Trees), for diagnosing what to change, what to change to, and how to cause the change. This skill is scoped to the bottleneck move itself - find and exploit the system bottleneck - not to those full operational systems, and that scoping is load-bearing for the evidence grade in section 3.

2. Lineage

• The Theory of Constraints is Eliyahu M. Goldratt’s (1947-2011), an Israeli physicist turned management thinker. He introduced it in 1984 through the business novel The Goal (with Jeff Cox), which dramatizes the Five Focusing Steps on a struggling factory and has sold millions of copies as standard operations-management reading.
• Goldratt extended the core into Critical Chain project management (Critical Chain, 1997) and codified the logic-diagram Thinking Processes in What Is This Thing Called Theory of Constraints and How Should It Be Implemented? (1990).
• Naming and attribution. “Theory of Constraints” and “bottleneck analysis” are used generically across the academic and practitioner literature with attribution to Goldratt; the term is not handled here as a trademark. This entry is documented descriptively with attribution to Goldratt rather than flagged as branded; attribution is required, trademark string is none.

3. What the evidence shows, and what it does NOT show

The honest governing grade is P (practitioner), and the split underneath it is the whole point of this entry. P is both the floor and the ceiling.

What the record supports. The bottleneck principle is durable, broadly taught, and - unusually for a practitioner method - endorsed even by its critics. Mukherjee and Chatterjee (2007) note that the criticism of Goldratt’s work targets his lack of academic rigour and presentation, but not the bottleneck approach, treating the two as separate questions. On the operational side there is a large descriptive literature: Mabin and Balderstone’s review of the international literature (the 2000 book and the 2003 IJOPM paper, “The performance of the theory of constraints methodology”) aggregated on the order of 80-plus reported applications and found consistent, often large improvements in lead time, inventory, due-date performance, and financial results. Domain reviews echo the pattern: Bacelar-Silva, Cox and Rodrigues (2020), a systematic review of 42 implementations in healthcare, reports positive results across the board - improvements in productivity and timeliness in the large majority of studies - and concludes the evidence supports the method as a promising solution. So the supported claim is real and worth stating plainly: in flow-heavy operational settings, focusing improvement on the binding constraint is a sound, repeatedly-reported way to lift system throughput.

What the record does NOT support. None of this is controlled, comparative effectiveness evidence for the cognitive move. Two cautions are decisive.

1. Selection bias. Mabin and Balderstone explicitly report finding no documented failures in the literature - an outcome that, in a body of self-reported success stories and consulting case studies, signals a literature of winners rather than an unbiased effect estimate. It is not evidence of a method that never fails.
2. The move under test is not the move shipped. Almost all of the operational evidence measures the full apparatus - Drum-Buffer-Rope scheduling, Critical Chain, Throughput Accounting - implemented as a management system, not the bare identify-and-exploit reasoning step. The part of the method closest to a standalone thinking method, the Thinking Processes / Evaporating Cloud, has the weakest evidence: Kim, Mabin and Davies (2008), reviewing the peer-reviewed Thinking-Processes literature from 1994 to 2006, document how thin the empirical base is, and the broader literature notes there is little to no controlled empirical validation of the Evaporating Cloud’s effectiveness in decision-making.

So the evidence is genuinely split - operational use is P with selection-bias caveats; the thinking tools are closer to anecdotal and largely unvalidated - and the conservative governing grade is the lower-supported reading of the actual move, which is P. Grading it above P would borrow the operational system’s case-review record for a reasoning step those studies did not isolate; grading it below P would understate that the bottleneck principle has real, repeated operational backing and near-universal endorsement.

4. Transferred-evidence flag

True. Every result above is from human teams in manufacturing, projects, and healthcare. None studies a constraint analysis produced by or with an AI agent. The evidence is transferred from human operational practice and is not validated for AI-augmented use; that transfer is a second, independent reason the governing grade is capped at P.

Why the AI value still holds: a model reaching for “make every step faster” or fixing the loudest-complained-about step is exactly the failure this move counters. Forcing the explicit capacity-versus-demand test that singles out one binding step, gating elevate behind exploit, and emitting an inspectable plan is a direct counter to naming the loudest step instead of the binding one. Those benefits do not depend on any unproven outcome claim.

5. When it works / when it fails (drives the eval negative cases and “When NOT to Use”)

Works best when: a system has a clear flow and a plausible single rate-limiter - a delivery pipeline, a manufacturing line, a hiring funnel, a support queue, a CI pipeline, a multi-stage approval. When throughput is capped by one step and teams are spreading improvement effort evenly across all steps, the discipline - find the binding step, squeeze it before buying capacity, and stop optimizing the steps that are not the constraint - is a sharp, useful correction. Its anti-coverage stance is exactly the value: it tells you what to ignore.

Fails or misleads when (poor-fit / anti-patterns):

• There is no single binding constraint, or the constraint is not stable. The method assumes one dominant bottleneck governs the system. With several co-equal limiters, a shifting constraint, or no flow at all (a one-off decision, a design question, a values trade-off), forcing a single-constraint frame manufactures a bottleneck that is not really binding and points effort at the wrong place.
• The problem is about coverage or root cause, not flow. Exhaustive decomposition of every category of cause or option is think-issue-tree; recurring-and-structural-cause questions are think-iceberg-model; this method answers neither - it answers where the rate-limiting step is.
• The constraint is treated as found rather than tested. “Identify the constraint” is a hypothesis. A wrongly named bottleneck - the loudest step rather than the binding one - sends the whole exploit / subordinate / elevate sequence at the wrong target. The method does not itself prove which step is binding; that requires data on each step’s capacity versus demand.
• Local optimization is genuinely the right call. “Subordinate everything to the constraint” is correct only when one constraint really governs. Applied where it does not, it can justify starving healthy parts of a system to feed a step that was never the true limiter.

6. Output artifact

The skill must emit a constraint-intervention plan, not prose. It carries:

• the named binding constraint (one step), stated as a hypothesis;
• the capacity-versus-demand test per step that this step is genuinely the rate-limiter, not the loudest step (each step’s capacity against the demand placed on it; the constraint is where demand meets or exceeds capacity and downstream starves);
• the exploit decision (wring maximum throughput from that step with resources already on hand, before spending);
• the subordinate decision (run every non-constraint at the pace the constraint can absorb, not at its own local maximum);
• the elevate decision (add capacity to the constraint only once exploitation is exhausted);
• the re-check trigger (when the constraint moves, the plan is stale - return to identify; do not let inertia keep optimizing yesterday’s bottleneck).

A short summary sits above the plan.

7. Sources

1. Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement (North River Press, 1984). The founding text; introduces the Five Focusing Steps and the bottleneck principle in narrative form. Foundational / practitioner.
2. Eliyahu M. Goldratt, What Is This Thing Called Theory of Constraints and How Should It Be Implemented? (North River Press, 1990). Codifies the Thinking Processes logic tools. Primary source.
3. Victoria J. Mabin and Steven J. Balderstone, “The performance of the theory of constraints methodology: analysis and discussion of successful TOC applications,” International Journal of Operations and Production Management 23(6) (2003), 568-595; and The World of the Theory of Constraints: A Review of the International Literature (St. Lucie Press, 2000). The most comprehensive review of reported applications; documents large operational and financial improvements and, notably, no reported failures (a selection-bias signal). (P, review of success cases.)
4. Gabriel M. Bacelar-Silva, James F. Cox III, and Pedro P. Rodrigues, “Outcomes of managing healthcare services using the Theory of Constraints: a systematic review,” Health Systems 11(1) (2020), 1-16. Systematic review of 42 healthcare implementations; positive outcomes (productivity, timeliness) but a heterogeneous evidence base including non-peer-reviewed sources, no controlled-trial or bias assessment. (P, domain systematic review.)
5. Sangwon Kim, Victoria J. Mabin, and John Davies, “The theory of constraints thinking processes: retrospect and prospect,” International Journal of Operations and Production Management 28(2) (2008), 155-184. Reviews the peer-reviewed Thinking-Processes literature (1994-2006) and documents the empirical and publication gaps in the logic tools. (Critical / review literature; bounds the thinking-tools evidence.)
6. Ashok Mukherjee and A. K. Chatterjee, “Theory of constraints: is it a theory and a good one?” (2007). Separates criticism of Goldratt’s academic rigour from the validity of the bottleneck approach itself; useful for not conflating the two. (Critical literature.)

Excluded on the evidence rule: the general impression that “the method always works,” and any implied success rate read off the no-failures-reported literature, trace to a self-selected body of success cases with no controlled comparison; they are not counted toward the grade.

Verification status: The bottleneck principle and the no-failures-reported caveat are well-attested and mutually consistent. Confirm the Mabin and Balderstone (count of applications) and Bacelar-Silva, Cox and Rodrigues (42 implementations) citation specifics before any public quantified claim. The honest scope - a durable, operationally-backed principle whose specific cognitive step has no controlled comparative trial, transferred from human practice - is the core caveat.