Theory of Constraints Foundations

11 canonical Theory of Constraints primitives for diagnosing and exploiting system constraints. Primitives are domain-agnostic: the same Five Focusing Steps that fix a production line apply to a software delivery pipeline, a product roadmap, or a consulting engagement. Each primitive solves a specific class of throughput-limiting problem.

When to Apply

Apply theory-of-constraints when:

One bottleneck demonstrably gates total system throughput (the system has a constraint, not many)
Roadmap or capacity-allocation under a hard limited resource (eng-weeks, GPU-hours, account-managers)
Funnel debug where a single step blocks downstream conversion
Policy constraint suspected (a rule, not a physical limit, is what's holding throughput)
Subordination question — "should other steps slow down to match the bottleneck?"
Post-AI adoption reassessment — when AI coding tools improve individual velocity but delivery metrics (lead time, deployment frequency, change failure rate) stay flat, re-run 5FS; the constraint has likely shifted downstream to code review, verification, or integration (DORA 2025, n≈5,000; corroborated by IT Revolution 2026 and Logilica 2025)
LLM / agent-pipeline optimization — when end-to-end latency or task throughput of a multi-step AI pipeline is not meeting targets despite adding models or workers; the constraint is usually a specific stage (LLM decode, serialized tool execution, or a guardrail/eval step), not aggregate capacity — profile per stage before scaling

Skip and use simpler alternatives when:

System has multiple roughly equal bottlenecks — TOC's "elevate one" model misfires; use queueing networks (foundations-queueing-theory)
Throughput question is really a feedback-control question (oscillation, instability) — use foundations-control-theory
The "constraint" is actually a strategic choice (we want this to be the limit) — TOC is a diagnostic, not a strategy
Bottleneck moves run-to-run (no stable system) — stabilise before applying 5 focusing steps
T/CU ratio differences are < 20% across initiatives — ranking noise dominates the signal
Pure capacity addition is cheap and uncontroversial — just add capacity; TOC analysis is overhead

Quick Reference
Primitive Index
Formal Supporting Theory
Misuse Boundaries
Anti-Patterns
Decision Checklist
Composition Recipes — Roadmap Re-Prioritization · Incident-Mode Flow Restoration · LLM / Agent-Pipeline Constraint Analysis · Policy Debugging
Workflow
ASCII Flow
Related Skills
Navigation
Fact-Checking

Quick Reference

Primitive	Core Question	Recipe Stub
Five Focusing Steps	Where should all improvement energy go?	Identify constraint → exploit → subordinate → elevate → repeat
Drum-Buffer-Rope	How do we schedule flow around the constraint?	Constraint = drum; time buffer before constraint; rope limits intake
Throughput Accounting	How do we measure with T, I, OE instead of cost?	Rank decisions by T/CU (Throughput per Constraint Unit)
Evaporating Cloud	How do we dissolve a conflict without compromise?	Map A→B→D / A→C→D′; challenge the assumption on each arrow
Current Reality Tree	What is the root cause of our undesirable effects?	List 5–10 UDEs; trace with "If…Then" to one Core Problem
Future Reality Tree	Will our injection actually fix the problem?	Map injection → effects; find Negative Branch Reservations
Prerequisite Tree	What intermediate objectives must come first?	List obstacles; derive IOs; sequence dependencies
Transition Tree	What specific actions, in what order?	For each IO: Need → Action → Effect; verify each effect is observable
Critical Chain	How do we schedule projects to prevent buffer hoarding?	Strip individual padding; add Project Buffer at end; track buffer consumption
Policy Constraints	Is the constraint a rule or metric, not capacity?	Audit rules and metrics before elevating physical capacity
Thinking Processes	Which TP tool do I need?	CRT (diagnose) → EC (resolve conflict) → FRT (design) → PRT+TT (execute)

Primitive Index

Each primitive has a full playbook (definition, when to use, inputs, outputs, failure modes, worked example, sources).

#	Primitive	Failure Mode It Addresses
1	Five Focusing Steps	Improvement energy scattered across non-constraints
2	Drum-Buffer-Rope	WIP floods system; constraint starves; local optima destroy flow
3	Throughput Accounting	Cost-accounting drives local optimization at expense of throughput
4	Evaporating Cloud	Conflict resolved by compromise; invalid assumption never surfaced
5	Current Reality Tree	Root cause misidentified; multiple symptoms treated without finding cause
6	Future Reality Tree	Solution deployed without validating it resolves root cause or checking side effects
7	Prerequisite Tree	Implementation stalls on unacknowledged obstacles
8	Transition Tree	Action plan lists steps without logic connecting them; first obstacle stops progress
9	Critical Chain	Projects chronically late despite individual tasks finishing "on time"
10	Policy Constraints	Throughput constrained by rules/metrics; physical capacity elevated without effect
11	Thinking Processes	Wrong TP tool selected; diagnosis and solution steps confused

Formal Supporting Theory

Theory Area	Use When	Applied Primitives It Grounds
Systems constraint logic	Need to identify the current throughput-limiting factor	#1, #10
Flow synchronization	Need WIP control around a constraint	#2
Throughput accounting	Need financial decisions under constrained capacity	#3
Conflict logic	Need to dissolve a policy or priority conflict	#4
Cause-effect reasoning	Need root-cause diagnosis and effect validation	#5, #6, #11
Implementation dependency logic	Need obstacle sequencing and action logic	#7, #8
Project buffer theory	Need project delivery under resource constraints	#9

Use references/formal-theory-map.md when the task needs boundaries between TOC, queueing, Lean, and general bottleneck language.

Misuse Boundaries

Misuse	Why It Is Wrong	Required Correction
Calling every problem a constraint	TOC constraint is the system throughput limiter	Identify the current limiting factor with observable flow evidence
Confusing the constraint with the bottleneck-of-the-day	Persistent queue depth nominates a candidate but does not prove throughput sensitivity	Use multiple windows to screen candidates, then vary effective capacity or policy and measure accepted end-to-end throughput at fixed quality; see `references/patterns-scenarios-traps.md#constraint-vs-bottleneck-of-the-day-expert-judgment`
Assuming exactly one constraint always exists	Matrix orgs, near-tied capacity, and unstable processes can violate the single-constraint model	Check `references/patterns-scenarios-traps.md#when-the-single-constraint-assumption-breaks` before forcing a 5FS ranking
Improving non-constraints	Local improvement does not raise system throughput	Subordinate non-constraints to the constraint
Buying capacity before exploitation	Elevation is step 4, not step 1	Exploit and subordinate first
Treating policy constraints as physical limits	Rules and metrics can cap throughput invisibly	Audit policies before capacity spend
Using critical chain as rebranded critical path	CCPM removes local padding and manages buffers	Track buffer consumption, not only task dates
Skipping logic validation	Thinking Process diagrams can encode bad assumptions	Use Categories of Legitimate Reservation-style checks

Check references/patterns-scenarios-traps.md before using TOC as an operating prescription.

Anti-Patterns

Anti-Pattern	TOC Diagnosis	Fix
Optimizing non-bottleneck steps	Violates step 3 of 5FS (subordinate); non-constraint improvements do not increase throughput	Apply 5FS first; prioritize the constraint without suspending required safety, maintenance or quality work
Treating the constraint as fixed	"We can't change that" accepted without evidence	Apply the Evaporating Cloud to surface the assumption that the constraint is immutable
Capacity vs. policy constraint confusion	Physical constraint elevated while a policy constraint caps throughput upstream	Audit rules and metrics before purchasing capacity; policy constraints are invisible but common
Throughput accounting ignored in favor of cost accounting	T/CU ranking skipped; product mix optimized on margin → wrong mix at the constraint	Define the goal, mandatory obligations, demand and shared capacities. Use T/CU ordering only for divisible independent work against one linear capacity; dependencies, deadlines, indivisibility or multiple capacities require a global feasible mix/schedule comparison
Critical chain treated as critical path	Individual task padding hoarded; Project Buffer undersized; buffer management ignored	Strip individual padding; enforce Project Buffer; track buffer consumption, not milestones
Solution deployed without FRT validation	FRT skipped; injection creates unintended side effects	Build the FRT before implementation; explicitly search for Negative Branch Reservations
UDEs patched without CRT	Symptoms recur because root cause untouched	Build a CRT from the last five recurring problems; solve the core, not the surface
Conflict resolved by compromise	Evaporating Cloud not used; invalid assumption sustains the conflict	Build the cloud; challenge every assumption on every arrow

Decision Checklist

Composition Recipes

Roadmap Re-Prioritization

Re-sequence the product backlog by throughput impact, not stakeholder volume.

Inputs: List of initiatives, each with T (revenue impact per quarter, in currency) and CU (constraint units consumed, e.g. dev-weeks); total available CU for the planning period; any known policy constraints (mandatory-item rules, release gate policies) quoted verbatim. Rules: T/CU is a screening ranking for one verified scarce resource with comparable marginal throughput, divisible work and no binding dependencies or demand caps. For indivisible initiatives, dependencies or multiple resources, formulate a constrained allocation and hand off to foundations-mathematical-optimization; ratio-greedy is not guaranteed optimal. Keep mandatory safety/compliance work as explicit feasibility constraints rather than treating it as a policy to eliminate. Outputs: Ranked schedule table (initiative, T, CU, T/CU, rank, included/excluded); total CU consumed and slack; list of any policy constraints identified and their go/no-go disposition.

Identify constraint with 5FS (#1): which resource, team, or step caps delivery?
Rank work by T/CU with Throughput Accounting (#3): which items generate the most throughput per hour of constraint time?
Audit for policy constraints (#10): is the constraint a rule (approval gate, batch-release policy) rather than capacity?
Add if conflict: use Evaporating Cloud (#4) if two valid priorities conflict in the ranking.

Worked example: Q3 roadmap, eng capacity = constraint (40 dev-weeks). Throughput = revenue impact per quarter.

Initiative	T (Δrev/qtr)	CU (dev-weeks)	T/CU	Rank
Checkout speedup	$180k	6	$30k	1
New onboarding flow	$240k	12	$20k	2
Admin redesign	$100k	10	$10k	3

Schedule by T/CU descending until CU exhausted: 6 + 12 + 10 = 28 dev-weeks → all three fit; 12 weeks slack for unknowns. Anti-pattern: ranking by raw T puts onboarding first, but it consumes 2× the constraint per dollar. Fail signal: if a policy constraint (e.g., "every quarter must include a platform item") overrides T/CU, name and challenge the policy explicitly — a policy can encode legitimate obligations; investigate its rationale and preserve required constraints.

Incident-Mode Flow Restoration

Restore throughput in a degraded or overloaded system without adding headcount.

Inputs: Candidate bottleneck steps from queue, wait-time, and utilization profiles; WIP at each step; accepted-throughput target and fixed quality definition; and capacity or policy interventions available for a replay, controlled change, or natural experiment. Rules: Queue and utilization signals screen candidates. Before choosing the drum, verify that changing a candidate's effective capacity or policy changes accepted end-to-end throughput at the target quality. Apply the five focusing steps to the verified constraint; exploit and subordinate before buying capacity. Size the buffer from observed variation and apply the rope to bound intake. Re-test throughput sensitivity after each change because the constraint can move. Outputs: Subordination plan specifying which upstream and downstream steps must change behavior to protect the drum; measurable throughput target with a named observation window (e.g., "≥ 40 tickets resolved per day over the next 5 business days"); buffer size and rope threshold with rationale; go/no-go on capacity elevation with supporting evidence.

Identify constraint with 5FS (#1): which step's marginal capacity or policy relaxation increases completed-system throughput? Use queue depth as a clue, then verify with a controlled change or natural experiment.
Apply DBR (#2): set the constraint as the drum; add a time buffer in front of it; apply the rope to freeze new intake above the buffer threshold.
Exploit before elevating: squeeze maximum output from existing constraint capacity before requesting more resources.
Add if constraint is a rule: audit for policy constraints (#10) — is intake or escalation throttled by a policy, not capacity?

LLM / Agent-Pipeline Constraint Analysis

Apply 5FS and DBR to a multi-step LLM inference or multi-agent workflow when end-to-end latency or task throughput is not meeting targets despite adding more models or workers.

Inputs: End-to-end latency profile per pipeline stage (e.g., prompt construction, prefill, decode, tool-call dispatch, guardrail/eval, output parsing); observed queue depth per stage; throughput target (tasks completed per minute or second); any rate-limit or concurrency policies on external APIs or GPU pools. Rules: Apply 5FS to the pipeline. Latency share and queue depth identify candidates, but the constraint is the stage whose added effective capacity or relaxed policy raises end-to-end throughput at the target quality. Confirm it with a controlled capacity change, shadow replay, or natural experiment; a slow stage can sit off the critical path, and a deep queue can be caused upstream. Profile your own pipeline, exploit before scaling, then set the verified constraint as the drum. Size a time buffer upstream from observed variation and apply the rope by rate-limiting intake. Audit rate limits, context caps, and serialized gates as possible policy constraints. Outputs: Candidate stages from latency/queue profiles; intervention or replay result showing end-to-end throughput sensitivity at the fixed target quality; verified constraint stage; exploitation plan; DBR configuration; and policy-constraint audit.

Identify constraint with 5FS (#1): profile the flow, form candidates from latency/queues, then verify which stage changes end-to-end throughput when its effective capacity changes.
Exploit before scaling: cache reusable context; batch parallel tool calls; right-size models at non-constraint stages to free GPU/token budget for the constraint.
Apply DBR (#2): set the constraint stage as the drum; add a task-slot buffer upstream; apply the rope (max in-flight limit) to prevent queue flooding.
Audit for policy constraints (#10): check rate-limit tiers, sequential guardrail pipelines, and context-window policies — these are the most common invisible constraints in agent systems.

Worked example: agent pipeline — search → plan → tool-dispatch → eval → summarize. Profiling shows plan-stage decode at 68% of wall-clock, so plan is a candidate. In a shadow replay at the same task mix and quality threshold, increasing plan capacity by 50% raises accepted end-to-end completions by 31%, while increasing tool-dispatch capacity by 50% changes them by 2%; plan is therefore the current constraint. Prefix caching is then tested at the same quality gate. After it raises accepted throughput, repeat the intervention because the constraint may have moved to eval. The figures are illustrative protocol outputs, not portable performance claims.

Policy Debugging

Diagnose why throughput is not improving despite available capacity.

Inputs: 5–10 Undesirable Effects (UDEs) with frequency and severity for each; candidate policy constraint quoted verbatim (the exact rule or metric suspected of capping throughput). Rules: Build a Current Reality Tree (CRT, #5) — connect ≥3 UDEs to a single root via If→Then chains, each arrow stating sufficiency (not mere correlation); a thought experiment resolving UDEs makes the policy a candidate explanation, not a confirmed cause; validate with a controlled change, replay or natural experiment at fixed quality before claiming throughput sensitivity; if two legitimate requirements sustain the policy, build an Evaporating Cloud (#4) to surface the underlying assumption; validate the proposed policy change as an injection in a Future Reality Tree (#6) before implementing. Outputs: CRT diagram with the named root cause and the candidate policy quoted verbatim; Evaporating Cloud with ≥3 assumption candidates on the arrows; go/no-go recommendation on policy change vs. capacity elevation, with the disconfirming evidence required to reverse the recommendation.

Build a CRT (#5): list the top UDEs; trace to root cause with "If…Then" logic.
Apply Evaporating Cloud (#4): if the root cause is sustained by a conflict between two requirements, build the cloud to surface and challenge the sustaining assumption.
Validate with FRT (#6): design the policy change as an injection; trace it forward to verify it resolves the UDEs without creating new ones.

Workflow

Observe the system: collect 5–10 Undesirable Effects (UDEs) — concrete, negative, observable outcomes.
Use the Decision Checklist to select the right primitive.
Open the per-primitive playbook in assets/templates/theory-of-constraints/ for the full definition, inputs, outputs, failure modes, and worked example.
For multi-question scenarios, use the Composition Recipes or the full assets/templates/theory-of-constraints/README.md to stack primitives.
For domain-specific applications (ops, product, software architecture, data engineering), load the consumer skill's references/theory-of-constraints-applied.md when available.

ASCII Flow

Throughput-limiting system problem
  -> Collect observable undesirable effects
  -> Identify current constraint
     +-- no stable constraint -> stabilize or use queueing networks
     +-- constraint found -> exploit it before adding capacity
  -> Subordinate non-constraints to the bottleneck
  -> Elevate constraint only when exploitation is exhausted
  -> Repeat and return throughput, constraint, policy changes, and next constraint

Related Skills

Consumer skills will link here when applied recipes are added.

Practical Decision Record

Use decision and validation worksheet for intake, model boundaries, uncertainty and checkable acceptance examples. Regression cases provide independent prompts and expected answers; these are fixtures, not executed agent results.

Navigation

Decision and validation worksheet: references/decision-and-validation.md
Per-primitive playbooks: assets/templates/theory-of-constraints/ (one file per primitive)
Composition guide: assets/templates/theory-of-constraints/README.md
Formal theory map: references/formal-theory-map.md
Patterns, scenarios, and traps: references/patterns-scenarios-traps.md
Domain-agnostic primitives overview: references/primitives-overview.md
Sources: data/sources.json

Fact-Checking

All primitives are sourced from primary Goldratt texts and the leading secondary references (Dettmer 2007, Cox & Spencer 1998, Schragenheim et al.).
Numeric claims (e.g., buffer sizing heuristics) are calibrated guidelines, not universal constants — validate against actual system data before applying.
TOC was developed primarily in manufacturing and distribution contexts; knowledge-work and software applications are well-established. Canonical software-lineage sources: The Phoenix Project (Kim et al. 2013), The DevOps Handbook (Kim et al. 2016), Project to Product / Flow Framework (Kersten 2018), and Flow Engineering (Pereira & Davis 2024). All available at data/sources.json.
The Five Focusing Steps, DBR, and Throughput Accounting are the most empirically validated primitives; the Thinking Processes are logic-based frameworks with strong practitioner support but limited controlled-study evidence.
CCPM evidence base: de Oliveira Martins et al. (2025), Applied Sciences 15(15):8147, DOI 10.3390/app15158147 — systematic review of 62 CCPM studies (Scopus + Web of Science, 2014–2025). The strongest available peer-reviewed evidence for this primitive, but note what it does and does not establish: most included studies are modeling and simulation rather than controlled field trials, and construction/manufacturing dominate the sample. It is evidence that CCPM is actively researched and simulated favourably, not proof of field effect sizes in knowledge work. See 09-critical-chain.md.
AI-era constraint shift (dev workflow): upgraded 2026-08-14 from practitioner report to survey evidence. DORA's 2025 State of AI-assisted Software Development (Google Cloud, n≈5,000, surveyed June–July 2025) found ~90% AI adoption and that higher AI adoption raises both delivery throughput and delivery instability, with time saved in generation reallocated to verification overhead — i.e. the constraint moves from writing code to reviewing and verifying it. Still correlational survey data, not a controlled trial. Corroborated by IT Revolution (Jan 2026) and Logilica (Dec 2025) practitioner analyses. Re-run 5FS after significant AI tool adoption.
AI-era constraint shift (runtime / agent pipelines): corrected 2026-08-14. Earlier revisions stated that Planner/Arbiter decode accounts for "~70% of total agent latency" as a general pattern. That figure came from Agent-X (arXiv:2605.10380), which measures an on-device agent on an M4 Pro; the same paper reports that server-class cloud inference is decode-dominated at >95%, so the on-device split does not generalize to cloud pipelines. Separately, tool-heavy agents are bottlenecked by the serialized LLM→tool loop, with tool execution at 36–60% of request time (arXiv:2603.18897). The load-bearing claim is the method, not any single percentage: profile per stage before scaling, and exploit (KV reuse, tool-call overlap, model right-sizing) before adding GPU capacity. Evidence grade B+: peer-reviewed-venue preprints measuring specific systems, not a general law.
2026-07-11 correction: earlier revisions of the per-primitive playbooks cited specific chapter numbers from Dettmer (2007), The Logical Thinking Process, for six primitives (5FS, Evaporating Cloud, CRT, FRT, PRT, TT). A spot-check against the publisher's table of contents confirmed the Evaporating Cloud chapter number was wrong (cited as Ch. 6; published contents place it at Ch. 5) and that the Five Focusing Steps citation to a specific Dettmer chapter was misleading (5FS originates in Goldratt's The Goal, not in Dettmer's Thinking-Processes-focused book). All chapter-specific citations across the six affected files were replaced with topic-level references and an explicit instruction to verify against the reader's own printing before citing a chapter number. Treat any chapter-level citation for this book as unverified until checked directly.
TOC and Kanban are complementary, not competing: the modern Kanban Method draws directly on TOC constraint logic (WIP limits as rope, bottleneck exploitation as 5FS). See references/formal-theory-map.md for the practical distinction and the common failure mode (running Kanban without knowing the constraint).
Critical Chain's multitasking-cost claims mix two evidence streams that should not be conflated: Goldratt's own throughput-loss percentages (practitioner illustration, not measured) and independent, peer-reviewed cognitive-psychology research on task-switching costs (Rubinstein, Meyer & Evans 2001) that corroborates the mechanism but not Goldratt's specific numbers. See 09-critical-chain.md.

Learnings Loop

When prior decisions or pitfalls are relevant, consult learnings.consolidated.md if present; use learnings.md only for needed history or as the available fallback. Otherwise skip both.

After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.

foundations-theory-of-constraints