Work-in-Progress Limiting

batch: First Iteration/Batch 06

WIP Cap

notes: Common shorthand for the active-work cap at the center of the archetype.

Active Work Cap

notes: Plain-language alias that emphasizes active work rather than all backlog or incoming demand.

Kanban WIP Limit

notes: Common mechanism family that implements the archetype in workflow management.

Concurrency Limit

notes: Technical implementation mechanism that caps simultaneous active execution rather than arrival rate.

Active Case Cap

notes: Human-service and administrative mechanism for limiting simultaneously active cases.

source_primes: queueing constraint resource_management concurrency

related_primes: flow feedback threshold order boundedness observability scheduling

slug: queueing

slug: constraint

slug: concurrency

slug: flow

slug: feedback

slug: threshold

slug: order

slug: boundedness

slug: observability

slug: scheduling

components:
Active Work Boundary
WIP Limit
Capacity Basis
Admission Control Rule
Stage Capacity
Completion Bias Rule
Backlog Visibility Signal
Blocked Work Policy
Exception and Override Policy
Class-Specific WIP Limit
Pull Replenishment Signal
Work Size Normalization
Limit Breach Signal
Review and Adjustment Cadence
Owner or Steward

mechanisms:
Kanban WIP Limit
Active Case Cap
Concurrency Limit
Team Workload Cap
Project Portfolio Limit
Sprint Capacity Rule
Pull Replenishment Signal
Work Slot Token
Blocked Work Swarming
Throughput-Based Limit Review

essence_one_line: Limit active work so the system completes existing commitments instead of spreading capacity across too many simultaneous items.

compression_statement: When too many items are active at once, cap work-in-progress and allow new starts only when capacity opens, preserving focus, throughput, completion, and flow integrity at the cost of delaying new starts and making overload visible.

core_intuition: A system can look busy while moving slowly if every actor keeps starting more work than the system can advance. Work-in-Progress Limiting forces a choice: before adding another active obligation, finish, unblock, cancel, or explicitly make room for the work already underway.

canonical_formula: active_work_set + explicit_limit + admission_rule + completion_bias + visibility_signal -> governed_flow_of_active_commitments

structural_problem: A system starts more work than it can advance, causing context switching, long cycle times, hidden queues, partial completion, quality erosion, and incomplete commitments.

trigger_conditions: Many items are marked active, in progress, open, assigned, started, under review, or being executed at the same time.

trigger_conditions: Cycle time rises even though people, machines, or teams appear constantly busy.

trigger_conditions: Work waits inside active status because owners are switching among too many items.

trigger_conditions: New work is easier to start than old work is to complete, unblock, or close.

trigger_conditions: Downstream stages are overwhelmed by partially prepared handoffs from upstream stages.

trigger_conditions: Stakeholders mistake a started item for a real commitment even when the system cannot advance it promptly.

trigger_conditions: Queueing and backlog visibility reveal that active status has become another hidden waiting state.

symptoms: Large numbers of half-finished tasks, open cases, active projects, or running jobs accumulate.

symptoms: People spend more time switching, coordinating, updating status, or remembering context than completing work.

symptoms: High-priority work is delayed because many lower-value items are already occupying active capacity.

symptoms: Teams keep adding active work to satisfy demand even though throughput does not improve.

symptoms: Blocked work sits in place while additional items are started to preserve the appearance of progress.

symptoms: Quality drops because active work waits, grows stale, or is repeatedly reloaded into attention.

symptoms: Completion, closure, or release events are rare compared with starts.

root_tension: Starting work creates visible responsiveness, but each active item consumes attention, coordination, memory, resources, and exception handling. The system must choose between accepting more apparent commitments and preserving the capacity needed to finish real commitments.

anti_signatures: The central problem is that the waiting backlog is unbounded rather than that too many items are active; use Bounded Backlog.

anti_signatures: The central problem is unfair or inefficient ordering of waiting items; use Queue Discipline Design.

anti_signatures: The central problem is arrival rate over time rather than active concurrency; use Rate Limiting or Load Leveling / Demand Smoothing.

anti_signatures: The system has abundant capacity and active work does not impose meaningful context-switching, coordination, or resource cost.

anti_signatures: The work must remain continuously active for safety or legal reasons and cannot be paused, queued, or sequenced without a separate exception design.

structural_intervention: Define what counts as active work, set explicit active-work limits, and enforce an admission rule that starts new work only when active capacity is available or a governed exception is approved.

logic: Separate active work from backlog, intake, pending ideas, blocked items, and completed work.

logic: Identify the capacity basis: throughput, staffing, attention, resource contention, stage capacity, risk, or service commitments.

logic: Set a WIP limit at the appropriate scope: global, stage, team, class, resource, portfolio, or individual.

logic: Create an admission rule so new work can become active only when a slot opens or a visible exception is approved.

logic: Bias action toward finishing, unblocking, canceling, or exiting active items before starting new ones.

logic: Make active count, breaches, blocked work, and waiting backlog visible to the actors who govern flow.

logic: Review limits against throughput, cycle time, backlog growth, quality, and exception history, then adjust deliberately.

condition: Active count reaches the WIP limit.

rule: Do not start additional work until an active item exits, is canceled, is moved under a defined blocked policy, or receives a governed exception.

condition: Cycle time rises while utilization appears high.

rule: Lower or segment WIP limits before adding more starts, because excess active work may be hiding capacity fragmentation.

condition: A stage repeatedly violates its local limit.

rule: Treat the stage as a bottleneck or handoff problem; do not solve it by pushing more work into the stage.

condition: Blocked work occupies many active slots.

rule: Trigger unblocking, escalation, swarming, cancellation, or a visible blocked state rather than quietly starting replacement work.

condition: Work classes differ in urgency, risk, or capacity path.

rule: Use class-specific WIP limits or protected active slots instead of one undifferentiated cap.

condition: New urgent work must enter despite a full limit.

rule: Approve an explicit exception and decide what active work is displaced, paused, or expedited.

condition: The backlog grows because WIP limits are working.

rule: Pair the limit with backlog visibility, queue discipline, rate control, or bounded backlog rather than weakening the WIP limit silently.

invariant: Active work remains countable.

why_it_matters: Hidden active work, side channels, and informal commitments defeat the limit.

invariant: New starts are constrained by available active capacity.

why_it_matters: The archetype only works when the limit changes admission behavior.

invariant: Completion is favored over starting.

why_it_matters: The goal is not idle austerity but better flow through finished outcomes.

invariant: Blocked work is governed explicitly.

why_it_matters: Blocked items can paralyze a strict limit or invite covert over-limit starts.

invariant: Waiting demand remains visible.

why_it_matters: WIP limiting should expose overload, not hide unmet need outside the active boundary.

invariant: Exceptions are visible and reviewable.

why_it_matters: Ungoverned exceptions normalize over-commitment and recreate the original problem.

invariant: The limit reflects real capacity and risk.

why_it_matters: A limit that is arbitrary, outdated, or politically convenient will either starve useful work or fail to reduce overload.

outcome: Shorter cycle time

description: Fewer simultaneous active items reduce waiting inside active status and help work move to completion.

outcome: Higher completion reliability

description: The system makes fewer active promises and can keep more of them.

outcome: Less context switching

description: Actors spend less effort reloading, coordinating, and remembering partially completed work.

outcome: Clearer bottleneck discovery

description: WIP limits reveal where work gets stuck instead of allowing every stage to hide congestion by accepting more.

outcome: Better quality and freshness

description: Work spends less time half-finished, stale, and repeatedly interrupted.

outcome: More honest capacity governance

description: The system can see when demand exceeds active capacity and can decide whether to delay, reject, reprioritize, or add capacity.

prose_essence:
Work-in-Progress Limiting is the intervention of making active work scarce on purpose. It says that a system should not keep starting work merely because demand exists, stakeholders ask, or an item can be opened in a tool. Work becomes active only when the system has enough capacity to advance it.

The archetype is especially important because active status often carries a false promise. A request marked “in progress,” a case assigned to a worker, a project approved by leadership, or a job running in infrastructure all imply that the system is doing something meaningful. If too many such items are active, the label stops meaning progress and becomes a hidden queue.

prose_when_to_use:
Use this archetype when the system has too many active items and completion suffers. Typical signs include long cycle times, many half-finished items, frequent context switching, blocked work that sits unattended, and a pattern of starting new work to relieve pressure while old work remains incomplete.

It is useful when active work consumes scarce attention, coordination, execution capacity, review capacity, legal capacity, clinical capacity, machine resources, or leadership bandwidth. It is less useful when the real problem is a waiting backlog, arrival rate, service order, or priority rule rather than active-work overload.

prose_structural_problem:
The structural problem is over-admission into active status. A system can accept too many active commitments even if its formal backlog is well organized. Once this happens, work waits inside the active state. People and systems switch among partial obligations, handoffs multiply, decisions stall, and progress becomes fragmented.

The paradox is that starting more work often feels responsive. It gives stakeholders an immediate visible signal that their request matters. But every active item consumes capacity even when little is happening. The more active obligations accumulate, the less capacity remains to finish any one of them.

prose_intervention_logic:
The intervention has seven moves. First, define what counts as active work. Second, identify the capacity basis for how much active work the system can really advance. Third, set a limit at the appropriate scope: stage, team, person, class, resource, portfolio, or runtime. Fourth, prevent new starts when the limit is full. Fifth, bias action toward finishing and unblocking active work. Sixth, keep the waiting backlog visible. Seventh, review the limit against actual flow.

The archetype should not be reduced to a number. The number is only one piece. The core is the coupled rule: active capacity is finite, and new active commitments require room.

prose_key_components:
### Active Work Boundary

The first component is the boundary around active work. A WIP limit cannot govern ideas, requests, tasks, cases, or jobs until the system knows which of them have actually entered active handling. The boundary separates backlog from active work, active work from blocked work, and active work from completed or canceled work.

### WIP Limit

The WIP limit is the explicit cap. It may be a number of tasks, cases, projects, jobs, or execution slots. The important point is not the number itself but the behavioral constraint: once the limit is full, new work cannot become active without a completion, exit, pause, cancellation, or governed exception.

### Capacity Basis

The capacity basis explains why the limit is credible. A limit may be based on observed throughput, staffing, resource contention, attention cost, coordination burden, risk, or service commitments. Without a capacity basis, the limit is either a ritual number or a power move.

### Admission Control Rule

The admission control rule decides when new work may start. In many systems the rule is pull-based: work is pulled into active status only when a slot opens. In other systems it is policy-based: a person, team, runtime, or portfolio body must approve active entry.

### Stage Capacity

Stage capacity distributes WIP limits across workflow stages or service points. This matters when one stage is the real bottleneck. A global limit may hide local overload, while stage limits make congestion specific enough to act on.

### Completion Bias Rule

The completion bias rule shifts attention from starting to finishing. It tells actors to finish, unblock, cancel, or hand off existing active work before opening new work. This is the behavioral heart of the archetype.

### Backlog Visibility Signal

A WIP limit does not eliminate demand. It often moves demand into a waiting backlog. The backlog visibility signal keeps that waiting work visible so WIP limiting does not become a way to hide unmet need.

### Blocked Work Policy

Blocked active work is the stress test for WIP limiting. The policy decides whether blocked items keep occupying slots, move to a visible blocked state, trigger swarming, escalate, or are canceled. Without this policy, the system either freezes or quietly breaks the limit.

### Exception and Override Policy

Some work must start even when the limit is full. The exception policy handles safety, recovery, legal, strategic, or urgent exceptions while preserving auditability. A visible exception is different from an informal breach.

prose_common_mechanisms:
### Kanban WIP Limit

A Kanban WIP limit implements the archetype by putting maximum counts on board columns, lanes, people, or stages. The board is not the archetype by itself; it becomes a WIP-limiting mechanism only when the limit changes what can start or move.

### Active Case Cap

An active case cap implements the archetype in case-based systems such as support, care coordination, legal review, investigations, or public administration. It limits how many cases may be under active ownership at once so assignment remains meaningful.

### Concurrency Limit

A concurrency limit implements the archetype in technical systems. It caps simultaneous jobs, requests, threads, workflows, or operations. It should not be confused with rate limiting: the key variable is simultaneous active execution, not arrivals per time interval.

### Team Workload Cap

A team workload cap applies WIP limiting at team scope. It prevents the team from keeping too many items nominally active and pushes decisions about starting, delaying, or finishing work into the open.

### Project Portfolio Limit

A project portfolio limit applies the archetype to initiatives and programs. The scarce capacity is not just labor; it can be leadership attention, shared expertise, decision bandwidth, budget governance, and organizational change capacity.

### Sprint Capacity Rule

A sprint capacity rule can support WIP limiting when it constrains active commitments during an iteration. It is only a planning artifact if the team can still start unlimited work during the sprint.

### Pull Replenishment Signal

A pull replenishment signal starts work when a downstream slot opens. It is a mechanism for turning the WIP limit into flow behavior: capacity opening, rather than demand pressure, authorizes the next start.

### Work Slot Token

A work slot token makes active capacity tangible. A task, case, job, or project must acquire a finite slot before it can start and release the slot when it exits active status.

### Blocked Work Swarming

Blocked work swarming implements the completion-bias side of the archetype. Instead of starting replacement work when active work gets stuck, actors concentrate effort on unblocking or closing the stuck item.

### Throughput-Based Limit Review

A throughput-based review ritual compares the WIP limit against cycle time, throughput, backlog growth, blockage, exception frequency, and quality. It prevents the limit from becoming a stale number.

prose_failure_modes:
A decorative WIP limit appears in a tool but does not change behavior. People keep starting work, and the limit becomes a number everyone ignores.

Hidden WIP side channels emerge when actors use unofficial lists, private assignments, side conversations, or untracked tools to bypass the active-work boundary.

A limit set too high has no effect; a limit set too low blocks useful parallelism. Both require empirical review.

Blocked-slot paralysis occurs when blocked items consume all capacity and no one is allowed to start anything else, but no one is responsible for unblocking the stuck work.

Backlog invisibility occurs when WIP limiting keeps active work clean by pushing demand into a hidden waiting state. This is why WIP limiting often needs backlog visibility, bounded backlog, queue discipline, or expectation setting nearby.

Priority capture occurs when powerful actors repeatedly override the limit for their work, leaving ordinary work to wait indefinitely.

prose_neighbor_distinctions:
**Bounded Backlog** caps waiting work. **Work-in-Progress Limiting** caps active work. A system can need both: the active set can be limited while the waiting backlog is also bounded and visible.

**Queue Discipline Design** governs the order in which waiting work is served or admitted. Work-in-Progress Limiting governs how many items can be active. When a WIP slot opens, queue discipline may decide which waiting item enters next.

**Rate Limiting** controls arrivals or throughput per unit time. Work-in-Progress Limiting controls simultaneous active load. A request stream can be rate-limited while still allowing too many long-running active requests.

**Backpressure** sends a saturation signal upstream. A WIP limit may create the condition that triggers backpressure, but the limit itself is the local active-work constraint.

**Load Leveling or Demand Smoothing** reshapes demand over time. WIP limiting governs starts based on occupied active capacity.

**Priority-Based Admission** decides which item gets scarce access. WIP limiting decides how many active slots exist in the first place.

**Load Shedding** rejects or drops excess work. WIP limiting usually delays starts rather than discarding work, although a full system may combine the two.

prose_cross_domain_examples:
In software delivery, a team may cap active development, code review, and testing items so features move to completion instead of accumulating as half-finished work.

In support operations, specialists may carry only a limited number of active escalations, while additional escalations remain in a visible queue governed by severity and waiting time.

In cloud infrastructure, a worker pool may limit active jobs so resource contention does not collapse throughput.

In healthcare case management, a care coordinator may have an active complex-case cap so assigned patients receive real follow-through.

In project portfolio governance, leaders may limit active strategic initiatives so shared experts, decision makers, and teams can finish before new initiatives are opened.

In legal or regulatory review, an office may cap active files per reviewer and require blocked files to be escalated before new files are admitted.

prose_non_examples:
A capped waiting list is not Work-in-Progress Limiting unless it also constrains active work. That is usually Bounded Backlog.

A first-come-first-served queue is not WIP limiting by itself. It is a queue discipline.

A rate limiter that allows a fixed number of requests per minute is not WIP limiting unless it also limits simultaneous active execution.

A Kanban board without enforced WIP limits is visibility, not this archetype.

A priority rule that lets urgent work interrupt everything may worsen WIP if it adds active work without closing or pausing something else.

prose_tradeoffs:
The main tradeoff is delayed starts for better completion. Stakeholders may dislike waiting before active handling begins, even if total completion time improves.

Another tradeoff is lower apparent utilization for better flow. A WIP-limited system may intentionally leave some local capacity unfilled so the whole system can absorb variation and finish work.

A third tradeoff is visibility. WIP limiting can make unmet demand more visible in the backlog, which may create political or emotional pressure. That pressure is not a flaw; it is often evidence that the system has stopped hiding overload inside active status.

The archetype also creates governance complexity. Work classes, exceptions, blocked items, item size, and stage-specific limits may all require careful design.

prose_invariants_to_preserve:
Active work must remain countable. If people can start hidden work through side channels, the limit is not real.

New starts must be constrained by available active capacity. A limit that does not change admission behavior is only a dashboard label.

Completion must be favored over starting. The aim is not to keep work out forever; it is to finish enough work that new work can enter with integrity.

Blocked work must be governed explicitly. Blocked items should not silently consume all active capacity or become an excuse for unlimited extra starts.

Waiting demand must remain visible. WIP limiting can improve flow while still creating a queue outside active status, so backlog visibility and queue discipline often need to accompany it.

Exceptions must be visible and reviewable. Frequent invisible exceptions recreate the original over-commitment under another name.

prose_target_outcomes:
A successful WIP limit usually reduces cycle time because work spends less time waiting inside active status. It improves completion reliability because the system makes fewer active promises. It reduces context switching because actors carry fewer simultaneous obligations. It exposes bottlenecks because congestion cannot be hidden by starting more work. It can also improve quality because work waits less, grows stale less often, and receives more continuous attention once started.

The deeper outcome is honest capacity governance. The system becomes able to say: this work is active, this work is waiting, and this work cannot start until capacity opens or a visible exception is approved.

prose_parameter_dimensions:
The main tuning dimension is what counts as one active unit. Some systems count tasks. Others count cases, projects, jobs, operations, person-days, risk-weighted items, or effort points. If items vary greatly in size, a simple item count can be misleading.

The second tuning dimension is scope. A WIP limit may be global, per stage, per team, per person, per class, per resource pool, or per portfolio. Stage limits are useful for bottlenecks; class limits are useful when different work types need protected capacity.

The third tuning dimension is limit size. A good limit is low enough to change behavior but high enough to preserve useful parallelism. The right value is often found by observing cycle time, throughput, blocked work, quality, and backlog growth.

Other tuning dimensions include blocked-slot policy, replenishment trigger, exception budget, visibility granularity, and review cadence. In high-stakes systems, tuning must also consider equity, safety, legal duties, and the harm of waiting outside active status.

prose_variants_and_near_names:
Stage WIP limiting caps active work at particular workflow stages. Class-based WIP limiting reserves active capacity by work type, risk, service path, or priority class. Portfolio WIP limiting applies the same logic to active initiatives and programs. Technical concurrency WIP limiting applies it to simultaneous jobs, requests, operations, or workflows.

Near names include WIP cap, active work cap, Kanban WIP limit, active case cap, team workload cap, project portfolio limit, and concurrency limit. Most of these should be treated as mechanisms or variants, not separate archetypes, unless they develop distinct cross-domain components and failure modes.

Stage WIP Limiting

short_definition: Applies explicit active-work caps to particular workflow stages or service points rather than to the whole system.

distinctive_feature: The limit is placed at stage boundaries so each stage governs its own active load.

distinct_from_parent: The parent archetype can limit active work at any scope; this variant specifically distributes limits across workflow stages.

still_same_parent_because: The causal intervention is still limiting simultaneous active work so the system completes and advances existing commitments.

source_primes: queueing constraint flow

use_when: A workflow has distinguishable stages with different capacities or bottlenecks.

use_when: A global active-work cap hides overload in one stage while other stages appear healthy.

use_when: Handoffs, review queues, approvals, or specialized tools create local congestion.

Stage Capacity

role: Defines local capacity by stage.

Admission Control Rule

role: Allows stage entry only when a stage slot opens.

Kanban WIP Limit

role: Places visible caps on workflow columns or lanes.

Pull Replenishment Signal

role: Moves work forward only when downstream capacity opens.

domain: Software delivery

example: A team caps code review to four active items so developers finish reviews before starting new features.

domain: Publishing

example: An editorial workflow limits items in copyedit and proof stages separately.

failure_modes: A local cap shifts congestion upstream without creating a plan for backlog handling.

failure_modes: A stage-specific cap is ignored during urgent work and becomes decorative.

Class-Based WIP Limiting

short_definition: Sets different WIP limits for different classes of work, risk, customer, case, service, or priority.

distinctive_feature: The active-work budget is split by work class rather than using one undifferentiated cap.

distinct_from_parent: The parent sets a WIP limit; this variant makes the limit stratified by class or obligation.

still_same_parent_because: It still prevents too many simultaneous active items; classification only changes how the active slots are allocated.

source_primes: queueing constraint resource_management

use_when: One work class can crowd out another if all active work shares one limit.

use_when: Different work classes have different costs, urgency, service paths, or protected obligations.

use_when: The system needs to preserve a mix of active work rather than maximize one visible category.

Class-Specific WIP Limit

role: Reserves active capacity by class.

Work Size Normalization

role: Prevents class rules from being gamed through item size.

Team Workload Cap

role: Caps active work by team and class.

Work Slot Token

role: Represents class-specific slots.

domain: Customer support

example: A team reserves active slots for high-severity incidents while limiting routine feature requests.

domain: Legal review

example: A review office separates active caps for urgent injunction work and routine contract review.

failure_modes: Protected classes become too broad and consume all capacity.

failure_modes: Low-visibility classes wait indefinitely outside the active boundary.

Portfolio WIP Limiting

short_definition: Limits the number of simultaneously active projects, initiatives, programs, or strategic efforts.

distinctive_feature: The active unit is a project or initiative rather than a small operational task.

distinct_from_parent: The parent applies at any scale; this variant applies WIP limiting to portfolio governance and strategic commitment load.

still_same_parent_because: The intervention remains an active-work cap with admission only when capacity or completion creates room.

use_when: The organization starts more initiatives than it can staff, govern, decide, or finish.

use_when: Projects compete for the same leaders, specialists, budget, change capacity, or organizational attention.

use_when: Completion suffers because everything remains nominally active.

WIP Limit

role: Sets the maximum number of active initiatives.

Capacity Basis

role: Grounds the portfolio cap in real organizational capacity.

Project Portfolio Limit

role: Restricts active initiatives.

Throughput-Based Limit Review

role: Revises the cap as capacity and completion data change.

domain: Product organization

example: Leadership limits active product bets to five so teams finish launches before starting new initiatives.

domain: Public agency

example: A department caps active transformation programs to match staff and legal review capacity.

failure_modes: Executives create shadow projects outside the official portfolio.

failure_modes: Small tactical work bypasses the portfolio cap and consumes the same scarce capacity.

Technical Concurrency WIP Limiting

short_definition: Limits the number of simultaneous technical operations, jobs, workflows, threads, requests, or tasks that may be active.

distinctive_feature: The limit is enforced by technical runtime controls rather than human workflow policy alone.

distinct_from_parent: The parent is cross-domain; this variant is the software/infrastructure implementation family.

still_same_parent_because: It still caps active work and allows new work only when execution capacity opens.

use_when: Resource exhaustion, latency, lock contention, or cascading failure is caused by too much simultaneous active work.

use_when: The problem is active concurrency rather than the arrival rate alone.

use_when: Queued items can safely wait outside the active execution set.

Active Work Boundary

role: Defines what counts as active execution.

Admission Control Rule

role: Allows execution only when a slot is available.

Concurrency Limit

role: Controls simultaneous executions.

Work Slot Token

role: Represents execution capacity.

domain: Cloud infrastructure

example: A worker pool processes at most fifty jobs concurrently while excess jobs wait in a queue.

domain: Database operations

example: A migration system limits simultaneous table rewrites to avoid lock contention.

failure_modes: The concurrency limit is mistaken for rate limiting and does not protect against long-running active work.

failure_modes: A blocked active job hoards a slot indefinitely.

near_names:
WIP Cap
Active Work Cap
Kanban WIP Limits
Concurrency Limits
Active Case Caps
Team Workload Caps
Project Portfolio Limits


Yield Loss Attribution

type: archetype

source: generated

batch: Batch 13

canonical_family: Staged Processes & Drift

source_primes: yield_loss decomposition aggregation conservation_laws transformation measurement quality_control optimization defect cost_benefit_analysis traceability accountability

slug: decomposition

slug: aggregation

slug: transformation

slug: measurement

slug: optimization

slug: defect

slug: traceability

slug: accountability

slug: backpressure

slug: bycatch

slug: bottleneck

slug: pipeline

slug: validation

slug: verification

slug: dissipation

slug: bioavailability

essence_one_line: Explain why realized output falls short of its theoretical maximum by partitioning the deficit into named, measured, ranked loss channels.

compression_statement: When a transformation has a definable theoretical or design maximum but delivers less, use yield loss attribution: state the maximum and boundary assumptions, measure realized output, force the deficit to close under a balance or accounting constraint, decompose the missing amount into mutually bounded loss channels, estimate uncertainty, rank channels by recoverable value and tractability, and verify that interventions recover yield rather than merely moving losses into hidden residuals.

core_intuition: A low yield is not yet a diagnosis. It becomes actionable only when the missing output has somewhere to go: side products, scrap, leakage, waste, queues, defects, dropout, rework, dissipation, measurement error, or unexplained residual. The archetype makes loss additive, accountable, and attackable while preserving the balance that prevents wishful recovery claims.

canonical_formula: YieldLossAttribution = (TheoreticalMaximum − RealizedOutput) = Σ NamedLossChannels + ClosureResidual; RecoveryPriority = RecoverableMagnitude × Controllability × Confidence ÷ InterventionCost

structural_problem: A process, transformation, pathway, campaign, experiment, production line, data pipeline, biological recovery process, or program reports an aggregate yield, but the shortfall from its theoretical or intended output is treated as a vague efficiency problem. Without a closed accounting basis, teams chase anecdotes, optimize visible symptoms, double count losses, or improve one stage while hiding losses elsewhere.

trigger_conditions: There is a credible theoretical maximum, design target, stoichiometric ceiling, capacity-normalized reference, or expected output under stated assumptions.

trigger_conditions: Realized output is measurably below that maximum or target.

trigger_conditions: Inputs, outputs, side outputs, rejects, waste streams, dropouts, leaks, or residues can be bounded within an accounting perimeter.

trigger_conditions: The deficit can plausibly be partitioned into multiple loss channels rather than explained by one known constraint.

trigger_conditions: The channels need to be ranked because resources cannot attack every loss at once.

trigger_conditions: Stakeholders are tempted to call the gap generic waste, inefficiency, failure, or noise without closing the balance.

trigger_conditions: Improvements must be verified against the whole yield, not only against a local metric.

symptoms: Reports show a total yield or conversion percentage but do not explain where the missing fraction went.

symptoms: Different teams claim overlapping slices of the same loss, creating double counting.

symptoms: A visible side stream receives attention while the largest hidden loss remains unmeasured.

symptoms: Local process improvements improve one metric but total realized output does not rise.

symptoms: The unexplained residual is too large to make the diagnosis trustworthy.

symptoms: Disputes focus on whether the theoretical maximum is realistic rather than on which assumptions define the reference case.

symptoms: Interventions are chosen by familiarity or blame rather than by recoverable magnitude and confidence.

symptoms: Yield improvements degrade quality, increase downstream loss, or shift losses outside the accounting boundary.

root_tension: The archetype manages the tension between a simple aggregate performance number and the detailed causal/accounting partition needed for action. The aggregate yield is easy to communicate, but actionable recovery requires a closed, auditable decomposition that may reveal uncertainty, shared responsibility, and loss relocation.

anti_signatures: The goal is only to track a conserved quantity across transfers without theoretical-versus-realized deficit ranking; use conservation_accounting.

anti_signatures: The main pattern is a repeated thermodynamic, charging, regenerative, or reversible cycle compared with a least-loss ideal; use cycle_efficiency_and_reversibility_assessment.

anti_signatures: The main problem is a single throughput-limiting stage rather than a closed decomposition of missing output; use bottleneck_identification_and_relief.

anti_signatures: The problem is staged customer/user dropout without a conservation-style theoretical maximum or balance closure; use funnel_attrition_localization.

anti_signatures: The loss is an economic surplus wedge caused by a policy, price, or transaction-cost distortion; use deadweight_loss_reduction.

anti_signatures: The process has no defensible maximum, denominator, accounting boundary, or realized-output measure.

anti_signatures: The deficit is intentionally sacrificed to preserve safety, quality, rights, redundancy, diversity, or robustness and should not be minimized blindly.

anti_signatures: The shortfall is dominated by random variation with no stable channel structure; first improve measurement and uncertainty characterization.

structural_intervention: Install a yield-loss accounting frame that defines the maximum, boundary, realized output, loss taxonomy, closure rule, uncertainty, and recovery priority. The intervention transforms “low yield” from a scalar complaint into a structured diagnosis and remediation backlog constrained by balance closure.

action_logic: State the transformation, desired output, unit of account, and accounting boundary.

action_logic: Define the theoretical maximum or reference yield and document assumptions that make it valid.

action_logic: Measure realized output with uncertainty and quality acceptance criteria.

action_logic: List plausible loss channels and assign each to a mutually bounded accounting category.

action_logic: Measure, estimate, or bracket each channel using sampling, balances, traces, inspections, or experiments.

action_logic: Check that named channels plus residual close to the total deficit within tolerance.

action_logic: Rank channels by recoverable magnitude, confidence, controllability, cost, risk, and interaction with other channels.

action_logic: Choose interventions against the highest-value tractable channels while preserving quality and boundary integrity.

action_logic: Reconcile before/after yield to confirm true recovery rather than loss relocation, double counting, or denominator manipulation.

action_logic: Update the loss taxonomy as new channels, side effects, or residual explanations emerge.

decision_rules: Do not attack a loss channel as primary until its magnitude and uncertainty are visible enough to justify intervention cost.

decision_rules: Do not count the same missing output in more than one channel; every partition must have a closure rule.

decision_rules: Treat a large unexplained residual as a diagnostic failure, not as proof that all named channels are complete.

decision_rules: Prioritize recoverable loss, not merely largest observed loss, when intervention feasibility differs across channels.

decision_rules: Preserve accepted quality, safety, robustness, and fairness constraints even when they reduce apparent yield.

decision_rules: When the theoretical maximum is contested, separate maximum-assumption review from loss-channel measurement.

decision_rules: Re-run the balance after every intervention because removing one loss can expose or increase another.

target_invariants: Deficit closure: named losses plus residual must reconcile to the gap between maximum and realized output within tolerance.

target_invariants: Mutual exclusivity: loss channels should not double count the same missing output.

target_invariants: Boundary stability: improvements should not be created by moving losses outside the measured boundary.

target_invariants: Unit consistency: theoretical maximum, realized output, and loss channels must use compatible units or conversion rules.

target_invariants: Quality integrity: higher apparent yield must not be achieved by accepting nonconforming output as product.

target_invariants: Uncertainty disclosure: rankings should show confidence and residual uncertainty, not false precision.

target_invariants: Recoverability distinction: unavoidable theoretical losses, protected tradeoffs, and intentionally rejected output must remain visible.

expected_outcomes: The aggregate yield gap becomes a ranked map of actionable loss channels.

expected_outcomes: Teams stop debating generic waste and focus on the highest recoverable losses.

expected_outcomes: Double counting and hidden residuals decrease.

expected_outcomes: Interventions recover actual output, quality, or value rather than shifting losses downstream.

expected_outcomes: Theoretical maximum assumptions become explicit enough to revise without invalidating the whole improvement program.

expected_outcomes: Owners, measures, and review cadence exist for each major loss channel.

Material-Balance Yield Loss Accounting

short_definition: Partition missing physical product into side products, residues, leaks, rejects, and measurement residual under a material balance.

distinctive_feature: The accounting basis is a mass, mole, energy, or material-flow balance.

distinct_from_parent: The parent is cross-domain; this variant centers physical conservation and process chemistry/manufacturing logic.

still_same_parent_because: It uses the same theoretical maximum, realized output, named-channel closure, and recovery priority logic.

use_when: Inputs and outputs are physical quantities.

use_when: Side products, waste, residue, or leakage paths can be measured or bounded.

domain: chemistry

example: A reaction yield shortfall is split into incomplete conversion, side products, isolation loss, and unmeasured residue.

name: Staged Conversion Yield Loss Attribution

short_definition: Treat a staged pipeline or funnel as a yield problem by reconciling expected entrants, conversions, rejects, dropouts, and residuals.

distinctive_feature: The loss channels are ordered stages rather than unordered side streams.

distinct_from_parent: The parent covers any channel partition; this variant centers stage-indexed loss attribution.

still_same_parent_because: It still requires a maximum or expected output, closure, channel partitioning, and recovery ranking.

use_when: A pipeline has a definable input cohort and expected converted output.

use_when: Loss at each stage must sum to the overall conversion deficit.

domain: healthcare

example: A screening pathway reconciles invited patients, scheduled appointments, no-shows, invalid tests, and completed screenings.

Quality-Escape Yield Loss Accounting

short_definition: Separate apparent output from acceptable output by counting defects, escapes, rework, and rejected product as yield loss channels.

distinctive_feature: The realized-output measure excludes nonconforming or unsafe output.

distinct_from_parent: The parent covers all output deficits; this variant centers quality acceptance and defect channels.

still_same_parent_because: The same maximum-minus-acceptable-output deficit is partitioned into named channels.

use_when: Output quantity looks adequate but accepted-quality output is low.

use_when: Defects, rework, or escapes consume potential yield.

domain: manufacturing

example: A line counts units needing rework or later recall as yield loss even when gross production volume is high.

near_names:
Yield Gap Accounting
Loss Channel Attribution
Yield Loss Pareto
Sankey Yield Loss Map