Capacity Pool¶

Governed shared-reserve institution — instantiates Slack Capacity Design

Aggregates slack from many units into one governed reserve that a steward allocates to wherever uncertainty actually lands, instead of each unit hoarding its own.

Capacity Pool replaces many small local reserves with one shared, centrally governed reserve. Its defining insight is statistical: because independent units rarely spike at the same moment, a single pooled reserve can cover them all with far less total capacity than the sum of their private cushions — the pooling principle. But aggregation only works if the pool is governed: it needs a steward who allocates it to wherever uncertainty actually materialized and defends it against the unit that would like to quietly annex it. Allocating one reserve across competing claims is what forces the opportunity cost of each use into the open, which fragmented local buffers never do.

Example¶

A platform team supports eight product teams, each of which used to hold its own ~20% compute headroom "just in case" — most of it idle most of the time. They consolidate it: one central reserve of roughly 15% of total capacity, held by the platform team and allocated by a named steward when a product team's load actually spikes. Because the eight teams' spikes are largely uncorrelated, the pooled 15% covers surges that the fragmented 20%-each never coordinated — aggregate idle capacity falls and surge coverage improves. When two teams request the reserve at once, the steward arbitrates, and that arbitration makes the real trade-off — whose work waits — explicit for the first time. (The gain is the standard risk-pooling result.^[1])

How it works¶

Three features distinguish it: aggregation (many units' slack combined so the pool needs less total reserve for the same coverage), a steward who allocates the pool and protects its system-level purpose against local capture, and cross-unit allocation that pits competing claims against each other and thereby surfaces opportunity cost. It is the coordination-and-governance layer over slack, not a particular flavor of reserve.

Tuning parameters¶

Pool breadth — how many units contribute. A wider pool smooths more but weakens each unit's felt ownership of "its" reserve.
Governance model — fully central versus federated. Central maximizes pooling benefit; federated preserves local responsiveness.
Allocation rule — first-come, priority ranking, or internal bidding; each shapes who tends to win the reserve.
Reserve fraction — how large the pool is relative to combined demand.

When it helps, and when it misleads¶

It helps most when many units each carry correlated-but-idle local slack that pooling could shrink while improving coverage — the classic waste of fragmented reserves. Its critical assumption is that demand is uncorrelated: when a common shock hits every unit at once, the pool is overwhelmed exactly when all of them need it, so pooling is no substitute for reserve against systemic events. The other failure is political — a shared pool is a prize, and without an independent steward it drifts toward whoever lobbies hardest. The classic misuse is a "pool" that is really one dominant unit's reserve rebranded. The discipline is steward independence plus watching demand correlation, not just pool size.

How it implements the components¶

protected_capacity — the aggregated central reserve is the protected capacity, now held once instead of many times.
slack_steward — it institutes the accountable role that allocates, defends, and replenishes the pool against local demands and capture.
opportunity_cost_review — every cross-unit allocation forces an explicit comparison of competing claims and of holding versus releasing the reserve.

It does not implement the visibility components utilization_ceiling, slack_visibility_metric, or slack_erosion_guardrail — those are Utilization Ceiling Dashboard — and it is not the standing staffing float of Reserve Staffing.

Instantiates: Slack Capacity Design — Capacity Pool is the aggregation-and-governance layer that keeps slack from fragmenting into idle local cushions.
Consumes: the unit-level reserves it aggregates, such as Reserve Staffing or Buffer Resources, where those are pooled rather than held locally.
Sibling mechanisms: Reserve Staffing · Utilization Ceiling Dashboard · Innovation Time · Maintenance Window · Buffer Resources · Learning Time · Schedule Slack · Slack Release Review · Surge Roster · Unallocated Budget · Emergency Reserve

References¶

[1] The pooling principle (or risk pooling) — combining independent demand streams into one reserve reduces the total capacity needed for a given service level, because variability across independent sources partly cancels and scales sub-linearly. It is why one shared reserve beats many private ones, and why correlated demand erases the advantage. ↩