TOC — Theory of Constraints / Теория ограничений — методология управления системой через поиск главного ограничения, которое в текущий момент определяет её общий результат. Вместо локальной оптимизации каждого компонента TOC концентрирует усилия там, где изменение действительно увеличит throughput всей системы.
№78 TRIZ помогает снять противоречие внутри найденного проблемного узла; №79 Kepner–Tregoe помогает диагностировать конкретное отклонение и выбрать действие; TOC отвечает на более системный вопрос: какой один фактор сейчас ограничивает результат всей цепочки? №81 IDEF0 помогает моделировать функции; №82 BPMN — поток процесса; TOC использует такие модели для поиска constraint и управления flow.
Хорошо сочетается с №13 Problem Formulation, №14 Decomposition, №30 Simulation, №45 Verification, №46 Observability, №47 Evals, №57 Queues & Workers, №64 Budgets, №68 Durable Workflow и №69 Distributed Reliability. Для production AI именно telemetry показывает, где реально накапливается очередь и где throughput перестаёт расти.
CONTROL PLANE: capacity policies, WIP limits, queue priorities, buffer targets, release rules. DATA PLANE: jobs, queues, work-in-progress, completions, failures. RUNTIME: TOC-derived controls могут работать автоматически — admission control, concurrency, routing, batching. OFFLINE: основная методология — анализ flow и изменение архитектуры/операций.
Success: системный throughput/goal metric improves after interventions at the identified constraint. Failure: optimizing local utilization, mistaking a symptom queue for the actual constraint, elevating before exploitation/subordination, or measuring “busy” instead of useful completed work. Evidence: end-to-end throughput, queue growth, blocking/starvation, WIP, cycle time and constraint utilization.
TOC не является универсальным load-balancer, scheduler, queue implementation или performance profiler. Она не доказывает root cause конкретного сбоя и не генерирует автоматически inventive solution. Она владеет SYSTEM-LEVEL FOCUS: IDENTIFY THE CURRENT CONSTRAINT AND ALIGN THE REST OF THE SYSTEM AROUND IT.
Revenue, completed cases, verified answers, shipped features, resolved tickets, accepted content, successful workflows.
How quickly the system creates units that count toward the goal.
Unfinished jobs, queued tasks, drafts, pending reviews, unprocessed documents.
Compute, people, tooling, model spend, infrastructure and operational effort.
PIPELINE CAPACITY: A ingest 100 jobs/min B parse 90 jobs/min C verify 30 jobs/min ← CONSTRAINT D export 80 jobs/min If A runs at 100: 100 jobs/min enter system But C can finish only: 30 jobs/min Result: WIP grows before C queues grow cycle time grows retries/timeouts may grow memory/storage pressure grows SYSTEM THROUGHPUT: ≈ 30 useful jobs/min Optimizing A from 100 → 150 does NOT improve system throughput. It may only create 50 more waiting jobs/min.
GPU, human reviewer, parser pool, browser sessions, external API quota.
Batching rule, approval policy, release window, concurrency cap, organizational procedure.
System can produce more than users/business can absorb or value.
Poor inputs cause rework; verification capacity becomes apparent constraint.
Growing WIP upstream is a strong clue.
If stage after resource is often idle waiting for it, resource may constrain flow.
If giving component more capacity increases end-to-end output, evidence for constraint strengthens.
Constraint may spend capacity fixing upstream defects rather than processing useful flow.
GOOD EVIDENCE: queue_before ↑ resource busy / scarce downstream frequently starved end-to-end throughput tracks this resource capacity increase raises whole-system throughput WEAK EVIDENCE: “this service has the highest CPU” “this team feels overloaded” “this function is slow” “this component is expensive”
Avoid starvation caused by missing inputs, approvals or batching gaps.
Validate cheap errors upstream so bottleneck does not waste scarce capacity.
Use constraint for high-value/goal-producing tasks, not optional low-value load.
Reduce unnecessary switching, cold starts, repeated setup or duplicated checks.
Upstream work released according to constraint capacity + buffer, not maximum upstream capacity.
Noncritical jobs should not crowd out critical throughput units.
Constraint sees prepared, valid work.
More workers, GPUs, reviewers, browser sessions, provider quota.
Sharding, parallel verifier pool, extra provider route.
Deterministic checks or tools take part of constraint workload.
Remove the step, alter architecture, outsource or avoid needing the constrained operation.
BEFORE: ingest 100 parse 90 verify 30 ← constraint export 80 AFTER: exploit/subordinate/elevate verify → 85 NOW: ingest 100 parse 90 verify 85 export 80 ← NEW constraint If team keeps optimizing verification from 85 → 150, system remains ≈ 80. TOC is continuous focusing, not one-time “find bottleneck” exercise.
The bottleneck's sustainable rate becomes the rhythm of the system.
Small controlled queue/time buffer ensures constraint does not starve when upstream varies.
Upstream admission/release rate tied to drum and buffer state, preventing uncontrolled WIP growth.
SOURCE ↓ ROPE / ADMISSION CONTROL ↓ UPSTREAM WORK ↓ BUFFER ↓ [ CONSTRAINT = DRUM ] ↓ DOWNSTREAM ↓ COMPLETED THROUGHPUT If buffer too low: risk starvation. If buffer too high: excess WIP / long cycle time. Goal: enough protection, not infinite queue.
Enough ready work so constraint keeps processing despite upstream variability.
Slack before critical delivery point absorbs variation.
Long cycle time, stale inputs, hidden failures and larger retry blast radius.
Green/yellow/red consumption can guide release/priorities instead of static schedules.
Useful goal units completed per time.
Started but not yet goal-complete work.
Start/release → useful completion.
How long oldest/typical work waits before constrained stage.
Time constraint idle because valid work unavailable.
Scarce capacity consumed by defects/retries.
How often protection buffer becomes dangerously depleted/overfilled.
Did intervention at suspected constraint actually improve total output?
For a stable flow: WIP ≈ THROUGHPUT × CYCLE TIME Example: Throughput: 20 tasks / hour Average WIP: 100 tasks Average cycle time: ≈ 5 hours If throughput remains 20/h but we let WIP grow to 200, cycle time tends toward ≈ 10h. This is why “keep feeding the system” can make responsiveness worse without increasing output.
Queue near component grows because later system is blocked, not because this stage lacks capacity.
Wrong scheduling makes stage look constrained.
Capacity appears low because defects loop back.
Temporary queue after batch does not necessarily define long-run constraint.
EXAMPLE:
Human reviewers:
theoretical capacity = 100 cases/day
Current policy:
every case must be reviewed twice
Effective system:
≈ 50 cases/day
If duplicate review adds
almost no quality uplift
for low-risk cases,
the constraint is partly policy-driven.
TOC move:
exploit:
prioritize high-value reviews
subordinate:
validate low-risk cases upstream
elevate:
change review policy by risk class
after eval evidence
No extra reviewer
may be required.
Stage whose capacity is lower than demand / neighboring flow.
Any factor that currently limits achievement of the system goal — resource, policy, demand, quality, information.
FLOW:
1. AI draft 500/day
2. deterministic QA 450/day
3. human approval 120/day ← constraint
4. publish 400/day
SYMPTOM:
approval queue grows daily.
BAD RESPONSE:
optimize generation from 500 → 900/day.
TOC:
IDENTIFY:
human approval = current constraint.
EXPLOIT:
reviewers see:
highest-risk / highest-value cases first;
complete evidence package;
no malformed drafts.
SUBORDINATE:
generation rate follows approval capacity;
low-priority drafts do not flood queue;
cheap checks happen before review.
ELEVATE:
eval risk-based auto-approval;
hire/train more reviewers;
improve reviewer UI;
split specialist queues.
AFTER:
approval capacity reaches 350/day.
NEW CONSTRAINT:
publishing API = 300/day.
Repeat.
REQUEST PIPELINE: API ingress 500 rps retrieval 480 rps model gateway 300 rps verification 90 rps ← actual goal constraint response delivery 450 rps Model team sees: model gateway 80% busy and wants more capacity. But verified completions are limited to ≈ 90 rps. Adding model capacity: 300 → 600 rps creates more verification WIP without raising verified throughput. TOC move: first improve/subordinate around verification. Only after verification > 300 does model gateway become relevant.
DAILY FLOW:
fetch 2M docs/day
parse 1.2M docs/day
quality 0.4M docs/day
index 1.5M docs/day
Looks like:
quality is capacity constraint.
Deeper observation:
55% quality failures
return to parse due broken table extraction.
Scarce useful throughput:
quality capacity consumed by rework.
TOC:
exploit quality:
stop sending known-bad document classes.
subordinate:
parser prechecks / quarantine before QA.
elevate:
improve table parser
only if still needed.
Result:
quality useful throughput may rise
without scaling QA workers.
ONE USER TASK: planner creates 12 branches ↓ 12 research workers ↓ 12 × web/search/model traffic ↓ evidence merge ↓ single verifier ← constraint If verifier can evaluate 3 branches/second, generating 30 branches/second only creates WIP. TOC move: identify quality merge/verifier constraint ↓ restrict research fan-out ↓ prioritize highest-value evidence gaps ↓ stop when coverage sufficient ↓ reserve DEEP fan-out only for tasks where verifier capacity and value justify it. This aligns perfectly with: FAST / STANDARD / DEEP.
Enough ready work; no urgent intervention.
Prioritize upstream tasks feeding constraint.
Escalate missing inputs or reduce competing work; admission rules change.
Don't create more task instances than flow can absorb.
Planner cannot spawn unlimited parallel branches.
One tenant/workload cannot occupy all bottleneck capacity.
WIP budget favors high-value/urgent throughput units.
Queue age, utilization, buffer state, latency, rejection rate.
Slow release, reduce optional deep work, prioritize critical jobs.
Less excess WIP, lower cycle time, constraint remains useful rather than overloaded.
Suppose: constraint = human review Upstream model cost = $0.08/task Strong model reduces review time 30%. Switch to cheaper model: cost = $0.03/task but review time +40% Local model spend improves. System effect: human constraint processes fewer cases/day. total throughput/revenue may fall. TOC asks: what is the effect on the system constraint? Not: which local component has lower unit cost?
Reject malformed jobs before scarce model/human/browser stage.
Constraint receives complete context, evidence and valid schema.
If bad work consumes constraint and then returns, system loses more throughput than same defect caught earlier.
Cause-effect map linking visible symptoms to deeper policies/conditions.
Expose assumptions behind two apparently incompatible requirements.
Map intended causal chain and possible negative branches.
Identify obstacles, intermediate objectives and ordered actions.
GOAL: reliable AI product NEED B: high quality NEED C: low latency ACTION D: verify every response deeply ACTION D': avoid deep verification APPARENT CONFLICT: D ↔ D' ASSUMPTIONS: B requires D because only deep verification catches material errors. C requires D' because all deep verification is slow. CHALLENGE ASSUMPTION: Is deep verification required for EVERY case? INJECTION: risk-based verification ladder. Then: high quality AND low average latency become compatible.
Shows which stage/factor actually governs system throughput.
If that constraint behaves unexpectedly, IS/IS NOT helps identify why.
Select/evaluate interventions and de-risk rollout.
Identifies the one constraint where improvement matters most.
If improving the constraint creates a hard contradiction, use TRIZ to generate mechanisms that escape compromise.
Clarifies functions, inputs, controls, outputs and mechanisms. Helps reveal overloaded/shared mechanisms.
Makes waits, queues, handoffs, parallel gateways and approvals visible. TOC then asks which one limits end-to-end goal throughput.
Convert docs/traces/workflow descriptions into stage map and candidate bottlenecks.
Based on queues, dependencies, policy and rework patterns.
AI can propose but must quantify expected system effect.
LLM should not declare bottleneck without flow evidence or experiment.
{
"system_goal": "verified reports completed/day",
"flow_unit": "report",
"stages": [
{
"id":"research",
"capacity_per_day":180,
"wip":24,
"queue_age_p95":"18m"
},
{
"id":"human_review",
"capacity_per_day":55,
"wip":140,
"queue_age_p95":"9h"
}
],
"constraint_candidate":"human_review",
"evidence":[
"queue_before_growing",
"downstream_starved",
"capacity_test_increases_total_output"
],
"exploit_actions":[],
"subordinate_actions":[],
"elevate_actions":[],
"expected_throughput_delta":null,
"verification_plan":[]
}Constraint hypothesis should be confirmed by end-to-end behavior: if intervention there does not improve system throughput, reassess the model.
| Question | Why it matters |
|---|---|
| Does work accumulate before it? | Suggests incoming demand exceeds effective processing. |
| Is downstream often waiting for its output? | Shows stage controls supply to later work. |
| Does reducing its rework increase system output? | Constraint capacity is being wasted. |
| Does adding temporary capacity improve end-to-end throughput? | Strong empirical test. |
| Does optimizing another stage leave throughput unchanged? | Supports that other stage is non-constraint. |
| Could a policy rather than physical capacity be limiting flow? | Avoids unnecessary scale spend. |
| Metric | Use |
|---|---|
| Verified task throughput | Completed tasks that pass acceptance per hour/day. |
| End-to-end cycle time | User/job release → accepted outcome. |
| WIP by stage | Where unfinished work accumulates. |
| Queue age p95 | Better than queue length alone when task sizes vary. |
| Constraint starvation | How often scarce capacity waits for valid work. |
| Constraint rework rate | Share of scarce capacity wasted on repeated/invalid work. |
| Throughput per constraint-hour | Useful output normalized by scarce resource time. |
| ΔThroughput after intervention | Empirical confirmation that constraint hypothesis was meaningful. |
| Time | Action |
|---|---|
| 0–4 min | Define system boundary, goal and one throughput unit. |
| 4–9 min | Map 5–10 major stages from entry to useful completion. |
| 9–14 min | Add capacity, WIP, queue age, rework, starvation evidence. |
| 14–18 min | Select constraint candidate and state why it limits system throughput. |
| 18–22 min | List exploitation moves that require little/no new capacity. |
| 22–26 min | List subordination rules for upstream/downstream flow. |
| 26–28 min | If still constrained, propose elevation options. |
| 28–30 min | Define metric/experiment that proves total throughput improved and when to reassess the new constraint. |
TOC WORKSHEET ======================================================= 1. SYSTEM BOUNDARY From: → To: → 2. SYSTEM GOAL → 3. THROUGHPUT UNIT One useful completion is: → 4. FLOW STAGES Stage: Capacity: WIP: Queue age: Rework: Starvation: Notes: (repeat) 5. CURRENT CONSTRAINT CANDIDATE → Evidence: [ ] queue accumulates before [ ] downstream starves after [ ] resource/policy is scarce [ ] capacity change affects total throughput [ ] rework consumes scarce capacity [ ] other stage optimization does not move throughput 6. EXPLOIT How can we get more useful output without major capacity investment? → → → 7. SUBORDINATE What must upstream stop / slow / prioritize? → What cheap checks should happen before constraint? → What downstream behavior should protect flow? → 8. BUFFER What should protect the constraint? → Target: → 9. ELEVATE Only if still needed: [ ] add capacity [ ] parallelize [ ] automate [ ] redesign [ ] change policy [ ] outsource / alternate provider 10. EXPECTED EFFECT Baseline throughput: → Expected: → WIP: → Cycle time: → 11. VERIFICATION What experiment proves this was the real constraint? → 12. REPEAT When will we re-identify the new constraint? →
You are assisting with Theory of Constraints analysis.
Do not optimize components independently.
1. Define:
- system boundary;
- system goal;
- one measurable throughput unit.
2. Map the end-to-end flow from release to useful completion.
3. For each stage collect:
capacity, WIP, queue age, rework,
blocking, starvation and policy constraints.
4. Do not declare the slowest-looking stage a constraint.
5. Rank constraint candidates using evidence:
- work accumulation before;
- downstream starvation;
- scarce/effective capacity;
- end-to-end throughput response to capacity changes.
6. For the leading candidate propose:
a) EXPLOIT actions first;
b) SUBORDINATE actions second;
c) ELEVATE only if needed.
7. Identify WIP/admission/buffer controls.
8. Estimate how each intervention affects:
throughput, WIP, cycle time, quality,
operating cost and secondary bottlenecks.
9. Define a falsifiable experiment:
if this really is the constraint,
what system-level metric should improve?
10. After improvement,
explicitly search for the next constraint.
11. Never use “100% utilization everywhere”
as a goal.
12. Prefer system throughput
over local optimization.
| Question | Answer |
|---|---|
| Стоит ли использовать? | Да. Когда есть multi-stage flow, очереди, ограниченная capacity, human review, provider quotas или recurring delivery bottlenecks. |
| Separate Component? | N/A. Это methodology/control logic, not runtime service. |
| Минимум 80% ценности? | Goal + throughput unit + flow map + real constraint + exploit + subordinate + elevate + verify Δthroughput + repeat. |
| Когда overkill? | Single isolated operation without meaningful flow dependencies, simple bug, or decision where throughput is not the system objective. |
| Trigger? | “More local capacity/optimization is not improving end-to-end completion”; “queues keep growing”; “one scarce resource governs output”. |
| Как измерить uplift? | Verified throughput ↑, WIP ↓, cycle time ↓, constraint rework/starvation ↓, cost per useful completion stable or lower. |
| Можно ли использовать AI? | Да. AI can map flow and propose interventions; observability and experiments must establish the actual constraint and throughput delta. |
Without system goal, “constraint” has no operational meaning.
Busy components are not the target.
Spread improvements only after system evidence says constraint moved.
Remove idle/rework/setup/low-value load before buying capacity.
Upstream should not create more WIP than constraint can convert.
Enough work to avoid starvation, not an infinite backlog.
Evaluate decisions by effect on scarce capacity and total throughput.
Do not assume the answer is more hardware/people.
A solved constraint creates a new system constraint.
SYSTEM ↓ DEFINE GOAL ↓ DEFINE THROUGHPUT UNIT ↓ MAP END-TO-END FLOW stage A ↓ stage B ↓ stage C ↓ stage D ↓ useful completion ↓ MEASURE: capacity WIP queue age rework blocking starvation policy constraints ↓ IDENTIFY CURRENT CONSTRAINT Question: “Which factor currently limits the rate at which the WHOLE SYSTEM creates goal units?” ↓ ──────────────────────────────────── 1. IDENTIFY ──────────────────────────────────── candidate must explain: queue build-up downstream starvation scarcity throughput response ↓ ──────────────────────────────────── 2. EXPLOIT ──────────────────────────────────── protect scarce capacity remove: idle rework invalid input low-value work setup waste unnecessary switching ↓ ──────────────────────────────────── 3. SUBORDINATE ──────────────────────────────────── upstream: release only what flow can absorb apply cheap quality gates respect WIP limits prioritize goal-critical jobs buffer: protect constraint avoid starvation stay bounded downstream: be ready for constraint output ↓ ──────────────────────────────────── 4. ELEVATE ──────────────────────────────────── only if still needed: add capacity parallelize automate change policy redesign alternate provider remove step ↓ MEASURE SYSTEM EFFECT throughput ↑ ? WIP ↓ ? cycle time ↓ ? rework ↓ ? cost / useful completion acceptable? ↓ NO → constraint model may be wrong → reassess YES ↓ ──────────────────────────────────── 5. REPEAT ──────────────────────────────────── the constraint moved. find the new one. ════════════════════════════════════ AI SYSTEM EXAMPLES: HUMAN REVIEW can constrain verified output MODEL PROVIDER can constrain inference flow VECTOR / RETRIEVAL can constrain evidence path BROWSER SESSIONS can constrain action agents EXTERNAL API QUOTA can constrain tool throughput PARSER QUALITY can create rework that consumes QA POLICY can constrain more than hardware DEEP REASONING can create WIP at verifier/merge stage ════════════════════════════════════ TOC + OTHER METHODS: TOC where is the leverage point? KT why is that point behaving badly? TRIZ how can we redesign the conflict? IDEF0 what functions/resources/control exist? BPMN how does work actually flow? EVALS / OBSERVABILITY did the change really improve the system? ════════════════════════════════════ THE CENTRAL QUESTION IS NOT: “WHICH COMPONENT CAN WE MAKE FASTER?” IT IS: “WHICH ONE CHANGE CAN INCREASE THE OUTPUT OF THE WHOLE SYSTEM RIGHT NOW?” AND THEN: “WHAT MUST THE REST OF THE SYSTEM STOP DOING SO IT DOES NOT OVERWHELM THAT CONSTRAINT?” THAT IS THE PRACTICAL POWER OF TOC.
A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №80 TOC — Theory of Constraints.
B–E. Existing boundary and placement. The existing conceptual boundary, class METHODOLOGY, default N/A and owner Design-time / Problem Solving remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.
F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.
I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.
K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.