deciqAI Theory of Constraints
Overview
Theory of Constraints (TOC) — Eliyahu Goldratt, 1984: throughput of any multi-step system is determined by its single bottleneck. Improving any other step produces no system-level gain. The Five Focusing Steps (Identify → Exploit → Subordinate → Elevate → Repeat) are the operational discipline.
Composes with pareto-principle (TOC = Pareto applied to throughput), feedback-loops, first-principles, and mvp (MVP design = TOC applied to validated learning).
When to Use
- System is producing less than desired throughput; "everyone is working hard" but results don't match effort
- Management improvement initiative or capacity investment is being planned
- Backlog or inventory accumulates at a specific step; local improvements don't translate system-wide
- Someone says "bottleneck," "throughput," "Goldratt," or "Theory of Constraints"
- Analyzing an AI capex / chip-supply-chain question — where the real limit is (e.g. GPU design vs. advanced packaging, HBM, or grid power), whether the "AI bubble" reflects a design race or a hidden physical bottleneck
Not when: single-step system; purely demand-side constraint; problem is strategic/psychological, not operational.
Coaching Novices (Adaptive Front Door)
- Engine mode: user has a concrete throughput problem → run The Process directly.
- Coach mode: user is unfamiliar → guide step by step.
In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.
- One-line: throughput is set by the slowest step — find it, fix it, ignore the rest until a new bottleneck emerges.
- Check fit: single-step system or demand-side constraint → TOC doesn't apply.
- Elicit their real case: what's the system? desired throughput? where does work-in-process pile up?
[WAIT — do not advance until user responds]
- Run The Process one step at a time: constraint? exploiting it? subordinating everything else? elevate?
[WAIT — do not advance until user responds]
- Close by naming the constraint, action plan, and re-identification schedule.
[WAIT — do not advance until user responds]
The Process
Step 1 — Identify: map all steps with capacity; find where WIP accumulates — that's the constraint. Step 2 — Exploit: max output from the constraint with no new investment (eliminate idle time, defects, distractions at that step). Step 3 — Subordinate: pace all other steps to the constraint's rate. Upstream: don't over-produce. Downstream: don't block. Retire local efficiency metrics that incentivize over-production. Step 4 — Elevate: if still binding after Steps 2-3, add capacity at the constraint (equipment, people, redesign). Highest ROI investment in the system. Step 5 — Repeat: bottleneck has moved. Return to Step 1.
Output: TOC Analysis
# TOC Analysis: <system>
## System map — steps, capacity per step, actual throughput, where WIP accumulates
## Constraint — bottleneck step + evidence (WIP buildup, idle downstream, output rate match)
## Exploit — changes to maximize current constraint output (no new investment)
## Subordinate — upstream rate limits, downstream coordination, metric changes, buffer plan
## Elevate — capacity investment at constraint, cost/benefit
## Re-identification — what to monitor, likely next constraint, re-apply schedule
→ Method in Action: Goldratt's The Goal (1984) and TOC's Lineage · Critical Chain Project Management (1997) → 2026 lens: The AI buildout's true constraint — packaging & power, not GPU design (2024–2026)
Pack: TOC by Domain
| Domain | Typical constraint | Common error | TOC fix |
|---|---|---|---|
| Manufacturing | Specific machine/workstation | Optimizing all stations | Subordinate rest to bottleneck |
| Software dev | Code review, QA, or deploy | Push devs to write faster | Limit WIP to constraint's rate |
| Sales funnel | Specific conversion step | Add more top-of-funnel leads | Fix conversion at the bottleneck |
| Hospital ops | OR scheduling or discharge | Add beds | Find true bottleneck (often discharge) |
| Project mgmt | Critical task or shared resource | Per-task safety padding | Critical chain; project-level buffer |
Applying It Well
- Identify the constraint with evidence, not intuition.
- Exploit and subordinate before elevating — most constraints yield without capital.
- Retire local efficiency metrics at non-constraints; they systematically mislead.
- Re-run Five Focusing Steps after every improvement — the constraint will move.
→ Primary sources: references/sources.md
Common Rationalizations
[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.
| Fake move | Reality |
|---|---|
| [D] "We need to fix all the problems" | Fix the constraint only. Non-constraint improvements produce no system gain. |
| [D] "Everyone needs to work hard" | Max output at non-constraints creates inventory, not throughput. |
| [D] "100% utilization everywhere" | Mathematically false with variability. Non-constraints need slack. |
| [D] "Local efficiency = global efficiency" | False in any multi-step system. |
| [D] "We don't have a constraint" | Finite throughput = constraint exists. Find it. |
| [D] "More technology will solve it" | Only if it addresses the constraint. |
| → Add [O] entries here after each real use — paste the actual failure pattern | What went wrong and why |
Red Flags
- Diagnosis for throughput shortfall is "everyone needs to work harder"
- Capacity investment spread across multiple steps without constraint identification
- Inventory visibly accumulates in front of one step; no one flags it
- Local productivity metrics tracked without aggregation to system throughput
- Previous TOC gains have decayed (new constraint unmanaged)
Verification
- System map drawn with capacity at each step
- Constraint identified with evidence (not intuition)
- Five Focusing Steps applied in order (exploit before elevate)
- Non-constraint metrics that contradict system throughput retired
- Next constraint identified after improvement; re-application scheduled
Part of deciqAI Knowledge Skills — 237 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/s/theory-of-constraints · Built by deciqAI · github.com/deciqAI · Contributions welcome.
Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/theory-of-constraints.json