Substrate Capacity Budget¶
Document — instantiates Displacement-Aware Capacity Admission
A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve.
An inventory tells you who is on the substrate; a budget tells you how much substrate there actually is to give — and how little of what looks free really is. Substrate Capacity Budget is the accounting document that partitions total capacity into named tranches: what is committed to protected floors, what is genuine discretionary slack an entrant could draw on, what is set aside as a phase-in allowance for staged admission, and what is held back as an emergency reserve that is never handed out at all. Its defining move is to subtract before it offers: the number an entrant is allowed to claim is not total capacity minus current use, but total capacity minus floors minus reserve minus the buffer that keeps quality from degrading under load. It converts "there's plenty of room" into a line-itemed statement of exactly how much room, and of what kind.
Example¶
A platform engineering team runs a shared GPU cluster — call it 400 accelerators — that a dozen internal teams train models on. A new recommendation-systems group asks to onboard a large continuous-training job and points at the cluster's average utilization, which sits around 62%, as proof there is ample headroom. The team writes a Substrate Capacity Budget instead of arguing from the average. Total capacity is 400 GPUs. The reserved floor is the block the two latency-critical inference-adjacent training jobs must always have — 120 GPUs, non-negotiable, because dropping below it breaks a product SLA. The emergency reserve is 40 GPUs held for incident-response retraining, never allocated in steady state. A phase-in allowance of 30 GPUs is carved out for onboarding new workloads gradually.
That leaves discretionary slack of 400 − 120 − 40 = 240, against a peak draw (not average) of roughly 210 during the daily 9 a.m. crunch — so real steady-state slack is closer to 30 GPUs, not the 150 the utilization average implied. The budget shows, on one page, that the recommendation job's request of 80 GPUs cannot fit in slack without either eating the phase-in allowance, breaching a floor, or degrading everyone at peak. The average said yes; the budget said the honest number is 30, and the rest is buffer that only looks free because it is idle most of the day.
How it works¶
The budget's distinguishing discipline is that slack is a residual, computed last, after every protected and reserved claim is subtracted:
- State total capacity in the register's unit. One number, one unit, reconciled to Incumbent Use Register.
- Book the floors first. Reserved capacity for protected functions comes off the top and is not available to any entrant, by construction.
- Set aside reserve and phase-in tranches. An emergency reserve held against shocks, and a phase-in allowance dedicated to staged onboarding, are named separately so they cannot be quietly spent as if they were slack.
- Compute slack against peak, not average. Discretionary slack is what remains after floors and reserves, measured at realistic peak strain — because the average hides the moment the substrate is actually full.
The result is a partitioned statement other mechanisms treat as the capacity ground-truth.
Tuning parameters¶
- Reserve fraction — how much capacity is withheld as emergency reserve. A larger reserve absorbs shocks but shrinks what entrants can ever use; too small and the substrate has no recovery margin.
- Peak definition — whether slack is computed against the daily peak, the 95th-percentile load, or the worst observed spike. Stricter peaks protect quality but ration harder.
- Phase-in allowance size — how much capacity is earmarked for gradual onboarding. Generous allowance smooths staged admission; stingy allowance forces entrants to compete with incumbents immediately.
- Degradation buffer — the headroom kept between committed load and total, reflecting that quality degrades before capacity is literally exhausted.[n1] Wider buffers protect service levels at the cost of apparent utilization.
When it helps, and when it misleads¶
Its strength is that it kills the average-utilization mirage — the single most common way an entrant's "unused slack" claim launders a buffer, reserve, or peak-hour margin into free space. By booking floors first and computing slack as a residual against peak, it makes over-commitment a visible arithmetic error rather than a surprise brownout.
Its failure mode is false precision about a substrate whose capacity is not actually a fixed number. Treating 400 GPUs (or acre-feet, or shelf-facings) as a hard ceiling ignores that effective capacity varies with contention, weather, or interference; a budget that looks exact can license admission right up to a line that was always fuzzy. It can also be gamed by shrinking the reserve or redefining the peak downward to manufacture slack that isn't there. The guarding discipline is to state the buffer and reserve explicitly, hold them against pressure to "just use the headroom this once," and version the budget so that a quietly loosened reserve leaves a trail. The budget states capacity and floors; it does not decide who gets admitted — that is a rule, not a document.
How it implements the components¶
The budget is a capacity-accounting document filling exactly two components:
capacity_budget_and_slack_estimate— its core output: total capacity partitioned into floors, reserve, phase-in allowance, and residual slack computed against peak load.protected_function_floor— books the reserved level for protected functions off the top as a named line item, so the floor is a quantity on the page, not an aspiration.
It does not turn the floor into an enforced admission decision — writing "admit only if it fits outside the reserve" as a standing rule is Capacity Reservation Rule; the budget only states the numbers. It does not enumerate incumbent_use_baseline — that is Incumbent Use Register — nor estimate displacement_elasticity_estimate, which belongs to Displacement Impact Assessment.
Related¶
- Instantiates: Displacement-Aware Capacity Admission — the budget supplies the capacity-and-slack ground-truth the admission decision depends on.
- Consumes: Incumbent Use Register supplies the substrate definition and the uses whose floors get booked.
- Sibling mechanisms: Incumbent Use Register · Displacement Impact Assessment · Shadow Displacement Accounting · Capacity Reservation Rule · Moratorium and Reversal Gate · Offset or Relocation Plan · Phased Admission Trial · Crowding-Out Monitoring Dashboard
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Substrate Capacity Budget operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve.
Independent corroboration: The frozen evidence defines Substrate Capacity Budget as 'A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve', so its operative form is Representation, Specification & Plan.
Nearest alternative: Decision, Gate & Allocation — Substrate Capacity Budget includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Allocating a finite receiving or processing substrate among competing loads while reserving headroom is capacity planning and queueing. NIST queueing theory relates arrival load, service capacity, utilization, and delay; engineering and ecology supply domain-specific substrate constraints.
Related originating lineages:
- Engineering & Design — engineering_design contributes engineering design, reliability, and systems-safety practice to this mechanism's defining operation—A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve—without displacing the selected primary historical lineage.
- Environmental Science & Climate Studies — environmental_climate contributes environmental monitoring and sustainability science to this mechanism's defining operation—A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve—without displacing the selected primary historical lineage.
- Logistics & Supply Chain Management — logistics_supply_chain contributes logistics, inventory, and supply-chain operations to this mechanism's defining operation—A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve—without displacing the selected primary historical lineage.
- Mathematics — Mathematical modeling, proof, and abstract-structure practice supplies a parallel or contributing lineage for the mechanism's defining operation: a budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve.
- Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: a budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve.
- Systems Thinking & Cybernetics — Reserve and slack protect system viability under disturbance.
Review resolution: The blind reviewers disagree on primary lineage (engineering_design versus operations_research). Authoritative or primary research supports operations_research as the best historical origin: Allocating a finite receiving or processing substrate among competing loads while reserving headroom is capacity planning and queueing. NIST queueing theory relates arrival load, service capacity, utilization, and delay; engineering and ecology supply domain-specific substrate constraints. The cited NIST, Quantitative Methods for Management: Queueing Theory directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=universal records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] In capacity planning, headroom (often formalized as N+1 or N+2 redundancy) is the deliberate margin kept between committed load and maximum capacity, because latency, error rates, and quality degrade well before a resource is literally full. Slack computed without a headroom buffer systematically overstates what is safe to allocate. ↩