Push-Pull Decoupling Point Design

batch: Batch 14

aliases: make-to-stock / make-to-order split design

alias_records: make-to-stock / make-to-order split design

related_primes: backpressure flow queueing demand uncertainty variability constraint boundary resource_management scheduling pipeline reserve coupling order optionality

slug: buffering

slug: postponement

slug: backpressure

slug: flow

slug: queueing

slug: demand

slug: uncertainty

slug: variability

slug: constraint

slug: boundary

slug: scheduling

slug: pipeline

slug: reserve

slug: coupling

slug: order

slug: optionality

components:
Flow Stage Map
Demand Variability Profile
Upstream Forecast-Push Regime
Downstream Order-Pull Regime
Decoupling Buffer
Intermediate State Specification
Pull Signal Contract
Trade-off Positioning Model
Buffer Replenishment Rule
Service Promise Boundary
Boundary Owner and Exception Path
Boundary Performance Dashboard
Segmented Decoupling Policy
Modular Configuration Architecture
Repositioning Cadence

mechanisms: Make-to-Stock / Make-to-Order Split Policy

mechanisms: Configuration Cell or Final Assembly Cell

essence_one_line: Place the buffer at the point where forecastable upstream preparation should stop and demand-specific downstream fulfillment should begin.

compression_statement: A flow often needs both efficiency and fit: upstream stages want stable plans, batch economies, and aggregated forecasts, while downstream stages need specific orders, cases, users, or contexts. This archetype deliberately places a stocked, reserved, or prepared intermediate boundary between the two. The boundary absorbs forecast error, protects downstream customization, and makes the inventory-versus-lead-time-versus-customization trade-off explicit instead of letting it drift.

core_intuition: Do not push certainty further downstream than the system really has. Prebuild only the part that is common enough to forecast, then pause at a meaningful intermediate state until the demand signal arrives. Moving the point changes who carries uncertainty: inventory and obsolescence upstream, waiting time and capacity strain downstream, or customization loss for the user.

canonical_formula: Decoupling point position = the latest upstream stage that can be safely forecast and standardized, constrained by demand uncertainty, buffer cost, lead-time promise, customization value, capacity flexibility, and service-risk tolerance.

structural_problem: A flow is managed as all-push or all-pull even though different stages face different uncertainty, standardization, and response-time economics.

trigger_conditions: Demand is uncertain in final mix, timing, configuration, location, priority, or service context.

trigger_conditions: Some upstream work can be prepared, standardized, pooled, batched, or reserved before the final demand signal is known.

trigger_conditions: Downstream fulfillment must still adapt to actual orders, cases, users, incidents, or contexts.

trigger_conditions: The system experiences recurring tension among long lead times, excess inventory, low customization, stockouts, expediting, or rework.

trigger_conditions: No accountable boundary states where forecast risk ends and order-specific commitment begins.

symptoms: Finished inventory piles up in configurations that actual demand does not want.

symptoms: Teams expedite custom work from raw inputs because nothing useful was prepared in advance.

symptoms: Lead-time promises are unstable because the system discovers too late which stages could have been prebuilt.

symptoms: Forecast errors propagate into downstream overload, stockouts, substitutions, or manual exceptions.

symptoms: Customization decisions are made too early and create obsolescence, or too late and create delay.

symptoms: Different functions optimize their own boundary: sales promises customization, production wants batches, operations wants low inventory, and finance sees only carrying cost.

root_tension: Efficiency improves when work is aggregated and pushed before demand is certain, but fit improves when commitment waits for the actual demand signal. The decoupling point is the negotiated boundary between those two logics.

anti_signatures: The flow has negligible demand uncertainty and final configuration is stable enough to push end-to-end.

anti_signatures: The work cannot be meaningfully prepared before the demand signal without destroying value or safety.

anti_signatures: The problem is only a generic queue-capacity mismatch, not a question of where forecast-based preparation should stop.

anti_signatures: The primary intervention needed is a downstream throttling signal; that is closer to Backpressure than to decoupling point design.

anti_signatures: The boundary is dictated externally and cannot be moved, buffered, governed, or instrumented.

structural_intervention: Partition a flow into an upstream forecast-push regime and a downstream order-pull regime, separated by a deliberately sized and governed buffer of reusable intermediate readiness.

action_logic: Map the flow stages from raw input or capacity commitment through final fulfillment, including information, material, labor, data, and approval handoffs.

action_logic: Segment demand by variability, volume, value, customization depth, urgency, and service promise so the boundary can differ by product, case, customer, or class of work.

action_logic: Identify intermediate states that are useful before final demand is known, such as semi-finished goods, configured templates, reserved capacity, prequalified cases, precomputed data, or staffed service windows.

action_logic: Choose a candidate decoupling point by comparing upstream forecastability against downstream need for specificity and responsiveness.

action_logic: Size and govern the buffer at that point, including replenishment rule, review cadence, service level, aging rule, and exception path.

action_logic: Define the downstream pull signal: what counts as a valid order, case, request, trigger, or context strong enough to consume or customize the buffer.

action_logic: Instrument performance across the boundary using lead time, fill rate, buffer turns, obsolescence, expediting, customization quality, and forecast-error absorption.

action_logic: Reposition the boundary when demand mix, modularity, capacity flexibility, or service promises change materially.

decision_rules: Move the point downstream when demand is stable, common intermediates are cheap to hold, and short lead time matters more than configuration risk.

decision_rules: Move the point upstream when customization value is high, finished inventory obsolescence is costly, or wrong early commitment creates rework.

decision_rules: Use multiple decoupling points when demand segments have materially different variability, value, volume, or service promises.

decision_rules: Do not increase buffer size to hide a poorly placed boundary; first test whether the intermediate state is the right one.

decision_rules: If downstream capacity is the binding constraint, pair the decoupling point with backpressure or WIP limits rather than letting pull signals exceed fulfillment capacity.

target_invariants: The buffer must preserve optionality: stored or prepared intermediates should remain reusable across enough downstream demands to justify holding them.

target_invariants: The downstream pull signal must represent real demand, not a disguised forecast or political request for priority.

target_invariants: The upstream forecast-push regime must be measured against forecast error, not judged only by production efficiency.

target_invariants: The boundary must remain visible and owned so exceptions do not quietly move customization risk to the wrong stage.

target_invariants: Service promises must be consistent with the chosen point, buffer size, and downstream capacity.

expected_outcomes: Lower total mismatch among inventory, lead time, customization, and expediting cost.

expected_outcomes: Clearer ownership for forecast risk upstream and order-specific fulfillment downstream.

expected_outcomes: More stable service promises because the reusable part of the work is prepared before demand arrives.

expected_outcomes: Reduced obsolete finished goods, hidden rework, and emergency customization.

expected_outcomes: Better ability to segment flows: standard items can be pushed farther; uncertain or high-value variants can wait for pull.

Customer-Order Decoupling Point Design

short_definition: Places the point in a supply chain where customer-specific order information begins governing the flow.

distinctive_feature: The downstream pull signal is specifically a customer order, usually with product, quantity, location, or delivery promise details.

distinct_from_parent: It narrows the parent to customer-order logistics and manufacturing language.

still_same_parent_because: It uses the same push-pull boundary, buffer, replenishment, and trade-off structure.

use_when: A product or fulfillment system must decide how far to stock or prepare before customer orders are known.

use_when: The major trade-off is between finished inventory exposure and customer lead time.

example: Stock common subassemblies, then assemble to order after the customer selects final options.

failure_modes: Treating all products as one segment hides which items need different decoupling points.

Postponement Boundary Design

short_definition: Delays final configuration until more demand information arrives while still preparing reusable upstream intermediates.

distinctive_feature: The variant emphasizes delayed commitment and option preservation more than stock location alone.

distinct_from_parent: It is a postponement-heavy case of the broader push-pull boundary pattern.

still_same_parent_because: Postponement requires a decoupling boundary and reusable intermediate state to be operationally useful.

use_when: The system can preserve option value by delaying color, packaging, configuration, localization, routing, or allocation.

use_when: Early final commitment creates costly obsolescence or rework.

example: Prebuild a common image, then localize settings only when a tenant request arrives.

failure_modes: Postponing too much can shift the entire burden to downstream capacity and lengthen fulfillment.

Service Readiness Decoupling

short_definition: Separates generic service readiness prepared in advance from case-specific service fulfillment triggered by actual demand.

distinctive_feature: The buffer is often capacity, information, templates, or prequalified readiness rather than physical stock.

distinct_from_parent: It translates the flow boundary into service operations where readiness is partly intangible.

still_same_parent_because: It still uses upstream preparation, downstream pull, and a governed intermediate readiness state.

use_when: Service work has common preparatory steps but final action depends on the specific case, client, patient, learner, or incident.

use_when: The system must reduce response time without pretending all future cases are known.

example: Prepare standard intake capacity, then allocate specialized clinical work after the real case signal arrives.

failure_modes: Prepared readiness may be consumed by low-priority demand unless eligibility rules are explicit.

near_names:
Decoupling Point Design
Push-Pull Boundary Design
Forecast-to-Order Boundary Design
Order-Penetration Point Design
Make-to-Stock / Make-to-Order Boundary


Queue Aging and Starvation Prevention

type: archetype

source: generated

batch: First Iteration/Batch 06

aliases:
Queue Aging
Starvation Prevention
Priority Aging Overlay
Wait-Time Priority Boost
Maximum Wait Safeguard

source_primes: queueing threshold order procedural_fairness

related_primes: resource_management feedback constraint observability boundedness scheduling

proposed_primes: time fairness

slug: threshold

slug: feedback

slug: observability

slug: boundedness

components:
Waiting-Time Clock
Age Threshold
Priority Aging Rule
Starvation Prevention Rule
Service Guarantee
Escalation Path
Fairness Policy
Risk and Urgency Override
Age Distribution Visibility
Audit and Remedy Loop
Service-Level Objective
Notification Policy
Revalidation Rule
Class-Level Service Share

mechanisms:
Priority Aging
Wait-Time-Based Priority Boost
Maximum Wait Guarantee
SLA Escalation
Deadline Queue
Fairness Rotation
Oldest-Item Sweep
Aging Dashboard

essence_one_line: Increase priority, service share, escalation, or review as waiting time grows so lower-priority work is not ignored indefinitely.

compression_statement: When a queue discipline favors some items or classes so strongly that others can wait beyond acceptable limits, add age-sensitive treatment rules that eventually change priority, trigger escalation, guarantee review, or force explicit disposition while preserving legitimate urgency and risk distinctions.

core_intuition: A priority rule can be locally rational and still produce tail injustice. Queue aging treats time-in-queue as information: the longer something waits, the stronger the evidence that ordinary service rules are failing it. The intervention gives waiting age causal force without turning every old item into an emergency.

canonical_formula: starvation_risk = persistent_bypass + increasing_wait_age; intervention = measure_age + define_threshold_or_curve + change_treatment + preserve_urgency_overrides + audit_tail_cases

structural_problem: A waiting system repeatedly serves some classes, priorities, or items while others remain queued indefinitely or beyond acceptable limits.

trigger_conditions: a priority, class, triage, or efficiency rule can repeatedly bypass low-priority work

trigger_conditions: older queued items lack a reliable path to service, review, escalation, or explicit disposition

trigger_conditions: tail waiting times matter ethically, legally, operationally, or politically

trigger_conditions: average throughput looks acceptable while a minority of items wait excessively

trigger_conditions: the system cannot simply remove priority distinctions because urgency, risk, or value still matter

symptoms: old tickets, cases, jobs, or requests remain unresolved while newer higher-priority work continues to flow

symptoms: low-priority classes develop hidden backlogs, repeated complaints, or loss of trust

symptoms: service dashboards report acceptable averages but poor oldest-item or percentile measures

symptoms: operators use ad hoc heroics to rescue aged items because no formal rule exists

symptoms: actors learn to game priority labels because ordinary waiting does not lead to attention

root_tension: The system needs priority or efficiency distinctions, but those distinctions can become absolute enough to violate the invariant that waiting work should eventually be served, reviewed, or explicitly resolved.

anti_signatures: simple FIFO service already provides acceptable maximum waits and no repeated bypass occurs

anti_signatures: items become invalid or unsafe with age and should be expired rather than boosted

anti_signatures: the central problem is total lack of capacity rather than starvation within a service rule

anti_signatures: newer critical items must always supersede older items because delay would cause immediate severe harm

anti_signatures: the queue is purely informational and no service, review, or disposition is expected

structural_intervention: Track waiting age and attach treatment-changing rules so excessive waiting increases priority, service share, escalation, review obligation, or guaranteed disposition.

action_logic: define when waiting begins and how age is measured for each item or class

action_logic: identify which kinds of delay count as starvation risk rather than acceptable waiting

action_logic: set age thresholds, aging curves, service shares, or maximum-wait guarantees

action_logic: modify queue treatment when age crosses the rule: boost, rotate, escalate, reserve capacity, or force review

action_logic: preserve risk and urgency overrides so aging does not create unsafe priority inversion

action_logic: monitor tail-age cases and audit whether the rule actually prevents indefinite neglect

decision_rules: apply aging only to items that remain valid, actionable, and legitimately queued

decision_rules: make age affect treatment before the oldest-item tail becomes ethically or operationally unacceptable

decision_rules: use stronger guarantees when waiting creates rights, safety, trust, or irreversible opportunity harms

decision_rules: cap or moderate aging boosts where strict priority is necessary for safety or mission-critical service

decision_rules: escalate systemic starvation to capacity, policy, or governance review rather than treating every aged item as an isolated exception

target_invariants: no class or item waits indefinitely without service, review, reclassification, or explicit disposition

target_invariants: age-sensitive treatment remains compatible with legitimate urgency, risk, and safety distinctions

target_invariants: waiting-time measurement is stable, auditable, and resistant to manipulation

target_invariants: the oldest or most-neglected cases are visible rather than hidden by averages

target_invariants: the system distinguishes starvation prevention from false promises of unlimited capacity

expected_outcomes: reduced tail waiting and fewer indefinitely neglected items

expected_outcomes: more procedurally fair service across priority classes or work categories

expected_outcomes: better visibility into priority rules that are producing pathological delay

expected_outcomes: less reliance on informal escalation, favoritism, or complaint-driven rescue

expected_outcomes: clearer accountability when the queue cannot satisfy its service obligations

prose_essence:
Queue Aging and Starvation Prevention is the pattern of making waiting time matter. It is used when a queue has a legitimate reason to favor some work over other work, but that favoritism can become so strong that low-priority work waits indefinitely. The archetype does not abolish priority. Instead, it adds a corrective layer: as an item or class waits, the system must eventually boost it, review it, reserve capacity for it, escalate it, or explicitly resolve it.

The practical intuition is simple: a queue rule can be fair in the short run and unfair in the tail. A few urgent cases should pass routine cases. But if routine cases can be bypassed forever, the service order has stopped being a priority rule and has become an abandonment rule. Aging turns the duration of neglect into a reason for intervention.

prose_when_to_use:
Use this archetype when the queue has real priority distinctions, but those distinctions produce a neglected tail. Typical signs include old tickets that never close, low-priority cases that only move after complaints, regional or class-based queues that receive little attention, or dashboards where average wait looks acceptable while the oldest cases are extreme.

It is especially useful when waiting time itself creates harm: loss of opportunity, trust erosion, legal exposure, worsening health, technical starvation, or escalating cost. It is also useful when the organization wants to keep triage or prioritization but cannot accept indefinite deferral as a side effect.

Do not use this as a substitute for capacity. If the queue is overloaded for everyone, aging rules may still improve fairness, but they cannot create enough service. In that case they should be paired with capacity adjustment, bounded backlog, load shedding, or service-rate matching.

prose_structural_problem:
The structural problem is repeated bypass. A service system has limited capacity and a rule that favors some work: high priority, high value, short duration, urgent risk, influential customer, nearby geography, or easy completion. That rule may be locally sensible. But because new favored work keeps arriving, disfavored work can remain perpetually behind.

This creates a tail-pathology: the system’s averages can look healthy while a minority of items wait far beyond acceptable limits. The harm is often invisible because the old items are not active, not loud, or not measured in the headline metric.

Aging and starvation prevention treats the oldest unresolved cases as evidence about the queue’s structure. The question is not only “what should be served next?” but also “what has been bypassed for too long under the current rule?”

prose_intervention_logic:
The intervention begins by defining a stable waiting-time clock. The system must know when waiting begins, whether pauses count, and whether resets are legitimate. It then defines age thresholds, priority-aging curves, maximum-wait guarantees, class rotations, or escalation triggers.

When an item crosses an age rule, its treatment changes. It may receive a priority boost, be routed to an escalation path, enter a protected service window, trigger supervisory review, or receive explicit disposition. The treatment change should be concrete. A label or dashboard alert alone is not enough.

The design also preserves overrides. Newer items with genuine emergency risk may still supersede old low-risk items. The archetype works best when it softens strict priority rather than replacing all priority with age alone.

prose_key_components:
### Waiting-Time Clock

The waiting-time clock records how long each item has been waiting from a defined start point. This is the measurement foundation. Without a stable clock, the system cannot distinguish ordinary delay from starvation, and it cannot audit whether operators are resetting or manipulating age.

### Age Threshold

The age threshold defines when waiting becomes unacceptable enough to require action. It may be a single maximum wait, several escalating thresholds, or a continuous aging curve. The threshold should reflect harm and obligation, not only managerial convenience.

### Priority Aging Rule

The priority aging rule specifies how waiting changes treatment. In technical systems it may increase a priority score. In service systems it may trigger review, protected capacity, or queue movement. The rule should be strong enough to matter but bounded enough to preserve legitimate urgency.

### Starvation Prevention Rule

The starvation prevention rule states the invariant: no queued item or class should wait indefinitely without service, review, reclassification, or explicit disposition. This component prevents the design from collapsing into vague concern about old work.

### Service Guarantee

The service guarantee says what must happen when an item becomes too old. The guaranteed action may be actual service, supervisory review, escalation, apology and remedy, or clean rejection. It should be honest about capacity: an impossible service guarantee becomes a trust-damaging promise.

### Escalation Path

The escalation path gives aged items somewhere to go when the ordinary queue cannot resolve them. This might be a specialist team, a supervisor, an exception lane, or a protected review meeting. Escalation must be resourced; otherwise it simply creates a second starving queue.

### Fairness Policy

The fairness policy defines what kind of waiting is unacceptable. Fairness might mean no indefinite waiting, proportional service across classes, equal maximum wait, protected access for low-visibility groups, or rotation among queues. The policy gives moral and operational shape to the aging rule.

### Risk and Urgency Override

The risk and urgency override prevents old low-risk work from displacing genuinely critical new work. This is essential in clinical, safety, security, and incident-response settings. Starvation prevention should not create dangerous priority inversion.

### Age Distribution Visibility

Age distribution visibility shows the tail, not only the average. It displays oldest items, percentile waits, age by class, age by owner, and breached thresholds. This component makes hidden starvation legible.

### Audit and Remedy Loop

The audit and remedy loop checks whether the design actually prevents starvation. It reviews aged cases, threshold breaches, class-level neglect, timestamp resets, and repeated bypass. It also creates accountability when the rule fails.

prose_common_mechanisms:
### Priority Aging

Priority aging is a mechanism that increases priority as waiting grows. It is common in schedulers and queue-management systems. It implements the archetype when the boost is explicitly intended to prevent indefinite deferral rather than merely tune throughput.

### Wait-Time-Based Priority Boost

A wait-time-based boost applies a step change when an item crosses a threshold. This is easier to explain than continuous priority aging, but it can create cliffs where many items suddenly jump at the same time.

### Maximum Wait Guarantee

A maximum wait guarantee sets an outer boundary on waiting. It can be powerful in high-stakes services because it translates “too long” into a specific action obligation. The guarantee may require service, review, escalation, or explicit disposition.

### SLA Escalation

SLA escalation is a workflow mechanism. When an item nears or breaches a service-level commitment, it moves to a different attention path. This implements the archetype only when escalation changes authority, capacity, or obligation; a notification alone is not enough.

### Deadline Queue

A deadline queue orders work by latest acceptable service time. It is useful when each item has a meaningful due date. It should be treated as a mechanism, not the archetype itself, because the broader intervention is age-sensitive starvation prevention.

### Fairness Rotation

Fairness rotation serves classes, queues, or groups in a rotating pattern so one class cannot monopolize capacity. It is especially relevant when starvation occurs at the group level. Rotation can be inefficient in the short run but protective in the long run.

### Oldest-Item Sweep

An oldest-item sweep is a periodic ritual in which the team reviews the oldest unresolved items. The sweep may close invalid work, reclassify it, escalate it, or assign protected capacity. It is simple but can become ceremonial unless connected to real action.

### Aging Dashboard

An aging dashboard displays item age, threshold breaches, and tail distribution. It supports the archetype, but it is not sufficient. A dashboard without treatment-changing rules is backlog visibility, not starvation prevention.

prose_failure_modes:
A threshold set too late merely legitimizes neglect. A threshold set too early can overwhelm urgent work. A boost without a risk override can create priority inversion. An escalation path without capacity becomes another backlog.

Another common failure mode is aging theatre: old items are displayed, flagged, or escalated in name only, but no actual treatment changes. This creates the appearance of fairness without the substance.

Metric gaming is also common. Teams may reset clocks, split cases, close and reopen work, or touch items superficially to avoid breaches. The design needs immutable timestamps and audit rules to prevent this.

Finally, old work may be stale. An aged item should not always be served exactly as originally requested. Revalidation may be needed before the system invests scarce capacity.

prose_neighbor_distinctions:
Queue Discipline Design is broader: it chooses the service-order rule. Queue Aging and Starvation Prevention is narrower: it adds an age-sensitive correction when the service-order rule risks indefinite neglect.

Priority-Based Admission governs what gets admitted or given access at the boundary. This archetype governs already-waiting items whose treatment must change because they have waited too long.

Backlog Visibility shows waiting work and age distributions. This archetype uses those signals to trigger priority change, escalation, protected capacity, or disposition.

Queue Expiration and Staleness Control handles old work that may no longer be valid. Starvation prevention handles valid work that should not be ignored. Many real systems need both: revalidate old items, then either serve, escalate, or cleanly dispose of them.

Work-in-Progress Limiting caps active work. Queue aging governs the waiting tail. A team may need WIP limits to improve completion flow and aging rules to ensure low-priority backlog items are not abandoned.

prose_cross_domain_examples:
In computing, a scheduler can raise the priority of processes that have waited too long. The point is not kindness; it is system integrity. A process that can be perpetually bypassed may never complete.

In customer support, critical incidents need priority, but low-severity tickets should not disappear forever. Aging thresholds can trigger review, priority boosts, or protected service blocks.

In healthcare, routine referrals may become more serious over time. Aging thresholds can trigger reassessment rather than allowing “routine” to mean “never.”

In public administration, benefits applications or permits may have statutory or policy windows. Aged cases can trigger supervisory review, remedy tracking, or explicit communication to applicants.

In manufacturing, rush orders can repeatedly displace ordinary work. An oldest-item sweep or protected capacity window can clear neglected work orders before they become chronic operational debt.

prose_non_examples: A plain FIFO queue is not this archetype when it already serves the oldest item next. A strict priority queue with no age correction is often the problem, not the solution. A dashboard that merely reports old items is visibility, not starvation prevention. A time-to-live policy that discards old messages is expiration, not anti-starvation. A one-time manager rescue of an old case is not the archetype unless it becomes a reusable rule.

prose_tradeoffs:
The main tradeoff is reduced strict priority. Some older lower-priority work will receive attention before some newer higher-priority work. That can feel inefficient or unfair to actors who define fairness solely by urgency or value.

The second tradeoff is complexity. Aging rules add thresholds, exceptions, audit logic, and communication burdens. They can also be gamed through timestamp manipulation, priority relabeling, or cosmetic updates.

The third tradeoff is exposure. Once maximum wait and age distribution are visible, the system can no longer pretend that all queued work is realistically serviceable. This is uncomfortable but often necessary.

prose_invariants_to_preserve:
The primary invariant is that valid queued work should not wait indefinitely without service, review, reclassification, or explicit disposition. The archetype does not promise instant service; it promises that waiting will eventually have consequences.

A second invariant is that risk remains meaningful. Age-sensitive rules should not force unsafe service order. Emergency, hazard, legal, or irreversible-harm cases may need protected precedence.

A third invariant is measurement integrity. Original waiting timestamps, pauses, resets, and reentries must be auditable. Otherwise the system can appear compliant while actually hiding starvation.

prose_target_outcomes:
The intended outcomes are lower tail wait times, fewer indefinitely neglected items, less complaint-driven rescue, greater procedural fairness, and clearer accountability. The design should make the oldest unresolved work visible and actionable.

It should also reduce pressure to game priority labels. When waiting itself eventually earns attention, actors have less reason to exaggerate urgency merely to escape a neglected queue.

In mature systems, aging data can reveal structural capacity or policy problems. If many items breach maximum waits, the issue is no longer an individual queue anomaly; it is evidence that the service model needs adjustment.

prose_parameter_dimensions:
Important tuning dimensions include the waiting-time start point, threshold values, aging curve shape, boost magnitude, maximum wait guarantee, class weights, escalation cadence, audit frequency, and reset policy. Designers must decide whether age accumulates continuously, in tiers, or only after a threshold.

The most sensitive parameter is the tradeoff between age and urgency. If age has too little force, starvation persists. If age has too much force, the system may create unsafe priority inversion. High-stakes queues often need protected emergency rules plus separate anti-starvation commitments for non-emergency work.

Another important dimension is whether the rule protects individuals or classes. Individual aging prevents old items from being ignored. Class-level aging or rotation prevents categories, regions, or groups from being systematically under-served even when individual items are not the oldest overall.

prose_variants_and_near_names:
Priority Aging Overlay is the common technical and operational variant: waiting time increases priority. Maximum Wait Guarantee Design is the commitment-oriented variant: after a defined wait, some action must happen. Deadline-Based Starvation Prevention uses latest-service deadlines to organize the queue. Class-Rotation Starvation Prevention protects groups or categories from being monopolized out of service capacity.

Near names include queue aging, starvation avoidance, priority aging, wait-time priority boost, maximum wait time, SLA escalation, and deadline queue. Several of these are mechanisms or parameters rather than archetypes. They are preserved as aliases or collapsed candidates so they do not become duplicate top-level drafts.

Priority Aging Overlay

short_definition: Aging metadata modifies an existing priority rule so items become harder to ignore the longer they wait.

distinctive_feature: It keeps the original priority discipline but adds a temporal correction layer.

distinct_from_parent: The parent includes several ways to prevent starvation; this variant specifically modifies priority scores as age increases.

still_same_parent_because: The causal purpose remains preventing indefinite waiting by making age change treatment.

source_primes: queueing threshold procedural_fairness

use_when: a priority queue repeatedly defers low-priority items

use_when: the system still needs priority distinctions but cannot allow indefinite neglect

use_when: waiting time can be measured reliably enough to drive reprioritization

domain: computing

example: Scheduler priority increases for processes that have waited too long.

domain: customer support

example: Low-severity tickets receive automatic priority bumps after defined aging thresholds.

failure_modes: priority inflation makes every old item urgent

failure_modes: aging boosts override genuinely critical new work

Maximum Wait Guarantee Design

short_definition: A queue policy sets an outer bound on waiting before service, review, escalation, or explicit disposition must occur.

distinctive_feature: It defines a latest acceptable action point rather than merely increasing priority gradually.

distinct_from_parent: The parent can use aging scores, rotations, or escalation; this variant centers the maximum-wait invariant.

still_same_parent_because: The intervention still prevents starvation by forcing treatment to change with waiting age.

use_when: the central harm is excessive tail waiting rather than average delay

use_when: service commitments, rights, or trust require a visible outer bound

use_when: some outcome other than immediate service can legitimately satisfy the guarantee

domain: public administration

example: Applications waiting beyond a statutory window receive supervisory review or a remedy path.

domain: healthcare

example: Routine referrals crossing a maximum wait threshold are escalated for reassessment.

failure_modes: guarantee is promised without capacity or remedy

failure_modes: threshold becomes a de facto target rather than an outer bound

failure_modes: the system closes or rejects cases merely to make metrics look compliant

Class-Rotation Starvation Prevention

short_definition: Service rotates among classes, queues, or groups so one class cannot consume all available capacity indefinitely.

distinctive_feature: The unit protected from starvation is a class, group, queue, or stratum rather than a single aged item.

distinct_from_parent: The parent can target individual item age; this subtype targets repeated group-level neglect through rotation or protected share.

still_same_parent_because: The intervention still ensures neglected work eventually receives attention instead of waiting indefinitely.

source_primes: queueing order procedural_fairness

use_when: starvation occurs at the class or group level rather than only at the item level

use_when: different queues or strata compete for the same service capacity

use_when: strict efficiency would let one category monopolize service

example_domains:
multi-class service queues
regional case allocation
shared platform support

domain: field service

example: A team reserves recurring capacity for remote regions that would otherwise always lose to dense urban requests.

domain: software support

example: A support group rotates attention across issue classes so complex but lower-volume categories are not abandoned.

failure_modes: class definitions become politically contested

failure_modes: protected shares hide underlying capacity shortages

Deadline-Based Starvation Prevention

short_definition: Queued items receive deadlines or latest-service dates that control ordering before waiting becomes unacceptable.

distinctive_feature: The main trigger is an explicit latest-service deadline rather than a general age score.

distinct_from_parent: The parent covers any age-sensitive anti-starvation intervention; this variant uses deadline ordering as the operational rule.

still_same_parent_because: Deadlines are one way to make waiting time alter queue treatment and prevent indefinite deferral.

source_primes: queueing threshold order

use_when: items have meaningful due dates or harm thresholds

use_when: tail waiting is more important than preserving strict priority order

use_when: deadline misses are easier to govern than continuous priority scores

domain: real-time systems

example: Tasks approaching deadlines are pulled forward to avoid indefinite blocking.

domain: casework

example: Cases approaching statutory deadlines move into an expedited review lane.

failure_modes: deadline gaming changes labels instead of improving service

failure_modes: deadline-only ordering neglects non-deadline harms

failure_modes: deadline pressure drives rushed low-quality service

near_names:
Queue Aging
Starvation Avoidance
Priority Aging
Wait-Time Priority Boost
Maximum Wait Time
SLA Escalation
Deadline Queue


Queue Discipline Design

Queue Discipline

notes: Names the chosen order rule; this archetype names the intervention of designing and governing that rule.

Service Order Policy

notes: Plain-language alias for the service-order policy at the center of the archetype.

Waiting Order Design

notes: Useful non-technical label for ordering waiting work or people.

source_primes: queueing order resource_management

related_primes: procedural_fairness scheduling constraint feedback

components:
Queue Membership Boundary
Service Order Rule
Eligibility and Readiness Test
Prioritization Criteria
Fairness Policy
Tie-Breaking Rule
Starvation Prevention Rule
Override and Exception Path
Backlog Visibility Signal
Service-Level Target
Audit and Appeal Path
Lane Partitioning Rule
Service-Time Estimate
Class or Actor Partition

mechanisms:
FIFO Queue
Priority Queue
Round-Robin Queue
Weighted Fair Queue
Shortest Job First
Deadline Queue
Aging Queue
Appointment Queue

essence_one_line: Choose and enforce a service-order rule so waiting work is handled according to fairness, urgency, efficiency, or risk rather than accidental arrival pressure.

compression_statement: When waiting work accumulates and service capacity is limited, define a queue discipline that governs who or what is served next, preserving fairness or system goals at the cost of rule complexity, measurement burden, and possible dissatisfaction from those moved later.

core_intuition: A queue already allocates delay. If the ordering rule is implicit, accidental, or manipulable, the system still has a policy, but it is hidden. Queue Discipline Design turns that hidden allocation into an explicit rule that can be explained, enforced, measured, and revised.

canonical_formula: waiting_set + scarce_service_point + explicit_order_rule + tie_breakers + anti_starvation_guardrails -> governed_service_sequence

structural_problem: A waiting set exists, service capacity is limited, and accidental or discretionary service order produces unfairness, inefficiency, starvation, unmanaged urgency, or risk.

trigger_conditions: Work, requests, people, cases, jobs, or packets wait for a constrained service point.

trigger_conditions: The order of service changes outcomes, legitimacy, safety, cost, or throughput.

trigger_conditions: Arrival order alone is either too arbitrary, too easy to game, or too blind to urgency and risk.

trigger_conditions: Operators are cherry-picking, improvising, or using inconsistent informal criteria.

trigger_conditions: Stakeholders need to understand why one waiting item was served before another.

symptoms: Frequent disputes over why one item moved ahead of another.

symptoms: Urgent items are buried behind routine work, or low-priority items wait indefinitely.

symptoms: Throughput varies because workers choose easy, visible, or politically salient items.

symptoms: Queue position becomes opaque, manipulable, or dependent on personal relationships.

symptoms: The system alternates between strict first-come-first-served rules and emergency overrides without a stable policy.

root_tension: Scarce service capacity requires ranking waiting items, but any ranking allocates delay, opportunity, and risk; the system must choose between simplicity, fairness, urgency, efficiency, and explainability.

anti_signatures: There is no meaningful waiting set because service capacity exceeds demand.

anti_signatures: The problem is excess inflow before entry rather than order among already waiting items; use rate limiting, priority-based admission, or load shedding instead.

anti_signatures: The key problem is only temporary absorption of bursts, with no meaningful order-of-service decision; use buffering instead.

anti_signatures: The system needs calendar allocation or demand smoothing over time, not next-item service order.

anti_signatures: Items are unsafe, invalid, or inappropriate to serve at all; admission, validation, or rejection must be designed before queue discipline.

structural_intervention: Define, communicate, and enforce an explicit service-order discipline for a waiting set, including eligibility, priority criteria, tie-breakers, exceptions, monitoring, and anti-starvation safeguards.

action_logic: Identify the waiting set, the constrained service point, and the moment at which the next item is selected.

action_logic: Name the service objective: procedural fairness, urgency response, risk reduction, average wait reduction, deadline protection, or balanced access across groups.

action_logic: Choose a queue discipline that matches the objective, such as FIFO, priority, round-robin, weighted fair service, shortest-job-first, deadline order, appointment order, or aging.

action_logic: Define eligibility tests, tie-breakers, exception paths, and override authority so the discipline is enforceable rather than aspirational.

action_logic: Instrument the queue for wait time, age distribution, service share, priority mix, bypass events, and complaints.

action_logic: Revise the discipline when measured outcomes reveal starvation, gaming, hidden inequity, or mismatch between the order rule and actual service goals.

condition: Items are similar and arrival order is a legitimate fairness proxy.

rule: Use FIFO or a close first-eligible-first-served discipline with clear tie-breaking.

condition: Items differ sharply in urgency, risk, or cost of delay.

rule: Use priority or deadline discipline, but add criteria transparency, review, and anti-starvation safeguards.

condition: Multiple groups share capacity and one group can dominate volume.

rule: Use rotation, class quotas, or weighted fair queueing rather than pure FIFO.

condition: Short jobs can be completed quickly but long jobs also matter.

rule: Use shortest-job or small-batch fast lanes only with aging, maximum-wait, or quota protections.

condition: The queue is safety-critical or rights-affecting.

rule: Require explicit justification, appeal or review paths, auditability, and bias monitoring.

invariant: The waiting set is legible.

why_it_matters: The system cannot govern order if it cannot tell who or what is waiting.

invariant: Service order follows declared rules except through declared exceptions.

why_it_matters: Hidden exceptions turn queue discipline back into discretionary favoritism.

invariant: No eligible class is silently starved.

why_it_matters: A discipline that maximizes one objective can still fail if some items never receive service.

invariant: Priority criteria are explainable and reviewable.

why_it_matters: Queue order allocates harm and opportunity, so opaque criteria damage legitimacy.

invariant: The order rule remains matched to the service objective.

why_it_matters: A rule chosen for simplicity, urgency, or efficiency can become harmful when conditions change.

outcome: Reduced arbitrariness

description: Actors can predict and inspect why items are served in a given order.

outcome: Improved fairness or legitimacy

description: Waiting becomes governed by a rule that can be defended rather than by accidental pressure.

outcome: Better response to urgency or risk

description: Items with higher harm from delay can move earlier without improvisation.

outcome: Higher throughput or lower average delay where appropriate

description: Disciplines such as shortest-job-first or batch fast lanes can reduce avoidable waiting when protected against starvation.

outcome: Lower conflict over service order

description: Explicit rules reduce disputes, appeals, and operator-level negotiation.

prose_essence:
Queue Discipline Design is the deliberate choice of **who or what gets served next** when a system cannot serve everything immediately. It is not the existence of a queue. It is the governance of the queue's order: the rule that converts a waiting set into a service sequence.

The core insight is that waiting is never neutral. When people, tasks, packets, applications, cases, or jobs wait, the system is already allocating delay. If the order rule is implicit, the allocation may be accidental, political, easy to game, or inconsistent across operators. This archetype makes the rule explicit enough to enforce, explain, measure, and revise.

prose_when_to_use:
Use this archetype when a waiting set exists, service capacity is scarce, and order of service affects fairness, urgency, risk, throughput, trust, or legitimacy. It is especially relevant when stakeholders ask why one item moved ahead of another, when urgent work is buried behind routine work, when easy work is cherry-picked, or when low-priority work waits indefinitely.

Do not reach for this archetype merely because a queue exists. If the main problem is excess inflow, use rate limiting, priority-based admission, or load shedding. If the main problem is temporary absorption of a burst, use buffering. If the main problem is changing demand timing, use load leveling or scheduling. Queue Discipline Design applies when the decisive intervention is **ordering admitted waiting items**.

prose_structural_problem:
The structural problem is a three-part pattern:

1. a set of eligible items is waiting;
2. a service point cannot handle all items at once;
3. the order of service changes outcomes.

When this structure is left unmanaged, order defaults to arrival pressure, convenience, visibility, informal privilege, or operator habit. That can produce avoidable harm: urgent items wait too long, quiet actors are ignored, easy work displaces important work, or stakeholders lose trust because order appears arbitrary.

The root tension is that every order rule privileges something. FIFO privileges arrival time. Priority rules privilege urgency, risk, value, or status. Shortest-job rules privilege throughput. Rotation privileges balanced attention. There is no order rule that is neutral for every purpose, so the system must choose and govern the principle it wants to preserve.

prose_intervention_logic:
The intervention begins by defining the waiting set and the exact service decision: when does the system choose the next item, and which items are eligible at that moment? It then chooses a discipline that matches the service objective.

For ordinary comparable work, the discipline might be FIFO. For safety-critical work, it may be triage priority. For shared capacity across groups, it may be round-robin or weighted fair service. For throughput under known service times, it may be shortest-job-first. For deadline-sensitive work, it may be time-to-breach. For priority queues that risk indefinite delay, it may add aging or maximum-wait guarantees.

A mature implementation does not stop at naming the rule. It also defines tie-breakers, exception paths, override authority, monitoring, and review. The rule should be stable enough to create expectations, but not so rigid that it fails under urgent or unusual cases.

prose_key_components:
### Queue Membership Boundary

The queue membership boundary defines who or what is in the waiting set. This matters because queue discipline only governs items that have entered the relevant waiting state. Without this boundary, the system confuses intake, admission, backlog, active work, and abandoned work.

### Service Order Rule

The service order rule is the heart of the archetype. It states how the next item is selected: first arrival, highest priority, nearest deadline, smallest job, rotation, class weight, aging, or another declared principle. The rule must be specific enough that different operators would usually make the same next-service decision.

### Eligibility and Readiness Test

An eligibility and readiness test prevents the queue from stalling on work that cannot actually be served. A file may be incomplete, a job may lack dependencies, a patient may need reassessment, or a request may require validation. Readiness is different from priority: an item can be important and still not yet serviceable.

### Prioritization Criteria

Prioritization criteria define which attributes legitimately move an item earlier or later. Common criteria include urgency, risk, deadline, service time, dependency impact, vulnerability, contractual obligation, or public value. The criteria should be explicit enough to reduce improvisation and gaming.

### Fairness Policy

The fairness policy states what fairness means in this queue. Fairness may mean first-come-first-served, equal rotation, proportional service shares, risk-sensitive priority, maximum waits, or transparent opportunity to appeal. The important point is to choose a fairness concept rather than smuggling one in through habit.

### Tie-Breaking Rule

A tie-breaking rule resolves equal claims under the main discipline. If two tickets have the same severity, two packets have the same class, or two applicants have the same deadline, the system needs a secondary rule. Otherwise, the most ambiguous cases become openings for favoritism.

### Starvation Prevention Rule

A starvation prevention rule protects items that might otherwise wait indefinitely. It can use aging, maximum-wait guarantees, quotas, periodic sweeps, or escalation. This component becomes essential when the main discipline prioritizes urgency, short jobs, high-value work, or high-volume classes.

### Override and Exception Path

The override and exception path defines when the normal discipline may be bypassed. Exceptions are often necessary, especially in safety-critical or humane systems, but they must be logged and reviewable. Unlogged exceptions are one of the fastest ways for a queue discipline to become arbitrary again.

prose_common_mechanisms:
### FIFO Queue

A FIFO queue implements first-in-first-out service. It is useful when items are comparable and arrival order is a legitimate fairness proxy. FIFO is simple and legible, but it can mishandle urgent work and can reward actors who are better able to arrive early.

### Priority Queue

A priority queue selects items by declared priority class or score. It implements the archetype when the system must serve higher-risk, more urgent, or more valuable items earlier. It becomes dangerous when priority labels are opaque, stale, or easy to manipulate.

### Round-Robin Queue

A round-robin queue rotates service across actors, classes, lanes, or groups. It is a mechanism for balanced attention. It works well when no group should monopolize capacity, but it can be too blunt when urgency differs sharply.

### Weighted Fair Queue

A weighted fair queue gives different classes different service shares while still preventing total domination by one class. It is useful when equal rotation is too flat but pure priority is too extreme. The hard part is governing the weights.

### Shortest Job First

Shortest-job-first serves items with lower estimated service time first. It can reduce average waiting time and clear small work quickly, but it can starve large or complex items. It should usually be paired with aging, quotas, or maximum-wait rules.

### Deadline Queue

A deadline queue orders items by due date, time-to-breach, or latest safe service time. It fits compliance, safety, and service-level contexts where missing a deadline changes the nature of the harm. It fails when deadlines are artificial or when undated work is important but invisible.

### Aging Queue

An aging queue raises priority or triggers escalation as waiting time grows. It is a mechanism for starvation prevention. It belongs under Queue Discipline Design when aging is one adjustment inside the service-order policy; it may become its own archetype when the whole intervention is about preventing indefinite waiting.

### Appointment Queue

An appointment queue reserves service order or service time without requiring continuous waiting. It can implement queue discipline when the appointment preserves a fair order. It may belong closer to Queue Reservation or Scheduling when the main intervention is time-slot allocation rather than next-item selection.

prose_failure_modes:
A queue discipline can fail through hidden priority capture, where powerful actors learn how to influence labels or exceptions. It can fail through starvation, where low-priority or large items never reach service. It can fail through criterion drift, where operators gradually reinterpret urgency, readiness, or priority.

It can also fail through gaming. If users learn that certain words, categories, or deadlines move them forward, they may reclassify work strategically. The mitigation is not always secrecy; it is better criteria, verification, sampling, and review.

Another failure mode is administrative overload. Some queues cannot support fine-grained triage. In those cases, a coarser discipline may be safer than a complex rule that nobody can apply consistently.

prose_neighbor_distinctions:
Queue Discipline Design is distinct from **Buffering** because buffering holds work while queue discipline orders service. It is distinct from **Backpressure** because backpressure tells upstream sources to slow down. It is distinct from **Rate Limiting** because rate limiting caps inflow. It is distinct from **Load Shedding** because load shedding rejects or drops work.

It is also distinct from **Priority-Based Admission**. Priority-Based Admission decides who enters the system; Queue Discipline Design decides who among the waiting admitted items is served next. The two can be combined, but they answer different questions.

It is distinct from **Scheduling** when scheduling assigns times and resources in advance. A queue discipline may use appointments as a mechanism, but its central question is the next-service rule for waiting items.

prose_cross_domain_examples:
In customer support, a team might serve critical outages first, then tickets near service-level breach, then FIFO within class. The queue discipline turns a vague ticket backlog into an explicit service sequence.

In computing, a scheduler might combine weighted fair queueing and aging so premium jobs receive higher share but ordinary jobs eventually run. The mechanism is technical, but the archetype is the same: choose and govern service order under constrained capacity.

In healthcare, triage uses clinical urgency rather than arrival order. The queue discipline is justified because the harm of waiting differs across patients.

In public administration, a permit office may order reviews by statutory deadline and submission date, while logging emergency exceptions. This makes backlog processing more defensible even when the backlog remains large.

In meetings, a facilitator may use a speaking queue that rotates toward unheard voices and permits urgent process interruptions. Attention is the scarce service point.

prose_non_examples:
A storage buffer that absorbs bursts without meaningful order consequences is not Queue Discipline Design. It is Buffering.

A request throttle that blocks excess requests before they enter a waiting state is not Queue Discipline Design. It is Rate Limiting.

A system that rejects low-value work entirely is not Queue Discipline Design. It is Priority-Based Admission or Load Shedding.

A team that simply adds more workers to a backlog is not Queue Discipline Design unless it also changes how waiting work is ordered. Capacity expansion and service-rate matching address a different part of the structure.

prose_tradeoffs:
The central tradeoff is fairness versus efficiency. FIFO is easy to defend, but it may waste capacity or delay urgent work. Shortest-job-first improves flow but may penalize complex cases. Priority rules respond to risk but may produce resentment or starvation.

A second tradeoff is simplicity versus fit. Simple rules are easier to communicate and enforce. Complex rules can represent reality better, but they require measurement, training, and oversight.

A third tradeoff is transparency versus gaming. Revealing criteria can improve legitimacy, but it also teaches actors how to jump the line. The right level of transparency depends on stakes, incentives, and whether classifications can be verified.

prose_invariants_to_preserve:
The first invariant is that the waiting set must remain legible. The system should know what is waiting, how long it has waited, and what class or priority it carries.

The second invariant is rule-governed order. Items may move ahead, but only through declared criteria or declared exceptions. Hidden movement destroys trust.

The third invariant is non-starvation. Even if the queue uses priority or efficiency rules, eligible items should not disappear indefinitely.

The fourth invariant is reviewability. High-stakes order decisions should leave enough trace that the system can explain, audit, and correct them.

prose_target_outcomes:
A successful queue discipline reduces arbitrary service order. It improves trust because users and operators can understand the basis of movement. It can improve safety by moving urgent items earlier, improve throughput by selecting work intelligently, and improve fairness by preventing quiet or low-power actors from being ignored.

The outcome is not necessarily a shorter queue. A queue can remain long because capacity is inadequate. Queue Discipline Design makes the allocation of service order more legitimate and better matched to purpose; it does not by itself create capacity.

prose_parameter_dimensions:
The most important tuning dimension is the **discipline type**: FIFO, priority, rotation, weighted fair service, deadline order, shortest-job-first, appointment order, or aging. This choice should follow the service objective rather than habit.

Other important parameters include priority weights, aging rate, maximum-wait threshold, bypass threshold, tie-breaking order, visibility level, and review cadence. Each parameter changes the burden of waiting. For example, a strong priority weight improves urgent response but can starve routine work; a low maximum-wait threshold improves fairness but may weaken the meaning of priority.

The review cadence is a hidden but crucial parameter. Queue disciplines drift as demand, staffing, incentives, and user behavior change. A rule that was fair under one demand mix can become unfair under another.

prose_variants_and_near_names:
The main variants are FIFO discipline, priority queue discipline, round-robin or rotation discipline, weighted fair queue discipline, shortest-job-first discipline, deadline-driven discipline, and aging or escalating discipline.

Near names include queue discipline, service order policy, service order rule, waiting order design, line management, and scheduling policy. The first four usually point back to this archetype. Scheduling policy is a cautionary near-name: it points here only when it means ordering waiting items, not assigning calendar slots.

Several roadmap names should collapse into mechanisms or variants rather than become separate archetypes here: FIFO queue, priority queue, round-robin queue, weighted fair queue, shortest-job-first, deadline queue, and token queue. Queue Aging and Starvation Prevention should not be collapsed yet; it remains a strong promoted candidate because starvation prevention has its own problem signature and components.

FIFO Queue Discipline

short_definition: Serve the earliest eligible waiting item first, making arrival order the default fairness rule.

distinctive_feature: The decisive ordering criterion is eligible arrival sequence.

distinct_from_parent: The parent archetype chooses and governs any service-order rule; this variant chooses first-eligible-arrival as the rule.

still_same_parent_because: FIFO is one discipline choice inside the broader act of designing queue order.

use_when: Items are broadly comparable in urgency, cost, and service time.

use_when: Arrival order is considered a legitimate proxy for fairness.

use_when: The system needs a simple, transparent order rule that users can understand.

Queue Membership Boundary

role: Defines who has entered the FIFO line.

Tie-Breaking Rule

role: Resolves simultaneous arrivals without ad hoc discretion.

Numbered Ticket

role: Records sequence position.

Timestamp Ordering

role: Uses recorded entry time as ordering evidence.

example_domains:
retail service counters
help-desk intake
document processing

domain: Public service

example: Applicants are handled in timestamp order after basic eligibility is confirmed.

domain: Computing

example: A worker consumes tasks from the front of a first-in-first-out task queue.

failure_modes: Urgent or high-risk items can be delayed behind routine items.

failure_modes: Actors may rush to enter early even when later classification would be better.

Priority Queue Discipline

short_definition: Serve waiting items according to a declared priority ranking rather than raw arrival order.

distinctive_feature: Priority attributes override or modify arrival sequence.

distinct_from_parent: The parent covers all service-order choices; this variant centers priority ranking as the dominant discipline.

still_same_parent_because: The intervention remains the selection and enforcement of order among waiting items.

use_when: Items differ in urgency, risk, cost of delay, value, or service obligation.

use_when: Strict arrival order would create avoidable harm or inefficiency.

use_when: Priority criteria can be made explicit enough to govern and audit.

Prioritization Criteria

role: Defines which attributes change service order.

Fairness Policy

role: Constrains priority so it does not become arbitrary privilege.

Priority Queue

role: Stores items by rank or priority class.

Triage Matrix

role: Maps urgency and severity to service class.

example_domains:
clinical triage
incident response
customer support

domain: Emergency care

example: Patients with life-threatening signs are served before routine cases.

domain: Operations

example: Security incidents outrank routine maintenance tickets.

failure_modes: Low-priority items may starve if aging or maximum-wait guarantees are absent.

failure_modes: Priority labels may be gamed unless criteria and review are enforced.

Round-Robin or Rotation Discipline

short_definition: Rotate service among actors, queues, classes, or regions so no one constituency monopolizes capacity.

distinctive_feature: The service rule cycles across groups or classes rather than ranking individual items alone.

distinct_from_parent: The parent may use many order principles; this variant uses cyclical turn-taking as the ordering principle.

still_same_parent_because: Rotation still implements a queue discipline: it decides who is served next.

use_when: Multiple groups share a scarce service point.

use_when: A single dominant group could consume all available service.

use_when: Equal or cyclic attention is more legitimate than pure speed or priority.

Fairness Policy

role: Defines what fair rotation means.

Class or Actor Partition

role: Names the groups among which service rotates.

Round-Robin Queue

role: Cycles through queues or actors.

Service Cycle

role: Allocates recurring turns to groups.

example_domains:
network scheduling
committee speaking order
shared support teams

domain: Network systems

example: Packets from multiple flows are served in a rotating sequence.

domain: Governance

example: Regions receive alternating hearing slots so the largest region does not consume every meeting.

failure_modes: Strict rotation may ignore urgent differences.

failure_modes: Groups may be badly defined, producing artificial fairness.

Weighted Fair Queue Discipline

short_definition: Distribute service across classes according to declared weights while still preventing total domination by one class.

distinctive_feature: The discipline combines class fairness with explicit service weights.

distinct_from_parent: The parent does not require weighting; this variant makes service-share weights central.

still_same_parent_because: The weights operationalize a service-order policy rather than constituting a separate intervention family.

use_when: Different classes deserve unequal but bounded service shares.

use_when: Pure FIFO would let high-volume classes dominate.

use_when: Pure priority would over-serve one class or starve another.

Priority Weight

role: Specifies relative service share.

Fairness Policy

role: Constrains weights against domination or hidden privilege.

Weighted Fair Queue

role: Implements class-weighted service rotation.

Quota Cycle

role: Allocates recurring service slots by weight.

example_domains:
computer networking
case management
portfolio review

domain: Infrastructure

example: Different traffic classes receive weighted shares of processing capacity.

domain: Service operations

example: A review board alternates among project categories but gives safety-critical cases more slots.

failure_modes: Weights can encode unjustified privilege.

failure_modes: Weights may become stale as demand and harm profiles change.

Shortest-Job-First Discipline

short_definition: Serve smaller or faster-to-complete items first to improve throughput or reduce average waiting time.

distinctive_feature: Estimated service duration becomes the order criterion.

distinct_from_parent: The parent can optimize for fairness, urgency, or risk; this variant optimizes around task size or completion time.

still_same_parent_because: It is a discipline choice for waiting work, not a separate structural pattern.

use_when: Service time can be estimated with reasonable accuracy.

use_when: Throughput or average delay matters more than strict arrival order.

use_when: Long jobs are protected from indefinite deferral by separate rules.

Service-Time Estimate

role: Predicts the processing burden of each item.

Starvation Prevention Rule

role: Keeps long jobs from waiting indefinitely.

Shortest Job First

role: Orders by estimated job length.

Small-Batch Fast Lane

role: Moves quick work through a distinct service path.

example_domains:
manufacturing dispatch
software job scheduling
administrative processing

example: A team clears short routine approvals before long complex reviews during a backlog surge.

example: Batch jobs with short estimated runtimes are executed before large jobs.

failure_modes: Large or complex items can be chronically postponed.

failure_modes: Bad duration estimates can invert the intended efficiency gain.

Deadline-Driven Queue Discipline

short_definition: Order waiting work by due dates, latest safe service time, or time-to-breach rather than by raw arrival.

distinctive_feature: Time-to-deadline is the governing order signal.

distinct_from_parent: The parent does not require deadlines; this variant makes deadline pressure the dominant ordering dimension.

still_same_parent_because: It still chooses a service-order discipline for waiting items.

source_primes: queueing order threshold

use_when: Items have real deadlines, expiration points, or harm thresholds.

use_when: Missing a deadline has consequences different from ordinary delay.

use_when: Deadline evidence is reliable enough to govern order.

Service-Level Target

role: Defines the relevant deadline or breach point.

Bypass Threshold

role: Allows items nearing breach to move ahead.

Deadline Queue

role: Orders items by due date or time-to-breach.

SLA Escalation

role: Raises priority as a deadline approaches.

example_domains:
legal filing
medical follow-up
maintenance scheduling

domain: Compliance

example: Filings near statutory deadlines move ahead of less time-sensitive paperwork.

domain: Support

example: Tickets close to service-level breach are escalated in the service order.

failure_modes: Artificial deadlines can displace genuinely important but undated work.

failure_modes: Repeated deadline escalation can recreate priority inflation.

Aging or Escalating Queue Discipline

short_definition: Increase priority, trigger escalation, or guarantee service as waiting time grows.

distinctive_feature: Waiting time changes an item's treatment over time.

distinct_from_parent: The parent chooses a queue discipline; this variant governs how the discipline changes as items age.

still_same_parent_because: It still implements a service-order rule, but it is strong enough to remain a promoted archetype candidate.

source_primes: queueing order threshold procedural_fairness

use_when: A priority or efficiency-oriented queue risks starving low-priority items.

use_when: Maximum acceptable waiting time can be defined.

use_when: The system needs fairness repair without abandoning priority entirely.

Age Threshold

role: Defines when waiting time changes priority.

Starvation Prevention Rule

role: Prevents indefinite waiting.

Priority Aging

role: Gradually raises priority with wait time.

Maximum-Wait Guarantee

role: Requires intervention before a wait limit is exceeded.

example_domains:
operating systems
support operations
benefits processing

example: A low-priority process gains priority the longer it waits.

domain: Public administration

example: Cases that exceed a maximum wait are escalated for review.

failure_modes: Aging can erase justified priority if thresholds are too aggressive.

failure_modes: Escalation can overload senior reviewers or exception queues.

near_names:
Queue Discipline
Service Order Policy
Service Order Rule
Waiting Order Design
Line Management
Scheduling Policy