---
slug: correlated_release_capacity_overwhelm
name: Correlated Release Capacity Overwhelm
one_liner: "A population of independent units held in a waiting state is released nearly simultaneously by a single shared signal and collides at once on a finite downstream resource, so the failure lives in the correlated timing of release rather than in the population size or the resource's steady-state capacity."
type: prime
schema_version: 2
status: density_v2_draft
categories: [structural, computational, economic]
origin_domain: distributed_systems
alternate_origin_domains: [operations_and_queueing, economics_and_finance, ecology]
aliases: [synchronized_demand_spike, correlated_wakeup_storm, shared_signal_stampede, release_synchronization_overload]
related: []
solution_archetypes: []
review_flags:
- "OPERATOR-DERIVED (op-05 generalization) — the proposed GENUS of `thundering_herd` (lift: strip the distributed-systems / process-scheduling frame from the waiters and the shared resource, leaving a bare population-released-by-shared-signal-onto-finite-capacity structure). Discovered in the op-05 remaining-strata sweep 2026-07-03. Tier B candidate. STATUS: HOLD pending owner keep/cut. COINAGE RISK: bespoke genus label minted for a single input — no established cross-domain name is asserted; keep-rate for Tier-B coinages is expected to be low."
- "Created 2026-07-03; STUB ONLY (frontmatter + Core Idea + Notes). SI/SF/similarity are PROPOSER ESTIMATES pending triangulation. Body sections (Structural Signature onward) NOT written."
- "Phase-C action: re-similarity-check vs `thundering_herd` (the input) and `load_balancing`, `bottleneck`, and any `bank_run` / `herd_behavior` / `synchronization` prime; confirm it is a genuine genus (covers thundering_herd AND the crowd-surge / ticket-flood / bank-run siblings) and is not a mere restatement of thundering_herd or a domain instance of a general contention/bottleneck prime; draw a subsumption edge thundering_herd→candidate + sibling edges at incorporation; sync one_liner to a v1 draft per CLAUDE.md before merge."
substrate_independence:
  composite_substrate_independence: 4
  domain_breadth: 4
  structural_abstraction: 4
  transfer_evidence: 3
  reasoning: 'The bare structure — a set of independent units parked in a held-back state, a single shared signal that releases them with near-simultaneous timing, and a finite downstream resource sized for steady-state that cannot absorb the synchronized spike — is medium-neutral: it needs only "units," "a common release trigger," and "a shared capacity-limited sink," none of which presuppose software, markets, or organisms. This scores higher than its framed input `thundering_herd` (which carries process/kernel-scheduling vocabulary), consistent with the expectation that a generalization lift out-scores its framed source on substrate-independence. Domain breadth is genuine (queues, retail crowds, ticketing servers, bank runs, mast-seeding ecology). It is held off a 5 because the pattern still leans on an operational notion of "capacity" and "demand," and because the transfer evidence is currently proposer-asserted from siblings rather than triangulated — hence transfer_evidence 3 and a composite of 4.'
similarity_to_nearest_existing_prime:
  slug: thundering_herd
  similarity: 0.72
structural_framed:
  label: structural
  aggregate: 0.24
  criteria: {vocab_travels: 0.85, evaluative_weight: 0.1, institutional_origin: 0.2, human_practice_bound: 0.15, import_vs_recognize: 0.3}
  rationale: 'Once lifted out of the distributed-systems frame the pattern reads as a bare timing-and-capacity structure: its vocabulary (held-back units, shared release signal, finite sink, correlated timing) travels cleanly across queues, crowds, markets, and ecology, and it carries almost no evaluative or normative content — a synchronized spike is a structural fact, not a value judgment. It has no institutional home and is recognized as a shape rather than imported as a doctrine. The residual framing is the operational "capacity/demand" idiom, which keeps import_vs_recognize and institutional_origin slightly off the floor. Net: clearly structural, aggregate low.'
phase_b_passes_completed: []
---
# Correlated Release Capacity Overwhelm

## Core Idea

Correlated Release Capacity Overwhelm is the bare structure in which *a population of independent units, each held in a waiting state, is released at nearly the same instant by a single shared signal and immediately competes for a finite downstream resource that was sized for steady-state demand and cannot absorb the synchronized spike*. The one constraint stripped to reach it from the input `thundering_herd` is the **distributed-systems / process-scheduling frame**: thundering_herd names this pattern for OS processes or clients woken by a single event and contending for a lock, socket, or backend; drop the software substrate and the same shape is left over — units, a common release trigger, and a shared capacity-limited sink. What makes the genus a genus rather than a restatement is that the failure is located precisely in the *correlation of timing*, not in the number of units or the size of the resource: the very same population, arriving spread out, would be served without incident.

The load-bearing anatomy is three parts. First, a *held-back population* — many units each independently ready to act but currently blocked, queued, or waiting on a precondition. Second, a *shared release signal* — one event that unblocks all of them at once, converting independent latent demand into a single synchronized wave; the correlation is imposed externally, not chosen by the units. Third, a *finite downstream resource sized for the average, not the peak* — a sink whose steady-state capacity is exceeded by the instantaneous spike, so that service degrades, queues explode, or the resource fails outright. The characteristic payoff of arranging systems this way is efficiency under normal load: sizing for the average rather than the worst case is cheap, and holding units back until a trigger is a natural way to batch or gate work. The characteristic cost is exactly the correlated-timing failure — a rare or engineered synchronizing event turns cheap average-case provisioning into a collapse, and the standard remedies all attack the *correlation* (jitter, staggered release, randomized backoff, admission control) rather than the population or the capacity.

Read structurally, the same move recurs far outside computing. A *Black Friday doorbuster* holds a crowd behind locked doors and releases the entire population through one entrance at a single announced opening time, overwhelming aisles and checkout sized for ordinary footfall. A *concert on-sale* parks thousands of buyers refreshing a page until a single publicized on-sale instant releases them all onto a ticketing server provisioned for normal traffic, which floods. A *bank run* is the same skeleton in finance: depositors who would ordinarily withdraw independently over time are released by one shared rumor to demand their money at once, overwhelming a reserve sized for steady-state withdrawal. Each of these is a structurally-unlike species — crowds, web requests, deposits — yet all share the identical anatomy of held-back population, shared signal, and finite sink, which is what the lift is meant to capture and what `thundering_herd` alone (bound to processes and locks) does not name.

## Notes

**Provenance.** Produced by operator 05 (generalization / lift) as the proposed genus of the input `thundering_herd`, by stripping the distributed-systems / process-scheduling frame to expose a bare correlated-release-onto-finite-capacity structure. Surfaced in the op-05 remaining-strata sweep on 2026-07-03. Claimed siblings: Black Friday doorbuster crowd surges, concert ticket-sale server floods, and rumor-triggered bank runs. Recorded as a **Tier B (B-rest)** candidate in the op-05 manifest.

**For owner evaluation (keep/cut).** The case FOR: the genus does real work that the input cannot, because `thundering_herd` is lexically bound to processes/clients and locks/backends, whereas the crowd-surge, ticket-flood, and bank-run siblings are plainly the same shape in non-software substrates; the pattern's *diagnosis and remedy both live in the timing correlation*, which is a genuinely portable structural insight (the fix is always de-correlate the release, never resize the population). The RISKS, stated plainly: (1) **Coinage, not an established genus.** "Correlated Release Capacity Overwhelm" is a sonnet-minted label for a single input; there is no widely-used cross-domain name for it, so Kurt is being asked to bless a coinage, and Tier-B coinages keep at a low rate. (2) **Restatement risk.** The similarity to `thundering_herd` is high (~0.72) — the danger is that this is thundering_herd with the software nouns filed off rather than a strictly broader genus. The discriminator: does the corpus want thundering_herd to *remain the software species* under a domain-neutral parent, or is thundering_herd already being used domain-neutrally in practice (in which case the candidate is a rename/alias, not a genus)? (3) **Alias/collapse into a bottleneck or contention prime.** It must not fold into `bottleneck` or `load_balancing` — those concern a persistent capacity constraint or its remedy, whereas this prime is specifically about a *transient synchronized spike caused by a shared release signal*; the correlated-timing origin is the whole point and is absent from a generic bottleneck. It should also not be swallowed by a general `herd_behavior` / `information_cascade` prime, which concerns *why* units decide alike, not the capacity collapse their synchronized action causes. The sharp keep/cut question for Kurt: **is the "shared-signal-synchronized spike onto finite capacity" structure a genuinely broader parent worth a slot of its own, or is it (a) thundering_herd already sitting at the right level of abstraction, or (b) a special case of an existing bottleneck/contention prime?**

**At incorporation.** Re-run similarity against `thundering_herd` (input), `load_balancing`, `bottleneck`, and any `bank_run`, `herd_behavior`/`information_cascade`, or `synchronization` prime to confirm no collapse. If kept, draw a subsumption edge `thundering_herd`→`correlated_release_capacity_overwhelm` and sibling/instance edges from the candidate to the crowd-surge, ticket-flood, and bank-run species (or to whatever existing primes cover them). Note any missing edge if a `bank_run`-type prime already exists but is not yet linked as a downstream instance. Write a v1 draft and sync the one_liner across v1 and v2 per CLAUDE.md before merge.
