Theory Of Constraints

Theory of Constraints

A diagnostic runbook for optimizing any process — a CI/build pipeline, a dev value stream, an Agent Skill or plugin, or a runtime code path — through Eliyahu Goldratt's Theory of Constraints (ToC).

The one idea that makes ToC powerful: every system has exactly one binding constraint at a time, and global throughput rises only when you improve that constraint. Effort spent anywhere else produces nothing — "an hour saved at a non-bottleneck is a mirage." This runbook finds the constraint with measurement, then walks the Five Focusing Steps to relieve it without creating new problems.

When to Apply

Use this skill when the user wants to optimize a process or workflow and any of these are true:

• They want to optimize but don't know where to start ("make this faster", "why is this slow", "reduce the cost of this").
• A local speedup didn't move the end-to-end result (you optimized the wrong thing).
• Work, queues, or WIP pile up at one stage while others sit idle.
• Everything looks 100% busy but little ships (high utilization, low throughput).
• They added capacity, parallelism, or resources and it didn't help.
• Fixing one bottleneck just surfaces another.
• The real limiter is a policy or rule, not a resource (a mandatory full test suite, serialized review, a "read every reference" instruction, batch-everything releases).
• They're stuck in a tradeoff that blocks the obvious fix ("faster vs safer", "smaller context vs more coverage").

Do not use this skill for:

• A specific, already-localized hotspot where the constraint is known — go straight to the fix (e.g. an O(n²) loop → complexity-optimizer).
• Pure correctness/quality review with no throughput goal — use a code-review skill.
• Micro-optimizing a stage you have not yet proven is the constraint. That is the cardinal ToC error; this skill exists to stop it.

The Process of Ongoing Improvement (POOGI)

ToC is a loop, not a one-shot. Always run it in order — exploiting before elevating is what separates ToC from "just throw resources at it."

        ┌─────────────────────────────────────────────────┐
        │                                                   │
        ▼                                                   │
1. IDENTIFY the constraint  ── the one stage that gates global throughput
        │
        ▼
2. EXPLOIT it               ── get the most from it with NO new spend
        │                       (remove waste/idle on the constraint)
        ▼
3. SUBORDINATE everything   ── pace all non-constraints to the constraint;
   else to the constraint      let them idle rather than build WIP
        │
        ▼
4. ELEVATE the constraint   ── only now add capacity / invest / parallelize
        │
        ▼
5. REPEAT                   ── the constraint has moved; go to step 1.
        │                       Do NOT let inertia (old policies) be the
        └───────────────────────new constraint.

The most common mistakes map directly to skipped steps: jumping to step 4 (elevate) before step 2 (exploit), or never reaching step 1 (optimizing whatever is most visible instead of what is binding).

Common Symptoms

Start here. Match the symptom, open its decision tree, run the quick check.

For Agent Skills / plugins specifically, the constraint is most often the always-loaded context budget (a bloated SKILL.md) or a weak description (the skill never triggers, so its throughput is zero). Run queries/skill-context-cost.sh <skill-dir>.

How to Use

1. Identify the symptom in the table above and open its tree in references/. 2. Define the goal and throughput metric first. ToC is meaningless without a global metric to improve (PRs merged/week, requests/sec, task completions per agent session, build wall-clock). The trees assume you have one — set it via config.json or ask the user. 3. Run the quick-check query the tree points to. Queries live in references/queries/; each has a header explaining parameters and how to read the output. 4. Follow the tree to a terminal action. Every path ends in a concrete ToC move (exploit / subordinate / elevate / change-the-policy / repeat). 5. Record the finding using assets/templates/report.md. Append a one-line entry to the investigation log so recurring constraints become visible over time.

Read references/symptoms.md for the full catalog with entry points and severity.

Setup

This skill uses config.json to know what "throughput" means for the system under study and how to measure each stage. On first use, if goal_metric or value_stream_stages are empty, ask the user (via AskUserQuestion) for:

• the goal metric (the global throughput to maximize), and
• the ordered stages of the workflow being optimized.

Then save them to config.json. If config cannot be filled, the skill still works — fall back to asking the user inline and measuring stages manually. Never block on missing config.

Gotchas

The classic ToC traps (measuring local efficiency, elevating before exploiting, optimizing the most-visible stage) are captured in gotchas.md. Read it before your first investigation — these errors are the whole reason ToC exists.

Related Skills

• complexity-optimizer — once ToC identifies a code stage as the constraint, use this to find and fix the algorithmic hotspot inside it.
• dx-harness — when the constraint is a developer-experience chore (slow bootstrap, manual steps), this audits and fixes the harness.
• dev-skill:evolve — when the constraint is an Agent Skill itself (bloated context, weak triggering), this improves it.

Constraint Analysis Report: {system / workflow name}

Date: {YYYY-MM-DD} Investigator: {agent/user} System under study: {CI pipeline | dev value stream | Agent Skill | runtime path} Goal metric (global throughput): {e.g. PRs merged/week, requests/sec, builds/hour, task completions/session} Severity: {P1 effort being wasted | P2 a step skipped | P3 meta-process}

Summary

{1–2 sentences: what the constraint was, which focusing step applied, and the measured effect on the goal metric.}

System map

{The ordered stages, with the constraint marked. Example:}

install → build → [TEST ← constraint] → deploy

Constraint identified

Timeline

• {HH:MM} — Goal metric defined: {metric} = {baseline value}
• {HH:MM} — Measured stages: {tool}, found {result}
• {HH:MM} — Constraint confirmed: {what} ({evidence})
• {HH:MM} — Focusing step applied: {EXPLOIT / SUBORDINATE / ELEVATE / change policy}
• {HH:MM} — Re-measured: {metric} = {new value}

Focusing step applied

{Which of the Five Focusing Steps, and exactly what was done.}

• [ ] 1. IDENTIFY — constraint confirmed with evidence (not guessed)
• [ ] 2. EXPLOIT — removed idle/waste/rework on the constraint (no new spend)
• [ ] 3. SUBORDINATE — paced non-constraints to the constraint; capped WIP
• [ ] 4. ELEVATE — added capacity (only after exploit + subordinate)
• [ ] 5. REPEAT / inertia check — removed any policy tuned to the old constraint

Throughput accounting (before / after)

Run queries/throughput-accounting.py --before T I OE --after T I OE to fill this in and get the verdict. A T-flat / OE-down result is a LOCAL OPTIMUM — do not claim success.

Necessary conditions verified (only if a policy was relaxed)

{If you shrank a test gate, removed an approval, or changed a metric: confirm the protected outcome still holds — escaped-defect rate, incident rate, output correctness. If it regressed, the policy was real, not stale; restore it.}

Next predicted constraint

{When this constraint is broken, the system limit moves. Where to next? This is POOGI step 5 — name the likely new constraint so the next investigation starts ahead.}

Action items

• [ ] {Intervention to keep / make permanent}
• [ ] {Stale policy to remove (inertia)}
• [ ] {Metric/instrumentation to add so the next constraint is measurable}
• [ ] {Append a one-line entry to the investigation log}

Gotchas

The diagnostic dead-ends and recurring errors of applying Theory of Constraints. The first five are the classic ToC traps — they are the entire reason the method exists. Append new ones (with dates) as investigations surface them.

Optimizing without a defined global metric

The most common failure: jumping to "make it faster" before naming the global throughput metric. Without one, every local speedup looks like progress and local optima get rewarded. Always pin the goal metric first (see find-the-constraint-tree.md precondition); if the user can't state one, that absence is the first thing to fix. Added: 2026-05-21

Optimizing the most-visible stage instead of the binding one

Teams optimize whatever is easiest to see or measure (compile time, a noisy log), not what is binding. An improvement to a non-constraint produces zero global gain — "an hour saved at a non-bottleneck is a mirage." Confirm the constraint with measurement (measure-stage-times.sh + measure-wip.sh) before touching anything. See local-optimum-tree.md. Added: 2026-05-21

Elevating before exploiting

Adding capacity (Step 4) before getting the most from existing capacity (Step 2) buys idle resources: OE rises, T stays flat. Always exhaust exploit + subordinate before spending. A misfired elevation is the strongest signal you skipped a step. See elevation-misfire-tree.md. Added: 2026-05-21

Mistaking high utilization for productivity

"Activating a resource is not the same as utilizing it." Driving a non-constraint to 100% only inflates WIP. A correctly-subordinated non-constraint should idle part of the time. Green dashboards everywhere with low throughput is the trap, not the goal. See utilization-trap-tree.md. Added: 2026-05-21

Leaving stale policies in place after the constraint moves (inertia)

After two or three POOGI cycles the binding constraint is usually a policy that was rational for a former constraint — a full-suite gate from when tests were fast, a buffer sized for an old bottleneck, a "read all references" instruction from when references were few. These are invisible to stage timing. Run the inertia check every cycle. See moving-constraint-tree.md and policy-constraint-tree.md. Added: 2026-05-21

Relaxing a policy without verifying its necessary condition

Policy constraints are high-leverage because changing a rule is free — but rules often protect something real (regressions, incidents, correctness). Shrinking a test gate or removing an approval can raise throughput while quietly raising escaped defects. ToC maximizes throughput subject to necessary conditions still holding. Verify the protected outcome for a few cycles before declaring success; if it regresses, the policy was real, not stale. See policy-constraint-tree.md. Added: 2026-05-21

Reacting to run-to-run noise as if the constraint moved

A constraint that "jumps around" is often measurement variance, not a moving constraint. Average over several runs (measure-stage-times.sh --runs 3+) before declaring a new constraint, especially when stage times are close together (a balanced, flow-gated system). See moving-constraint-tree.md. Added: 2026-05-21

Treating throughput accounting units inconsistently

throughput-accounting.py compares before vs after — the verdict is only meaningful if T, I, and OE use the same units in both readings (e.g. both T in PRs/week, both OE in CI-minutes/run). Mixing units (local stage time before, global metric after) produces a false verdict. Measure the same global metric on both sides. Added: 2026-05-21

Decision Tree: Conflict Resolution (the Evaporating Cloud)

Symptom: You know the constraint, but the obvious fix is blocked by a tradeoff that feels unresolvable — "we must move faster but we must stay safe", "shrink the agent's context but keep full coverage", "deploy continuously but protect stability." The team is stuck choosing between two bad options or splitting the difference.

Core principle: ToC's Evaporating Cloud (Conflict Resolution Diagram) holds that a persistent conflict is never a real tradeoff — it survives only because of a hidden, false assumption. You don't compromise the cloud; you evaporate it by breaking one assumption, producing a win-win "injection." Compromise leaves both needs partly unmet; evaporation meets both.

State the conflict as a cloud, then attack the assumptions.
│
├── Step 1 — Build the cloud (5 boxes):
│   A  (Objective)      ← the shared goal both sides actually want
│   B  (Need)           ← what side 1 must protect   → requires D
│   C  (Need)           ← what side 2 must protect   → requires D'
│   D  vs D' (Wants)    ← the two conflicting actions
│
│   Read it as logic:
│   "To achieve A we need B; to have B we want D."
│   "To achieve A we need C; to have C we want D'."
│   "But D and D' conflict."
│
├── Step 2 — Surface the assumption behind EACH arrow. Ask "why must this be
│   true?" for all five:
│     A→B : "to reach the goal we really need B because…"
│     A→C : "…we really need C because…"
│     B→D : "to get B we must do D because…"   ← most assumptions hide here
│     C→D': "to get C we must do D' because…"  ← and here
│     D↔D': "D and D' can't coexist because…"  ← and here
│
├── Step 3 — Find the WEAKEST assumption (the one that isn't actually a law of
│   nature) and break it with an INJECTION — a change that makes the assumption
│   false, so both needs are met without choosing.
│   │
│   ├── Found a breakable assumption
│   │   └── State the injection. Verify it doesn't create new negative effects
│   │       (a mini Future Reality Tree: "if we do this, then… does anything
│   │       bad follow?"). 
│   │       ├── No new negatives → adopt the injection; the conflict evaporates.
│   │       │   Return to the constraint fix you were blocked on →
│   │       │   find-the-constraint-tree.md.
│   │       └── New negative effect appears → it's a different assumption or a
│   │           real necessary condition; pick the next-weakest assumption and
│   │           repeat Step 3.
│   │
│   └── Every assumption seems ironclad (it's a genuine physical tradeoff)
│       └── This is rare. If truly no assumption breaks, it is a real
│           constraint, not a false conflict → make the tradeoff explicit,
│           pick the side that maximizes the GOAL METRIC, and elevate later →
│           find-the-constraint-tree.md.
│
└── Step 4 — Record the cloud, the broken assumption, and the injection so the
    same dilemma isn't re-litigated next time → ../assets/templates/report.md

Worked examples (the injection is the payoff)

"Move faster" vs "stay safe" (CI gate):

• A = ship value reliably; B = catch regressions → D = run full suite on every change; C = fast feedback → D' = skip/shorten the suite.
• Weak assumption (B→D): "the only way to catch regressions is to run everything."
• Injection: run the diff-affected tests on every change + the full suite nightly. Both needs met; no compromise.

"Shrink agent context" vs "keep full coverage" (Agent Skill):

• A = correct task completion; B = enough knowledge → D = load all references; C = fit the context budget → D' = drop references.
• Weak assumption (B→D): "the agent needs all references loaded up front to be correct."
• Injection: progressive disclosure — a lean SKILL.md that points to on-demand references. Full coverage, small always-loaded budget.

"Deploy continuously" vs "protect stability" (release policy):

• Weak assumption: "more frequent deploys mean more risk."
• Injection: small, automated, reversible deploys with canary + auto-rollback. Smaller batches are lower risk per deploy, not higher.

When to use this tree vs the others

Reach for the Evaporating Cloud when the constraint is known but a dilemma blocks the intervention — most often after policy-constraint-tree.md (a policy persists because of a "we have to" assumption) or when an exploit/elevate move is resisted as "too risky." For finding the constraint itself, use the measurement-driven trees.

Decision criteria

Terminal actions

• Adopt the injection — assumption broken, no new negatives; conflict evaporated → resume the blocked constraint fix.
• Try the next assumption — the injection created a new negative effect.
• Make the tradeoff explicit — genuinely no breakable assumption; decide by the goal metric and revisit after elevating.
• Escalate — no shared objective exists; this is a goal/priority disagreement for the owner, not a ToC cloud.

Record the cloud and chosen injection in ../assets/templates/report.md.

Decision Tree: Elevation Misfire (added capacity, no gain)

Symptom: You added capacity — more workers, parallelism, hardware, a bigger machine, an extra reviewer — and throughput barely changed.

Core principle: Elevation (Step 4) is the last of the Five Focusing Steps for a reason. It is the only step that costs money, and it pays off only when (a) you have already exploited and subordinated, (b) you elevated the actual constraint, and (c) the constraint hasn't already moved. A misfire means one of those three failed.

You elevated something and throughput didn't rise. Which failure?
│
├── Did you EXPLOIT before elevating?
│   │   (Was the constraint already running with zero idle/waste?)
│   │
│   └── No → you bought capacity to do work the existing capacity wasn't
│       fully doing. Revert or pause the spend. Go EXPLOIT first
│       (remove idle, batching, rework, waiting on the constraint) →
│       find-the-constraint-tree.md Step 2. Re-measure before spending again.
│
├── Did you elevate the ACTUAL constraint?
│   │   Run queries/measure-stage-times.sh (and measure-wip.sh) again, AFTER
│   │   the elevation, on the goal metric.
│   │
│   ├── The stage you elevated is still the slowest / still accumulates WIP
│   │   └── You under-elevated: added capacity but it's still the constraint.
│   │       Elevate further (more shards/workers) OR switch to a structural
│   │       exploit (e.g. cache, algorithmic fix → complexity-optimizer). 
│   │       Re-measure.
│   │
│   └── A DIFFERENT stage is now slowest / now accumulates WIP
│       └── You elevated a non-constraint (it never was binding), OR the
│           constraint MOVED to the new slowest stage. Either way, the elevation
│           you paid for did nothing for T → 
│           │
│           ├── The elevated stage was never the constraint
│           │   └── Local optimum via spending. Roll back the spend if it adds
│           │       ongoing OE. Redirect → find-the-constraint-tree.md.
│           │
│           └── The constraint genuinely moved to a new stage
│               └── Expected and good — the system improved. Continue POOGI on
│                   the NEW constraint → moving-constraint-tree.md.
│
└── Confirm with throughput accounting:
    run queries/throughput-accounting.py with before/after T, I, OE.
    │
    ├── T rose but you only looked at the local stage → not a misfire; the
    │   elevation worked. Re-identify the new constraint →
    │   find-the-constraint-tree.md.
    │
    ├── T flat, OE up (you now pay for idle capacity)
    │   └── Confirmed misfire. The capacity sits idle because it isn't the
    │       constraint or wasn't exploited. Roll back the ongoing cost.
    │
    └── T flat, I up (more parallelism created more WIP, not more output)
        └── You parallelized a non-constraint; it floods the real constraint →
            subordinate it and cap WIP → wip-accumulation-tree.md.

Common misfires by domain

• CI: added runners, but the bottleneck is a serialized DB-migration test that can't parallelize → exploit (isolate/mock it) before adding hardware.
• Dev value stream: added a reviewer, but reviews wait on flaky CI, not reviewer time → CI was the constraint.
• Runtime: scaled out web workers, but all hit one undersized database → DB is the constraint; workers now just queue on it.
• Agent Skill: added more reference detail "to be thorough", inflating context — that's negative elevation; it enlarged the very constraint (context budget).

Decision criteria (measurable)

Terminal actions

• Exploit first — you skipped Step 2; recover free capacity before spending.
• Elevate further / structurally — right target, not enough; add more or change the approach.
• Roll back the spend — elevated a non-constraint; stop paying for idle capacity.
• Continue POOGI — constraint moved (a win) → moving-constraint-tree.md.
• Subordinate + cap WIP — parallelism created WIP, not output → wip-accumulation-tree.md.

Record the elevation, its cost, and the measured T delta in ../assets/templates/report.md — elevations that don't hold are the strongest signal of a hidden policy constraint.

Decision Tree: Find the Constraint (master)

Symptom: "Optimize this / make it faster / cheaper" with no obvious target. Start here whenever the constraint is unknown — every other tree assumes you have already identified one.

Precondition — define the goal metric. ToC is meaningless without a global throughput metric. Before measuring anything, pin down what you are maximizing:

• CI/build pipeline → end-to-end wall-clock per run, or runs/hour at capacity.
• Dev value stream → PRs merged/week, or lead time from first commit to deploy.
• Agent Skill/plugin → useful task completions per session, or tokens spent per completion.
• Runtime code path → requests/sec sustained, or p99 latency at target load.

If the user has not given one, ask. Optimizing without a global metric is how local optima get rewarded.

Define goal metric + list the ordered stages
│
├── Can you time each stage? → run queries/measure-stage-times.sh
│   │
│   ├── One stage dominates wall-clock (>40% of total, or ≥2x the next)
│   │   └── That stage is the constraint candidate → CONFIRM with WIP check below
│   │
│   └── No single stage dominates (times are even)
│       └── Throughput is likely gated by flow, not a slow stage →
│           run queries/measure-wip.sh and queries/utilization-vs-throughput.py
│           │
│           ├── WIP accumulates before one stage (queue grows run-over-run)
│           │   └── That stage is the constraint → go to wip-accumulation-tree.md
│           │
│           └── A non-constraint runs >85% busy while a downstream stage starves
│               └── Over-activation → go to utilization-trap-tree.md
│
├── Can't time stages, but work flows through a queue/board →
│   run queries/measure-wip.sh
│   └── The stage with the largest / fastest-growing inbox is the constraint
│       (work waits in front of the slowest resource) → CONFIRM below
│
└── It's an Agent Skill / plugin → run queries/skill-context-cost.sh <skill-dir>
    │
    ├── SKILL.md + always-loaded content > ~500 lines or dwarfs references
    │   └── Constraint = always-loaded context budget → EXPLOIT: move detail into
    │       on-demand references; the entry point should navigate, not embed
    │
    └── Description is generic/passive (skill rarely triggers)
        └── Constraint = triggering — throughput is ZERO when the skill never fires →
            EXPLOIT: rewrite the description (intent-focused, pushy). Defer to
            dev-skill:evolve. This beats any internal optimization.

CONFIRM the constraint, then walk the Five Focusing Steps:
│
├── Step 2 — EXPLOIT (no new spend): is the constraint ever idle, blocked, or
│   doing avoidable work? Remove that first. (Examples: constraint waits on a
│   serialized upstream step; runs work that could be cached; re-does rejected work.)
│   └── Re-measure. Did the goal metric improve? 
│       ├── Yes, and it's now "good enough" → STOP. Record in report.md.
│       └── Still binding → continue to Step 3.
│
├── Step 3 — SUBORDINATE: pace every non-constraint to the constraint's rate.
│   Non-constraints should idle rather than pile WIP in front of the constraint.
│   (Drum-Buffer-Rope: release work only as fast as the constraint consumes it.)
│   ├── Non-constraints resist idling / stay over-activated →
│   │   go to utilization-trap-tree.md.
│   └── Else (they subordinate cleanly) → continue to Step 4.
│
├── Step 4 — ELEVATE (only after exploit + subordinate): add capacity to the
│   constraint — parallelize it, add a worker, upgrade it, split the batch.
│   └── Re-measure with queries/throughput-accounting.py (verify T rose, not just OE).
│       Go to elevation-misfire-tree.md if it didn't help.
│
└── Step 5 — REPEAT: the constraint has moved. Re-run this tree from the top.
    Beware inertia: kill policies built around the OLD constraint →
    go to moving-constraint-tree.md.

Usual suspects (most frequent constraints, by domain)

1. CI/build: a serialized full test suite or a single-threaded build step gating every run. 2. Dev value stream: code review (work waits longest in the review queue). 3. Agent Skill: the always-loaded context budget, or a non-triggering description. 4. Runtime: an N+1 query or a synchronous external call on the hot path.

Decision criteria (measurable)

Terminal actions

• Exploit / Subordinate / Elevate — proceed through the Five Focusing Steps above.
• Repeat — constraint moved; restart at the top.
• Dismiss — all stages <70% utilized and no WIP builds anywhere → the constraint is not a resource. Go to policy-constraint-tree.md.

Record every confirmed constraint and intervention in ../assets/templates/report.md.

Decision Tree: Local Optimum (the mirage of the non-bottleneck)

Symptom: A change measurably sped up one stage, but end-to-end throughput or lead time barely moved. The user is frustrated that "the optimization didn't work."

Core principle: "An hour saved at a non-bottleneck is a mirage." Improving a stage that is not the constraint cannot raise global throughput — the constraint still gates the system. The fix is rarely to optimize harder; it is to redirect effort to the actual constraint.

A change sped up stage X. Did global throughput improve?
│
├── Did you measure the GLOBAL metric before and after?
│   │   (not just stage X's local time — the end-to-end goal metric)
│   │
│   ├── No → run queries/throughput-accounting.py with before/after T, I, OE
│   │   │   to get the real delta. Then re-enter this tree with the numbers.
│   │
│   └── Yes → compare global throughput (T) delta:
│       │
│       ├── T rose ≥ the stage's local improvement, proportionally
│       │   └── X WAS the constraint. Not a local optimum — keep the change.
│       │       Re-identify (constraint has likely moved) →
│       │       find-the-constraint-tree.md.
│       │
│       ├── T flat (<5% change) but OE dropped or stage X is faster
│       │   └── LOCAL OPTIMUM CONFIRMED. X was not the constraint.
│       │       │
│       │       ├── Was the change cheap and side-effect-free (e.g. a cache)?
│       │       │   └── Keep it (harmless), but STOP investing here. Redirect all
│       │       │       further effort → find-the-constraint-tree.md.
│       │       │
│       │       └── Did the change add complexity, risk, or new WIP?
│       │           └── REVERT it. Local optimizations that add inventory or
│       │               complexity make the system worse (more I and OE, same T).
│       │               Then → find-the-constraint-tree.md.
│       │
│       └── T fell after the change
│           └── The change pushed MORE WIP at the real constraint (a faster
│               non-constraint floods the bottleneck). Revert, then apply
│               Drum-Buffer-Rope → wip-accumulation-tree.md.
│
└── "We can't measure global throughput"
    └── You cannot do ToC without a global metric — that absence is itself the
        first thing to fix. Define the goal metric (see find-the-constraint-tree.md
        precondition), instrument it, then return.

Why this happens (so you can prevent it)

Local efficiency feels like progress and is easy to measure, so teams optimize whatever they can see. Goldratt's measurement rule: the worth of any local improvement is judged solely by its effect on the global goal. A 50%-faster compile stage does nothing if tests (the constraint) gate every merge.

Decision criteria (measurable)

Use queries/throughput-accounting.py — it explicitly flags the OE↓/T-flat pattern as a local optimum.

Terminal actions

• Keep + redirect — change was harmless; stop investing here, go find the real constraint.
• Revert — change added I/OE/complexity without raising T.
• Re-identify — X actually was the constraint; it has moved → find-the-constraint-tree.md.
• Apply DBR — change flooded the constraint → wip-accumulation-tree.md.

Record the false start in ../assets/templates/report.md — repeated local optima in the log signal a measurement-culture problem worth naming.

Decision Tree: Moving Constraint (and the inertia trap)

Symptom: You fix one bottleneck and another immediately appears; the constraint seems to "jump around," and it's unclear whether you're making progress or chasing your tail.

Core principle: A moving constraint is the expected, healthy outcome of POOGI Step 5 — when you break a constraint, some other stage becomes the new limit, and you repeat. The danger is twofold: (1) thrashing — chasing a constraint that oscillates because it isn't stable, and (2) inertia — leaving in place policies that were built around an old constraint, which then become the new constraint themselves. Goldratt's warning: "do not allow inertia to cause a system's constraint."

The constraint moved. Is this healthy progress or thrashing?
│
├── Did the GOAL METRIC improve each time the constraint moved?
│   run queries/throughput-accounting.py across the iterations.
│   │
│   ├── Yes — T rose with each move
│   │   └── Healthy POOGI. The system is genuinely improving. Decide whether to
│   │       continue:
│   │       │
│   │       ├── Current T is "good enough" vs the goal
│   │       │   └── STOP iterating. Lock in the current constraint as a
│   │       │       deliberate control point (you WANT a known, managed
│   │       │       constraint — e.g. a strategic capacity you scale on demand).
│   │       │       Stabilize it with Drum-Buffer-Rope → wip-accumulation-tree.md.
│   │       │
│   │       └── Still short of the goal
│   │           └── Continue: re-identify and exploit the NEW constraint →
│   │               find-the-constraint-tree.md.
│   │
│   └── No — T flat or oscillating while the "constraint" jumps around
│       └── Thrashing, not progress. The most likely causes:
│           │
│           ├── Constraints are close together (several stages near-equal)
│           │   └── Whichever you touch becomes "not slowest" by a hair, so it
│           │       looks like it moved. Stop optimizing single stages; the
│           │       system is balanced and gated by FLOW → install a WIP cap and
│           │       subordinate to one chosen pacing stage →
│           │       wip-accumulation-tree.md / utilization-trap-tree.md.
│           │
│           ├── Measurement noise (you're reacting to run-to-run variance)
│           │   └── Average over multiple runs before declaring a constraint.
│           │       Re-measure with queries/measure-stage-times.sh (several runs).
│           │
│           └── The real constraint is a POLICY that re-creates the symptom
│               each time (e.g. a batch-everything rule, a metric that rewards
│               local utilization) → policy-constraint-tree.md.
│
└── INERTIA CHECK (run after every successful move): are any policies, rules,
    schedules, buffers, or instructions still tuned to the OLD constraint?
    Run queries/five-focusing-steps.sh and answer the Step 5 prompts.
    │
    ├── Yes — e.g. a buffer sized for the old bottleneck, a "always run full
    │   suite" rule from when tests were fast, a review process built around a
    │   slow stage that's now fast
    │   └── REMOVE/resize the stale policy. Left in place it becomes the new
    │       constraint. Then re-identify → find-the-constraint-tree.md.
    │
    └── No stale policies found
        └── Clean. Continue POOGI on the new constraint →
            find-the-constraint-tree.md.

Inertia: the most expensive constraint

After two or three POOGI cycles, the binding constraint is frequently no longer a resource at all — it's a rule that used to make sense. Examples:

• A CI gate that runs the entire suite "to be safe" — rational when the suite was 30s, now the constraint at 30min.
• A buffer/queue sized large for a slow stage that has since been elevated — now it just inflates lead time.
• An Agent Skill instruction to "read all references before acting" — sensible when references were few, now the context constraint.

These are invisible to stage timing because the waste is structural. The inertia check above and policy-constraint-tree.md exist to catch them.

Decision criteria (measurable)

Terminal actions

• Continue POOGI — healthy improvement; re-identify the new constraint.
• Stop + stabilize — good enough; lock the constraint as a managed control point with DBR.
• Stop chasing, cap WIP — system is balanced/flow-gated; subordinate to one pacing stage.
• Average more runs — you're reacting to noise.
• Remove stale policy — inertia; a former-constraint rule is now binding → policy-constraint-tree.md.

Record the constraint's path (stage A → B → policy C) in ../assets/templates/report.md; the trajectory tells you where to invest structurally.

Decision Tree: Policy Constraint (the limiter is a rule, not a resource)

Symptom: No physical resource is maxed out — all stages have spare capacity, nothing is starved for hardware — yet throughput is still capped. Or: you keep elevating resources and the system refuses to go faster. The binding constraint is a policy: a rule, process, metric, or instruction.

Core principle: Goldratt's most consequential claim is that the vast majority of real-world constraints are policy constraints, not physical ones — and they are the highest-leverage to fix because changing a rule usually costs nothing. A policy constraint is invisible to stage timing because the waste is structural: the resource isn't slow, it's forbidden from flowing.

Throughput is capped but no resource is maxed. Find the binding policy.
│
├── Run queries/utilization-vs-throughput.py.
│   Are ALL stages well under 100% busy (e.g. <70%) yet throughput is low?
│   │
│   ├── No — some resource IS maxed → this isn't (only) a policy constraint →
│   │   find-the-constraint-tree.md (treat the maxed resource first).
│   │
│   └── Yes — spare capacity everywhere, low throughput
│       └── A policy is gating flow. Identify which class:
│           │
│           ├── BATCHING — work is held and processed in large batches
│           │   (deploy weekly, run the full test suite on every change, review
│           │   only at end of sprint, regenerate everything on any edit)
│           │   └── EXPLOIT by shrinking the batch: deploy per-PR, gate only on
│           │       tests affected by the diff, review continuously, regenerate
│           │       only changed artifacts. Smaller batches cut lead time and
│           │       unlock idle capacity. Re-measure with throughput-accounting.py.
│           │
│           ├── SERIALIZATION — steps that could overlap are forced sequential
│           │   (one reviewer at a time, single-threaded gate, mandatory handoff
│           │   ordering, "read every reference before acting")
│           │   └── EXPLOIT by parallelizing or removing the ordering constraint:
│           │       multiple reviewers, fan-out the gate, read references on
│           │       demand instead of all up front. Re-measure.
│           │
│           ├── WRONG METRIC — local efficiency/utilization is rewarded over
│           │   global throughput, so people re-create the utilization trap
│           │   └── CHANGE THE METRIC to a global one (throughput, lead time).
│           │       Until the measurement changes, the behavior won't. This is
│           │       the root of recurring utilization-trap-tree.md symptoms.
│           │
│           ├── GATE/APPROVAL — work waits on a sign-off that adds little
│           │   (mandatory manual QA on low-risk changes, change-advisory board
│           │   for routine deploys, an approval step that rubber-stamps)
│           │   └── EXPLOIT by right-sizing the gate: risk-tier it (auto-pass
│           │       low-risk), make it asynchronous, or remove it where it adds
│           │       no protection. Verify quality doesn't regress, then keep.
│           │
│           └── STALE RULE — a policy that was rational for a FORMER constraint
│               (see moving-constraint-tree.md inertia check)
│               └── REMOVE/resize it to match the current system.
│
└── Can't tell which policy is binding?
    └── Apply the Evaporating Cloud to surface the assumption that keeps the
        policy in place — most policies persist because of an unexamined
        "we have to do it this way" → conflict-resolution-tree.md.

Verifying a policy change (don't trade throughput for safety blindly)

A policy often exists for a reason (the full suite catches regressions; the gate catches bad deploys). Before keeping a relaxation, confirm the protected outcome still holds:

• Shrinking the test gate? Confirm escaped-defect rate doesn't rise (track it for a few cycles).
• Removing an approval? Confirm the incident rate for that change class stays flat.
• Reading references on demand? Confirm the agent still produces correct output (run dev-skill:eval).

If quality regresses, you found a real (not stale) policy — restore it and elevate elsewhere. ToC improves throughput subject to the system still meeting its necessary conditions (quality, safety).

Why policy constraints are highest-leverage

Decision criteria (measurable)

Terminal actions

• Shrink the batch / parallelize / right-size the gate / change the metric — relax the binding policy, then verify necessary conditions hold.
• Remove the stale rule — inertia from a former constraint.
• Restore + elevate elsewhere — the policy is real (quality regressed); it's protecting something.
• Surface the assumption — can't tell which policy binds → conflict-resolution-tree.md.

Record the policy changed and the necessary-condition you verified in ../assets/templates/report.md.

Symptom Catalog

Each symptom is an entry point into a decision tree. Match the user's situation to a row, then open the tree. Severity reflects how badly the symptom misdirects optimization effort — P1 symptoms mean effort is actively being wasted right now.

How severity maps to action

• P1 — Effort is being wasted right now (either undirected, or aimed at a non-constraint). Stop and identify the real constraint before any more changes.
• P2 — A specific ToC step is being skipped or misapplied (subordination, exploitation, elevation). Correct the step.
• P3 — The system is improving but the meta-process needs attention (constraint moved, or a dilemma/policy needs a thinking-process tool).

Terminal states (every tree ends in one)

1. Exploit — get more from the constraint with no new spend (remove idle/waste on it). 2. Subordinate — pace non-constraints to the constraint; let them idle rather than build WIP. 3. Elevate — add capacity to the constraint (only after exploiting). 4. Change the policy — relax, reorder, or right-size a rule that is the constraint. 5. Repeat — the constraint has moved; re-identify (and check for inertia). 6. Dismiss — not a constraint problem; redirect to the appropriate skill or declare "no action; this stage is not binding."

Investigation history

Append a one-line entry per investigation to the log (default ${CLAUDE_PLUGIN_DATA}/toc-investigations.log, configurable in config.json). Over time this reveals which constraints recur and whether elevations actually held — the signal that a deeper policy constraint is in play.

Decision Tree: Utilization Trap (busy ≠ productive)

Symptom: Every stage/resource looks fully utilized — dashboards green, everyone "at capacity" — yet little actually ships and throughput is low.

Core principle: Two Goldratt rules collide here. "Activating a resource is not the same as utilizing it" — running a non-constraint flat-out only produces excess WIP, not throughput. And "the level of utilization of a non-constraint is determined by the constraint, not by its own potential." A correctly-subordinated non-constraint should sit idle part of the time. High utilization everywhere is a symptom, not a goal: balance flow, not capacity.

Everything is busy but throughput is low.
│
├── Run queries/utilization-vs-throughput.py with each stage's busy-time and
│   items-completed.
│   │
│   ├── A non-constraint stage runs >85% busy while the constraint STARVES
│   │   (constraint idle, waiting for input)
│   │   └── Over-activation. The busy non-constraint is producing the WRONG
│   │       work or work the constraint can't yet use → SUBORDINATE: throttle
│   │       the non-constraint to feed the constraint exactly what it needs,
│   │       when it needs it. Let it idle the rest of the time.
│   │
│   ├── A non-constraint runs >85% busy and the constraint is BLOCKED
│   │   (constraint can't release output downstream)
│   │   └── The downstream stage is the real constraint, not the busy one →
│   │       go to find-the-constraint-tree.md to re-identify, then subordinate
│   │       the busy stage to it.
│   │
│   ├── The CONSTRAINT itself is <100% busy while everything waits on it
│   │   └── The constraint has idle/waste on it — the highest-value fix →
│   │       EXPLOIT it (remove setup time, batching delays, rework, waiting on
│   │       approvals). An hour recovered on the constraint is an hour of system
│   │       throughput. See find-the-constraint-tree.md, Step 2.
│   │
│   └── ALL stages >85% busy and WIP growing between them
│       └── You are pushing work in faster than it can flow (a "push" system).
│           High utilization is inflating WIP and lead time, not throughput →
│           install a WIP cap / rope → wip-accumulation-tree.md.
│
└── "But idle resources look wasteful / management rewards utilization"
    └── This is a POLICY constraint masquerading as a capacity problem: the
        measurement system rewards local utilization over global throughput →
        go to policy-constraint-tree.md. Until the metric changes, people will
        re-create the trap.

Why local utilization is the wrong target

If a non-constraint is faster than the constraint, forcing it to 100% just builds inventory in front of (or behind) the constraint — more I, more lead time, zero extra T. The only resource whose utilization should approach 100% is the constraint. Everywhere else, idle time is the correct state of a balanced flow.

Decision criteria (measurable)

queries/utilization-vs-throughput.py reports utilization% and throughput per stage side by side and flags any stage that is "busy but not the constraint."

Terminal actions

• Subordinate — throttle the over-activated non-constraint to the constraint's rate; let it idle.
• Exploit — the constraint has recoverable idle/waste; remove it (highest leverage).
• Cap WIP — push system flooding itself → wip-accumulation-tree.md.
• Re-identify — the busy stage isn't the constraint and you're unsure which is → find-the-constraint-tree.md.
• Change the metric — utilization is rewarded over throughput → policy-constraint-tree.md.

Record which stages you allowed to idle in ../assets/templates/report.md — it is counterintuitive and will be questioned.

Decision Tree: WIP Accumulation (let inventory point at the constraint)

Symptom: Work-in-progress, queue depth, or an inbox keeps growing at one stage; lead time is climbing even though "everyone is working."

Core principle: In any flow, WIP piles up immediately in front of the constraint — the constraint can't consume work as fast as upstream produces it. The growing pile is a free pointer to the bottleneck. The remedy is Drum-Buffer-Rope (DBR): the constraint sets the drumbeat, a small buffer protects it from starving, and a "rope" ties the release of new work to the constraint's consumption so WIP stops growing.

WIP is growing somewhere. Where?
│
├── Run queries/measure-wip.sh across the stages.
│   │   (Counts items waiting per stage: open PRs in review, files in a queue
│   │    dir, jobs pending, branches awaiting CI, etc. Run it twice, minutes
│   │    or a cycle apart, to see which inbox GROWS.)
│   │
│   ├── One stage's inbox is largest AND growing run-over-run
│   │   └── The stage CONSUMING that inbox is the constraint. Confirm: is it
│   │       ~100% busy? (queries/utilization-vs-throughput.py)
│   │       │
│   │       ├── Yes, ~100% busy → constraint confirmed. Apply DBR (below).
│   │       │
│   │       └── No, it's idle while its inbox grows
│   │           └── The stage is BLOCKED, not slow — it waits on something
│   │               (a lock, an approval, an external dependency, a serialized
│   │               handoff). That dependency is the real constraint →
│   │               EXPLOIT by removing the block (parallelize the handoff,
│   │               pre-fetch the dependency). Then re-measure.
│   │
│   ├── WIP is growing at MULTIPLE stages
│   │   └── You are releasing work faster than the system can flow it. The
│   │       constraint is the FURTHEST-DOWNSTREAM growing stage; upstream piles
│   │       are secondary. Throttle release (rope) to that stage's rate, then
│   │       re-measure — upstream piles should drain.
│   │
│   └── No stage's WIP is growing (inboxes drain each cycle)
│       └── Not a flow/constraint problem in steady state. The slowness is
│           elsewhere → find-the-constraint-tree.md (look at stage timing).
│
└── Apply Drum-Buffer-Rope at the confirmed constraint:
    │
    ├── DRUM — set the system's pace to the constraint's actual throughput.
    │   Measure how many items/hour it really completes.
    │
    ├── BUFFER — keep a SMALL, bounded queue right before the constraint so it
    │   never starves (e.g. 1–2 items, or a few minutes of work). Bigger is not
    │   safer — it just inflates lead time (I) with no T gain.
    │
    └── ROPE — release new work into the system only when the constraint pulls
        the next item. This caps total WIP. 
        └── Re-run queries/measure-wip.sh: upstream inboxes should stop growing
            and lead time should fall while throughput holds.
            ├── Lead time fell, T unchanged → success (you removed inventory waste).
            │   Now consider EXPLOIT/ELEVATE on the constraint itself →
            │   find-the-constraint-tree.md (Five Focusing Steps).
            └── T dropped after adding the rope → buffer too small (constraint
                starving). Increase buffer by one item and re-measure.

Worked examples

• Dev value stream: 30 PRs open, all waiting on 2 reviewers. Review is the constraint. Rope = don't start new feature work until a review slot frees (WIP limit on "in review"). Buffer = a small ready-for-review queue so reviewers never idle.
• CI: builds queue behind a single shared test runner. Runner is the constraint. Rope = cap concurrent pipeline triggers; buffer = a short job queue; then EXPLOIT (shard tests) or ELEVATE (add a runner).
• Agent pipeline: generation steps outrun a slow verification step; partial outputs accumulate. Verification is the constraint. Rope = generate the next item only when verification frees.

Decision criteria (measurable)

Terminal actions

• Apply DBR — drum/buffer/rope as above; the default fix.
• Unblock — constraint is idle-but-blocked; remove the dependency (an exploit move).
• Throttle release — multiple growing piles; cap WIP to the downstream constraint's rate.
• Dismiss — no inbox grows; not a flow problem → find-the-constraint-tree.md.

Record buffer sizes and the WIP cap you set in ../assets/templates/report.md so the next investigation can tune them.