The Capacity
Planning Practice

61 figures

The visual tour

Every figure in the paper, in order, with its caption. The figures and captions are built to carry the argument on their own; each links to its place in the full reading.

Executive summary

Summary card. Forecast 500,000 vs actual 480,000 requests per second, within 4%; bill $525,600 planned vs $683,280 actual, 30% over. The overrun splits into volume −$21,024 (product team), coefficient +$126,144 (shared service) and rate +$52,560 (service owner, with finance); the last two exceed the whole overrun. Second miss: approved as 4 units, needed 4.8, machines a quarter late. Invented numbers.
Figure 1. The same invented year-end review, two ways it missed: a bill 30% over a forecast within 4%, split by who moved each piece, and an approval that needed more machines, later, than it bought. In context: Executive summaryOpen full size: Figure 1
Concept map. At the top, the problem: a forecast within 4% and a bill 30% over, and an approval with no usable machines. Two pillars follow. A coefficient is an agreement: owned, versioned, restated, with launches entering as declarations that firm up in stages (Section 5). Approval is not allocation: the gap in shape, place and time needs an owner and a ledger, and supply runs on its own clock under contracts and slips in steps (Section 6). Both feed the commit-point method (Section 8), which writes into mechanisms 12 and 13 of the thirteen-mechanism operating discipline (Section 9). Three prices answer three questions (Section 4). A strip lists the newcomer path: Sections 1, 2, 4, 5.2, 5.4, 6.5, 7, 8 and 14. A footer says it is a practitioner synthesis and the method is untested (Section 13).
Figure 2. Two claims and one method, resting on an operating discipline and a clear answer to "which price?". Section numbers show where each is argued. In context: Executive summaryOpen full size: Figure 2

One page

Flowchart for one declaration. Step 1 lists every supply layer with a usual and a cautious lead time. Step 2 works back from launch: each need date is the next layer's start, and each commit point is the need date minus the cautious lead time. For each layer, slowest first, a diamond asks whether any declaration exists at the commit point. If not, the portfolio envelope serves the layer and the launch's claim is recorded. If so, step 3 reads the stage and the range still open. A second diamond asks whether the attribute that drives the layer is known by then. If not, the planner picks one of three choices (ask earlier, buy an option past the event, or commit to the stage's record and name the owner of the residual) and writes a decision note. Steps 4 to 8 follow: cover up the range by the shortage-to-idle ratio, net against what's on hand, on order, due back and retiring, split into firm, flexible and named, agree change bands, and write it down in four artifacts. A final diamond takes supply's answer, and either branch makes the approval capped issue: a dated commit makes it firm; a named gap is capped issue with the gap named and a bridge owned, with an owner and a ready-by date. A loop back says each stage move is checked against its band; outside the band is a priced event.
Figure 3. The commit-point method for one launch. Two questions decide the path at each layer: does a declaration exist yet, and is what drives this layer known by its commit point? Every path ends in a written answer from supply, and either answer makes the approval capped issue. A way to think it through, not a model; the method is untested (Section 13). In context: One pageOpen full size: Figure 3

Section 1 · Introduction: a close forecast and a wide miss

Equation card: cost equals volume times coefficient times rate. Volume is owned by the product team and moves with its product. The coefficient is owned by the shared service and moves with code, cache behavior, request mix, data size and hardware. The rate is owned by the service owner with finance and moves with its cost structure. Example: 0.4 calls at 2.5 ms gives 1.0 ms per request, at $0.12 per busy core-hour. Illustrative numbers.
Figure 4. The bill multiplies three numbers. The team that forecasts its demand owns only the first. In context: Section 1Open full size: Figure 4

Section 2 · Why cost drivers exist: the service doesn't cause its own load

Flow diagram. Equipment, power, space and staff bills flow through resource drivers to shared services, then through traced, sampled activity drivers to Products A, B and C. A network example, labeled as a shared service with its own drivers, reads "bytes replicated per byte written; cross-region calls per request". A side branch carries rootless background work (compaction, replication, re-indexing and backups) and the unattributable leftover δ to an unallocated line, apportioned by declared policy and owned by the service. The formula c(s,r) = sum over products of a(s,p) times ρ(p,r), plus δ(s,r), is shown with its source [2]. A note says Dapper's first version sampled one trace in 1,024 [12]. Schematic.
Figure 5. Bills land on shared services first, then follow traced calls to the products that caused them. What no request explains is apportioned by declared policy and kept on an owned line. Schematic. In context: Section 2Open full size: Figure 5

Section 3 · What is published, and what it leaves open

Layered diagram on one page. The base is Hixson and Guliani's 2015 frame [6]: organic and inorganic growth; a planning horizon at least as long as resource order time; fungibility; planning for only some launches, with a correlation check; a lead-time table ending at "Ready to serve," step 2 in outline; weighting actions with "costs" so they normalize into one driver, an early form of this paper's coefficient; checking that blow-up factors "remain accurate" and writing down design assumptions, the same idea as a valid range; keeping step changes itemized to "learn as you repeat the process," which scoring by stage writes down; "That tolerance should define how aggressively you provision," the shortage-to-idle choice; the "sensitivity" of estimates "to their time horizon," the residual uncertainty at a commit point; shorter lead times as among "the most valuable things" a company can do; and a Plan B for a "success disaster." Above it, three published families are placed by when they decide: statistical driver regression after observing history [13]; coefficient graphs and attribution each planning cycle [1, 2, 14]; priced allocation before resources are assigned [15–18]. A side column notes that step-change demand is declared by the team that knows it, runs optimistic and can be checked against a reference class [7, 8–10, 30–34]. Above that, a band lists some parts borrowed from operations, finance and IT management: hierarchical planning, gain-sharing and IT financial management [3–5]; parties and stages [19–24]; Olavson's base-and-high consensus, customer-versus-statistical check, slow layers planned to a high quantile and quantiles varying by component [8]; netting and time fences, standard manufacturing practice; and the operations results named with the sections that cite them: the newsvendor formula (Section 6.3); postponement, quantity flexibility, chained flexibility and the option value of waiting (Section 6.2). Others are cited where the text uses them. The top band shows what this paper adds: a rule tying each supply layer's commitment to the declaration's stage at its commit point, and governance with owners, versions and ledgers, with a sub-line: ratios are monitored in [7]; owners, versions and restatement are added here. A note says the coefficient-as-agreement claim extends Meta's "capacity contracts" [31] from the amount of capacity to the coefficient and rate. A card in the published band credits the 2026 SRE chapter [7], by Gordon, Kirby, Hixson and colleagues: planned and unplanned inorganic demand, percentile forecasts and backtesting, an unconstrained plan turned into a plan of record, pooling, stranded capacity, and demand and supply shaping; supply dimensions (fungibility, lead time, elasticity); phased, non-binary readiness. A bracket marks it as the same lineage as the 2015 frame.
Figure 6. The formula is published [1, 2], and much of the frame is Hixson and Guliani's [6]. What this paper adds sits on top: a rule tying supply commitments to how firm a launch is, and the governance that keeps the numbers true. The 2026 SRE chapter [7] publishes much of the middle layer and has the ingredients; as far as I can find, it doesn't write them as one rule per supply layer. In context: Section 3Open full size: Figure 6

Section 4 · Three prices, three questions

Three hotel scenes. A ledger gives each guest's share of the year's bill: the average loaded rate, which answers who pays. A new wing's cost per room: long-run incremental cost, which answers whether to build. The last room on a sold-out night is worth what the turned-away guest would pay: the shadow price, which answers who gets scarce capacity; on a half-empty night it is near zero.
Figure 7. One hotel, three prices: a fair share of what already runs, the cost of building more, and the worth of the last room when it's scarce. Asking one number to do all three misleads on at least one. In context: Section 4Open full size: Figure 7
Two panels for a $9.0 million pool. Rate on usage: 65 million core-hours gives about $0.138; when one consumer leaves and usage falls to 45 million, the rate becomes $0.20, up 44%. Rate on practical capacity of 75 million: $0.12 before and after; the 30 million idle core-hours, $3.6 million, sit on the service's unused line. Illustrative.
Figure 8. Set the rate on usage and one departure raises every other bill, inviting the next. Set it on practical capacity and the idle remainder becomes its own owned line. Illustrative. In context: Section 4Open full size: Figure 8

Section 5 · Coefficients are agreements

Flow diagram: Products A and B feed a front-end tier, which calls Service X (0.4 × 2.5 ms) and Service Y (0.1 × 5 ms). Product C calls Service Y directly (0.2 × 1 ms), and replication links X to Y. A solid arrow reads the coefficient forward as a load forecast; Product A's coefficient at Service X is 0.4 × 2.5 = 1.0 ms per request. A dashed arrow reads it backward as a price charged to the causer. Below, Cost = V × α × r, with owners for volume, coefficient and rate. Forward, 1,000 requests per second keeps one core busy; backward, each extra 1,000 is about $1,051 a year at the illustrative rate. Service Y and Products B and C are illustrative.
Figure 9. The same coefficient forecasts a shared service's load and prices a consumer's growth, so both sides need it stable and readable. In context: Section 5.2Open full size: Figure 9
Two rings that meet at the alerts. The measuring ring, built on the 2026 SRE chapter [7] and arranged by this paper: pick a business driver, the chapter's intrinsic product metrics; collect driver and resource telemetry together; compute the ratio continuously; raise two alerts, one when the ratio shifts and one when consumption deviates from the forecast; log them as tickets to planning; reuse the ratios in pre-launch tests and benchmarks; re-validate periodically and find efficiency projects, which feed back into design. The agreement ring, this paper's: the coefficient is published with a version, an effective date, an owner and a valid range (mechanism 3, the service owner with finance). It is used two ways, forward as a load forecast and backward as a price, and measured on actuals, with its age recorded and, as Hixson and Guliani advise, its accuracy checked regularly [6]. A diamond asks whether it has passed its error threshold, set in money, or met a break, such as a hardware change, migration or re-grain. If not, it stays in use. If so, its history is restated per service, or it is re-fitted, the cause is logged in the discontinuity register (mechanism 6), and a new version takes effect from its date. Three inputs enter the agreement ring: a consumer's challenge, which sometimes wins; a reorganization, which gives an orphaned coefficient an interim owner and a transfer date; and a newly found driver, added with its own coefficient and rate from its effective date, not retroactively. A re-baseline node on the agreement ring, fed by the gap between plan and actual, resets the baseline on a set cadence or past a threshold and scores the gap by owner. Where the rings meet, both alerts are read against the published coefficient: the ratio alert goes to the service owner, who owns the coefficient, and the forecast alert, while the ratio holds, goes to the product team, who owns volume. A note says reclamation changes supply, not the coefficient, so it stays out of the history.
Figure 10. Two rings. The SRE chapter's measuring ring tracks the ratio and raises two alerts [7]; this paper's agreement ring publishes, versions and restates it. The alerts are where they meet, each going to the owner of the term it watches. In context: Section 5.2Open full size: Figure 10
(a) Two consumers each peak at 100 cores, one at 2 p.m., the service's peak, one at 3 a.m.; the night consumer sends 20 at 2 p.m., so it caused 20. (b) Surviving one loss of three domains takes 1.5 times peak; one of four, 1.33; two of four, 2. The number of losses to survive is set by the consumer's availability tier. Illustrative.
Figure 11. Two things Cost = V × α × r hides: a consumer's share is its load at the service's peak, and the availability tier multiplies capacity in steps. Illustrative. In context: Section 5.2Open full size: Figure 11
Two stacked line charts over quarters Q1–Q16 with a demand strip above. Top panel: an observed CPU-ms-per-request series breaks at a hardware change (Q5, ×0.75) and a measurement re-grain (Q8, ×1.15), and a trend fitted through the breaks forecasts too low. Bottom panel: the same history restated on the current basis is a smooth decline and forecasts 0.759–0.733. Synthetic data.
Figure 12. Restate history at known breaks instead of asking a trend to learn them. It's the capacity version of split-adjusting a price series. In context: Section 5.3Open full size: Figure 12
Five-stage staircase: Intent, Dated, Configured, Live, Organic. Each step shows what is known, the evidence needed to enter it and the supply action it licenses, from a share of the envelope and options at Intent to closing the declaration at Organic. The range of likely size narrows at each decision event.
Figure 13. A declaration firms up in stages, at decision events. Each stage licenses only its own supply action, and promotion takes the evidence on its row. In context: Section 5.4Open full size: Figure 13
State diagram. A launch with no history enters as a declaration and moves Intent, Dated, Configured, Live, Organic. Each promotion needs evidence: a named owner and driver; funding with a target date; a design review and a place on the launch calendar; the launch; a completed ramp. Organic closes the declaration. An intent not advanced by its target date leaves the envelope unless re-confirmed. A configured launch's grant lapses if its date passes unconfirmed, and the slip becomes a recorded event. Planning promotes, demotes or expires a declaration, on the stage's evidence or a missed target date. Within a stage, a change inside its change band is the plan working; outside it, a priced event recorded against the declaration. Declared size and date are scored against actuals by the stage the ask was made (mechanism 2) and feed the all-teams stage record, a reference class [10]. An inset blends eight launches of that record at 60% with Team T's two at 50%, giving 58%, where T's next intent enters. A note says a team whose intents land at half and whose configured asks land within 10% is calibrated late, not dishonest. Tags tie two games to their counters: stage inflation to promotion only on evidence, and parked intents to expiry. Illustrative.
Figure 14. A declaration moves up only on evidence, expires if it stalls, and is scored against what landed. Its record, blended with every team's, sets where the next intent enters. Illustrative numbers. In context: Section 5.4Open full size: Figure 14

Section 6 · Approval is not allocation

Schematic seven-step funnel: Declared, Approved, Allocated, Delivered, Live, Adopted, Productive. Lettered gaps (a)–(f) name each leak and its owner, from forecast error (declaring team) to occupancy without goodput (workload owner). Notes mark firmness classes at approval, the limits of markets over steps 2–3, and supply contracts creating liabilities over steps 3–4. Netting sits between approved and allocated. Delivered is itself a chain from order to turn-up, where each link's need date is the next link's start. Approvals stay uncommitted until supply answers.
Figure 15. A common unit prices demand so it can be approved. The steps after that are where ownership most easily goes unassigned. Hixson and Guliani's lead-time table runs a similar line [6]; the funnel adds adoption and productive use after capacity is live. In context: Section 6Open full size: Figure 15
Illustration of three trucks on a highway heading to a building marked launch, each carrying one supply layer. The door is their need date, the start of the next layer, not launch day; at the door, turn-up is a crew working at a rate, not a truck. Below, a ladder of lead times: land, shell and power in years; long-haul network in months to years; machines and parts in quarters; turn-up in weeks per job; placement from minutes to days. Turn-up and order-to-dock times have no published values.
Figure 16. Supply is already on the highway. The slower the layer, the longer ago it had to leave, so each layer has its own commit point even inside one launch. In context: Section 6.2Open full size: Figure 16
Three panels. (a) Five orders placed at −5: four arrive in one quarter, one in two, so plan on two and commit at −8 for a need date of −2; in my experience, late arrivals are common and early ones rare. (b) Hall, machines (two quarters, −8 to −2), turn-up and load tests run as a relay; each layer is needed when the next starts, not at launch. (c) Four halls at two weeks each, two at a time, take a month; a slipped batch of four more waits a month longer. Hypothetical values.
Figure 17. Three adjustments that move a commit point earlier than "launch minus lead time": plan on the slow case, work back from the next layer's start, and remember that turn-up is a queue. Hypothetical values. In context: Section 6.2Open full size: Figure 17
Step chart of the share of an order's price owed on cancelling, by time before delivery: a tenth a year out, half a quarter out, all of it inside the vendor's build time. A dashed line at 100% marks orders that are non-cancellable from the start. A two-way arrow says a delivery can usually be pushed out or pulled in for less than cancelling. A marker at the edge of the cheap step defines the cancel window as the last date you can still walk away cheaply. A side card says that once the window closes the forecast is a liability, recorded with its cancel window and owner in mechanism 11. Hypothetical.
Figure 18. What you owe on cancelling rises in steps toward delivery, and some orders are non-cancellable from the start. Since slips are the most common timing miss, the right to push a delivery out is often the more valuable one. Hypothetical numbers; no published terms of this kind were found. In context: Section 6.2Open full size: Figure 18
A chain from powered land, which can serve almost any launch, to a shell with a cooling design, which serves fewer, to a tested rack in one hall, which serves only demand of its shape there. Buildings, power and common parts are committed on the slow clock and configured machines on the fast one. An inset defines an option as a deposit that holds the right to buy later.
Figure 19. Postponement [73] in capacity: keep supply generic until the decision that says which shape, and hold the slow, generic layers open with options. In context: Section 6.2Open full size: Figure 19
A newspaper seller stocks copies before knowing demand. Below, ten equally likely demand outcomes from lowest to highest; with running short costing four times holding a spare, the fraction is 0.8, so the plan covers the eighth-lowest and accepts running short in the two above. A note credits the textbook newsvendor formula [78], which this paper calls the shortage-to-idle ratio.
Figure 20. Buy up the range until the next unit is as likely to sit idle as to be needed, weighted by which mistake costs more. At 4 : 1, cover the eighth of ten outcomes. The rule is the textbook newsvendor formula [78]. In context: Section 6.3Open full size: Figure 20
Three panels. (a) Six named buffers: redundancy, maintenance reserve, queueing headroom, forecast-error buffer, launch reserve and inventory buffer, with one operator's published split of about 94% guaranteed, 2% for random failures and 4% for correlated failures [54]. (b) Independent monthly errors of ±10 grow to about ±20 over four months, not ±40. A growth-rate error, 4% a month against a 3% forecast, ends about 12% above plan after a year and about 26% after two. (c) Pooling: two regions holding 10 each need about 14 together, not 20; four need about 20, not 40. Illustrative except the cited split.
Figure 21. Name each buffer and size it on which mistake costs more. Lead time pushes buffers up, more than the textbook says when errors run the same way; pooling pulls them down. Illustrative, except the cited split [54]. In context: Section 6.3Open full size: Figure 21
Schematic timeline from 24 months before launch to 6 months after. Top, the demand clock: a declaration's open size range narrows in steps at decision events (funding approval, design review, go/no-go; a named owner and a completed ramp are marked hollow, as evidence rather than events), from Intent (months −18 to −9) to Dated (−9 to −3), Configured (−3 to launch), Live (launch to +3) and Organic (after ramp). Bottom, the supply clock: five layers, each a bar ending at launch whose left end is its commit point: land, power and shell (−24, before any declaration exists); network and large contracts (−15, at Intent); machines and parts (−6, at Dated); turn-up and allocation (−1, at Configured); placement and admission (launch, Live). Orange brackets mark the range still open at each commit point; at the land, power and shell commit point the whole range is still open. Instruments on the right: envelope for the portfolio and options; buy toward the high through options and cancel windows; buy to the base with the high as options, a reserve or a bridge; rank, cut line and grants; bridges and admission control. Illustrative. At each dot a tag names the stage the declaration has reached. At −15 the range still open is 40,000 to 100,000 requests per second; at −6, a base of 60,000 and a high of 90,000. A note says the bars are simplified; the method stacks need dates and uses cautious lead times.
Figure 22. Demand firms up on one clock; supply commits on another. At each layer's commit point, the range still open in the declaration, not the point forecast, picks the instrument. In context: Section 6.5Open full size: Figure 22
Three range bars. Turn-up, ratio 1 to 1, covered to the median. Machines, 4 to 1, to the 80th percentile. Power and shell, 19 to 1, to the 95th, mostly as options. Notes give the two conditions: layers must work together, and the high is held mostly as options. Illustrative; the paper's argument, not a published result.
Figure 23. For lasting demand in a growing business, the paper argues that the cover point should rise with lead time: median for turn-up, about the 80th percentile for machines, about the 95th for power and shells. Illustrative, not a published result. In context: Section 6.5Open full size: Figure 23
Decision tree for one supply layer, in the same order as the method's flowchart. The first question asks whether any declaration exists at the layer's commit point. If none does, the portfolio envelope serves the layer and the launch's claim on it is recorded, as for land, power and shell. If one does, a second question asks whether the attribute that drives the layer (region, redundancy tier, hardware class and power density, or data stored) is known by its commit point. If yes, the planner goes on to cover, net and split. If no, there are three unranked choices: ask for the decision earlier; buy an option that carries the commitment past the event; or commit to the stage's record and name the owner of the residual. Each choice ends in a decision note recording what was known, when, by whom, and what would have changed it. A worked row from Appendix A: high-memory machines commit at −11 while the launch is an intent. Stored data is asked at −12 as a range of 8 to 20 TB, and one machine is ordered reschedulable until −3. Illustrative.
Figure 24. When an order is due before the event that would size it, ask earlier, buy an option past the event, or commit to the stage's record and name who owns the rest, and write down which. Before any declaration exists, only the portfolio envelope can serve the layer. Illustrative example from Appendix A. In context: Section 6.5Open full size: Figure 24
(a) A decision event, then a gate, then a commit point. When the commit point comes first, there are three choices: ask earlier, buy an option past the event, or commit to the stage's record and name the owner of the residual. (b) Change bands narrow from ±50% to ±25% to ±10% around 60,000; the launch landed at 40,000, six weeks late, outside both bands. Panel (a) uses generic timing, panel (b) Appendix A's. The bands follow manufacturing time fences and quantity-flexibility contracts [70, 71]. Illustrative.
Figure 25. Put each gate between the event that answers a question and the order that needs the answer. Agree how far the declaration may still move at each stage. Illustrative bands. In context: Section 6.5Open full size: Figure 25
Four panels. (a) A size miss is paid mostly on the slow and middle layers: too high, and capacity waits for demand; too low, and the gap needs bridges. (b) A slip is paid mostly at the machine and turn-up layers, for the length of the slip. A building serving twenty launches hardly notices one six weeks late. (c) A launch as a persistent step with a transient spike on top. The step wants owned capacity; the spike wants returnable capacity (shifted work, reclaimed and borrowed buffers, third-party capacity, admission control at the top). Sizing owned capacity on the spike buys permanent capacity for a temporary peak. (d) On the bill: a size miss shows as a smaller bill, in the volume term; a slip is invisible on a flat realized-peak bill, and under hour-by-hour billing its cost moves to the service's unused line. Schematic.
Figure 26. A size miss is paid on the slow and middle layers; a slip, on the machines and turn-up committed for the launch. A spike on a step needs two shapes: owned capacity for the step, returnable capacity for the spike. On a flat bill, a slip can be invisible. Schematic. In context: Section 6.6Open full size: Figure 26
Left: four independent launches, each half likely (a coin marked 50%); usually about two land, and all four only about one time in sixteen. Right: the same four tied to one driver land or slip together; half the time all four land, and a plan for two is short by two. Planning for only some launches, and checking that they aren't correlated: Hixson and Guliani [6]. Illustrative.
Figure 27. Independent bets average out; bets tied to one driver land or slip together. Hixson and Guliani's correlation check [6] is what makes planning for fewer successes safe. Illustrative. In context: Section 6.6Open full size: Figure 27
Two panels on one scale, in thousand requests per second. Separate reserves: four launches each hold a 25,000 high slice, 100,000 in all. One pooled reserve: with each launch independently half likely to need its slice, the outcomes 0, 25, 50, 75 and 100 thousand occur 1, 4, 6, 4 and 1 times in 16. Fifty thousand covers 11 of 16, under the 80th percentile; 75,000 covers 15 of 16, so the 80th percentile is 75,000. A strip notes that launches tied to one driver land together and need all 100,000. Peak of sums, after [7]; planning for only some launches [6]. Illustrative.
Figure 28. One reserve for a group of independent launches, sized to the group's high, holds less than the sum of their high slices. Tie the launches to one driver and the saving disappears. Illustrative. In context: Section 6.6Open full size: Figure 28
Two parts. At the top, demand's stages (Intent, Dated, Configured, Live, Organic) mirror supply's (planned, contracted, under construction, delivered, live), with both scored on promised against actual size and date by stage (mechanisms 2 and 11); a planner who discounts demand intents but takes supply promises at face value has half an outside view. Below, a chain: a late transformer delays the building, then every rack and turn-up committed on the old date, and the slipped batches queue at turn-up together, so a slip often shows up twice. Side notes: decommission is negative supply [2], so a slipped retirement can stall an on-time delivery; and four sites that wait on one transformer supplier or utility slip together. A footer says a supply slip is an envelope change in time, handled as a re-cut. Schematic.
Figure 29. Supply declares in stages too, and is scored the same way. One late part travels down the chain and arrives at turn-up with everything else that slipped. Schematic. In context: Section 6.7Open full size: Figure 29

Section 7 · A worked example (all numbers illustrative)

Machine diagrams. The need is 200 cores and 1.6 TB of memory. Four standard machines (4 NMU) give 200 cores but only 0.8 TB. Eight standard (8 NMU) give enough memory with half the cores stranded. Two standard plus two high-memory (4.8 NMU) fit exactly. The 0.8 NMU gap goes on the fulfillment ledger with a named owner. Via standard machines each extra GB costs 0.005 NMU, five times its weight; high-memory machines take two quarters, standard ones come from the stocked pool in weeks. Illustrative.
Figure 30. The forum approved 4 NMU because the intake asked only about CPU. The data A stores needs memory, and the cheapest fit is 4.8 NMU. The 0.8 gap needs a named owner. Illustrative. In context: Section 7Open full size: Figure 30
Waterfall chart of annual cost to Product A: plan $525,600; volume −$21,024 (Product A); coefficient +$126,144 (Service X release); rate +$52,560 (Service X with finance); actual $683,280. The terms A did not own total +$178,704, more than the +$157,680 (+30.0%) overrun. Illustrative numbers.
Figure 31. A forecast within 4% and a bill 30% over plan. Split the variance by term and each piece gets an owner; the two terms A did not own add up to more than the whole overrun. In context: Section 7Open full size: Figure 31
Swimlane flowchart in five lanes: Product A; Service X; X with finance; planning with X; and the forum with finance. The +$157,680 overrun on a forecast within 4% splits into volume −$21,024 (Product A), coefficient +$126,144 (Service X, whose release should have been versioned) and rate +$52,560 (X with finance). From the split, the forum rules on each piece, whether or not a payment rule exists. X's CPU bridge premiums go to X, outside its rate. The memory bridge and the 0.8 NMU go to the unallocated line with planning and X named. A's memory is charged only from the new driver's effective date, and X re-fits with a second driver, data stored. Separately, a diamond asks who pays the coefficient term: was a payment rule agreed with finance before the miss? Without one, the pieces have owners in the meeting but not on the bill. With one, the forum scores the coefficient term against X's efficiency commitment and decides whether a central reserve holds A harmless. An inset shows that putting the rate first moves $8,760 off the rate piece, so the order is a policy. Illustrative.
Figure 32. The split gives each piece an owner, and the forum rules on the bridges, the memory and the re-fit either way. Who pays the coefficient term needs a rule agreed in advance; without one, that piece has an owner in the meeting but not on the bill. Illustrative numbers. In context: Section 7Open full size: Figure 32

Section 8 · The commit-point method

Eight steps in two groups. Read (worksheet Part A): list the layers and their lead times in the slow case; find each layer's need date and commit point; read the stage and the range still open at each commit point, and whether the driving attribute is known. Decide (worksheet Part B and footer): choose how far up the range to cover; net against what you have; split each layer into firm, flexible and named; agree change bands per stage; write it down and get supply's answer. The steps flow into four artifacts: the declaration register entry with its bands (mechanism 12), a commit-point map line per layer (13), the supply request and supply's answer (11), and the fulfillment ledger line (5), whose net and committed columns come from steps 5 and 6. A decision note is added where a commit point fell before the event that resolves it. Method steps are numbered pills, unlike the funnel's numbered squares.
Figure 33. The walk ends in artifacts, not a number. Each step writes into a register, a map, a ledger or supply's answer, so the decision can be checked and defended later. In context: Section 8.1Open full size: Figure 33
Ten configured-stage outcomes from 40,000 to 90,000 requests per second. Up to the 60,000 base is firm, ordered plainly. From 60,000 to the 70,000 target is flexible: options, reschedulable orders or a named reserve. Above 70,000 to 90,000 is named: a bridge with an owner and a ready-by date, then admission control. Worked rows for standard and high-memory machines follow. Illustrative.
Figure 34. Step 6 of the method: buy the firm part, hold the next slice as options or a reserve, and name a bridge and an owner for the rest. Illustrative numbers from Appendix A. In context: Section 8.2Open full size: Figure 34
Swimlane flowchart in four lanes: declaring team, forum, planning and supply. Planning pre-fills the intake from telemetry with last year's ask and actual. The team confirms its driver forecast and signs any override. The forum approves the ask in a common unit, ranks it and draws the cut line, and the approval is uncommitted until supply answers. Planning nets it against what's on hand, on order, due back and retiring, each dated and owned. Before each layer's commit point, planning sends the net requirement by shape, site and need date, the stage and open range, the signed band, accepted substitutes, the ramp and the rank under shortage. Supply answers either with a dated commit (quantity, date, confidence and any substituted shape), which makes it firm, or with a named gap (how much, by when, why, and a proposed bridge with its owner), which also makes it capped issue, with the gap named and the bridge owned. Both go on the fulfillment ledger, and pegging links each order to its declaration. Supply is scored on promised against actual, and demand on changes inside supply's lead time.
Figure 35. An approval prices an ask; supply's answer makes it firm. Planning sends a dated, ranged, signed request per layer before its commit point, and supply answers each line with a dated commit or a named gap; either answer makes it capped issue. In context: Section 8.3Open full size: Figure 35
Two timelines in months from launch. As written: high-memory machines commit at −6, the memory need surfaces at −3, and machines arrive at +3, a quarter late, so a bridge runs. With the method: power commits at −20, stored data is asked at −12, high-memory commits at −11, machines are on the dock by −2, ready for service at −1; no bridge at the base. The cost is about 1.0 NMU of spare, about $26,280 a year more idle at the 40,000 landing. Illustrative.
Figure 36. Section 7's launch with and without the method. A cautious lead time and a real need date move the high-memory commit point from −6 to −11, early enough to ask about stored data. The spare it buys has a price, and an owner. Illustrative. In context: Section 8.4Open full size: Figure 36

Section 9 · The operating discipline: keeping the agreement

24-month timeline. Context lanes show finance envelope, budget lock and goal-setting dates. Nested bands show the annual, quarterly, monthly and continuous steering cycles, each aligned on the right to a lead time from years down to minutes. One month after each launch, a post-launch review feeds the next quarterly intake (dashed arrows). A starred month-16 envelope change moves the cut line. Months 11–12 are an off-cycle zone where a gate can block launches. Each quarterly cycle includes a supply review where supply brings its own plan, constraints and risks; a callout marks it as, in the author's experience, the step most often missing.
Figure 37 (illustrative timings). Each horizon commits only what its lead time demands. Actuals flow back into the next intake, and an envelope change re-cuts the ranked list instead of reopening every commitment. The supply review sits between demand and decision each quarter. In context: Section 9.1Open full size: Figure 37
Flowchart on one page with two paths. On the left, an envelope cut or pull-in, or a supply slip treated as an envelope change in time, reaches a diamond: was the re-cut order agreed beforehand? If not, the plan is renegotiated team by team and doesn't survive. If so, the forum re-signs with finance, the cut line moves in ranked order, and displaced claims are named, not trimmed pro rata. On the right, a shortage in one shape at one site follows its own rule: a diamond asks whether the shortage rule, who goes short first, was agreed in the forum beforehand. If not, written during the shortage, it's a negotiation. If so, supply carries out who goes short first. Both paths then ask whether a bridge can cover a displaced claim; if not, the claim stays named. A ladder lists bridges by time to capacity: re-pegging a slipped launch's supply (days); reclaiming (days to weeks); shifting demand (hours to weeks for stateless serving); reallocating between tenants (weeks); deferring a decommission (weeks); third-party capacity (months with a standing agreement); and facility redesign (quarters to years). Each premium is charged to its cause. An override path lets a named executive move a launch above the line, logged with what moved down and charged for its bridges.
Figure 38. An envelope cut or a supply slip moves the cut line in an order agreed in advance; a shortage in one shape follows its own rule, agreed beforehand. Either way, name what's displaced, bridge what can be bridged and charge each premium to its cause. Bridge speeds are the paper's judgment. In context: Section 9.1Open full size: Figure 38
Thirteen numbered tiles in four groups. Keep demand honest: 1 declared demand in priced units, 2 prior ask beside prior actual, 12 declaration register. Keep price honest: 3 coefficient register and versioned rate card, 4 owned unused and unallocated lines, 6 discontinuity register. Keep supply honest: 5 fulfillment ledger, 11 supply plan of record and commitment register, 13 commit-point map. Make decisions stick: 7 commitments that become institutions, 8 efficiency landing rule, 9 cadence aligned to lead time and launch calendar, 10 standing arbitration forum. Each tile names its artifact and owner. Six are outlined as carrying the argument: 2, 3, 5, 8, 12 and 13; the commit-point method writes into 12 and 13.
Figure 39. The operating discipline as thirteen artifacts, each with an owner, grouped by the job they do. Outlined: the six that carry the paper's argument. In context: Section 9.2Open full size: Figure 39
Matrix of nine decision rights against seven roles. A named executive, a column of its own, holds only the cut-line override, logged with the displaced claim. The forum re-cuts the plan in ranked order, with finance, when the envelope changes. Planning promotes, demotes or expires declarations, on the stage's evidence or a missed target date, and names interim owners for orphaned coefficients. The new accountable leader re-signs after a reorganization. Finance and product, the declaring team, set the shortage-to-idle ratios jointly, with supply's input on the cost of idle and the liability terms. Supply and planning set change bands inside each lead time, the declaring team signs them, and finance agrees who pays for a change outside them. Supply answers each ask with a commit or a gap and accepts a substitute shape or site. Reliability engineering sets reliability buffers. A footer adds the efficiency landing rule, who keeps capacity a team saves, agreed before any recovery by planning with finance (mechanism 8).
Figure 40. Nine decisions that sit outside the mechanisms' owner column, and who holds each. Supply holds the answer to every ask; finance co-signs every rule about who pays. The landing rule, who keeps capacity a team saves, is agreed before any recovery. In context: Section 9.2Open full size: Figure 40

Section 10 · People: the room around the math

A triangle with capital at the top, demand at the lower left and supply at the lower right, and the planner in a circle in the middle with a spoke to each corner. Capital has money and wants it to buy something. Demand has plans and wants capacity on time. Supply has lead times and contracts and wants a signal to buy against. Each edge carries two arrows. Capital to demand: envelope, cut line, the bill; demand to capital: business case, signed forecast, efficiency commitment. Capital to supply: approval to order, contract sign-off; supply to capital: liabilities, cancel windows, promised dates. Demand to supply: declarations by stage, change bands, substitutes; supply to demand: a dated commit or a named gap. A shared service straddles the demand–supply edge: supply to its callers, demand to the fleet. Seam 1, between product and platform, attaches there: volume belongs to product, the coefficient and rate to platform. Seam 2, between planning and finance, runs along capital's edges and carries three finance decisions disguised as capacity decisions: a third-party bridge, a deferred decommission and an early order. Seam 3, between planning and supply, runs along the demand–supply edge, brokered by the planner and held by an answer to every ask, pegging, change bands with who pays beyond them, shortage rules agreed in advance, and a definition of done anchored on Hixson and Guliani’s “Ready to serve” [6]. The planner box reads: usually owns no capacity and no budget; information, who holds what and what's coming; timing, ask before the commit point; trust, numbers it doesn't pad; credible commitments, signatures others can buy against. Two tags mark the claims: on the capital–demand edge, the coefficient is the price on this edge; on the demand–supply edge, at seam 3, approval is not allocation. A footer says the seams of Section 10.1 run along these edges.
Figure 41. Capacity is a handshake among capital, supply and demand. The planner sits in the middle, usually with no capacity and no budget, and trades in information, timing, trust and credible commitments. The three seams run along the edges. In context: Section 10.1Open full size: Figure 41
A strip of six points in the planning cycle (intake, declaration stages, cut line, grant, inside the lead time, buffers), with eight games above and their counters below. Capacity requests are budgets, pathologies included [95, 96]. At intake, relabeling, organic growth declared as a launch to jump the queue: launch priority requires a dated declaration with a named owner. At the stages, parked intents enter at their stage's record and expire if they don't advance, and stage inflation is met by promotion only on the stage's evidence, with size and slip scored by stage. At the cut line, a late ask is charged its bridge premium and late asks are reported by owner. At the grant, capacity held for a launch that quietly moved expires unless re-confirmed. Inside the lead time, churn is bounded by change bands, with changes reported by requester. At buffers, reliability as a trump card is met with named buffers, each sized by its owner, and planning's own padding, which matters most, becomes a signed forecast-error buffer line.
Figure 42. Each game pays off at one point in the cycle, and its counter sits at that point. The one that matters most is planning's own. In context: Section 10.3Open full size: Figure 42
Swimlane flowchart in three lanes: the consuming team, the forum (run by planning), and the service owner with finance. The service owner publishes the coefficient and rate with a version, an effective date, an owner and a valid range (mechanism 3). The consuming team, which needs its own coefficient, reproducible from its telemetry, challenges a coefficient. The forum rules on the challenge (mechanism 10), reading the published version, as it ruled on a new driver in Section 7. A diamond asks whether the challenge wins. If not, the published version stays in use. If so, the service owner restates the history per service, or re-fits, and a new version takes effect from its effective date, not retroactively. A strip shows the record it leaves: the ruling in the forum's decision log (mechanism 10); if the challenge wins, the new version and its effective date in the coefficient register and rate card's change log (mechanism 3), and the cause in the discontinuity register (mechanism 6). Notes say that who pays a coefficient term is a separate rule, agreed with finance before the miss; that planning publishes the same indicators about the infrastructure organization's coefficients as about consumers' forecasts; and that a consumer who can challenge a coefficient, and sometimes wins, trusts the rest of the bill, one of Ostrom's design principles for durable commons [97].
Figure 43. A channel to challenge coefficients: the consumer brings the challenge, the forum rules, and sometimes the consumer wins. Every ruling goes in the forum's decision log; a win also leaves a new version, from its effective date, with its cause recorded. In context: Section 10.4Open full size: Figure 43

Section 11 · What changes in the AI era

Two panels. (a) Four translations. For the largest operators' AI fleets, by their own account [72, 90], the binding resource moves from dollars toward critical IT megawatts; say which power, and at a PUE of 1.2, 10 MW of IT load is 12 MW of facility power. Shape becomes one interconnect domain, where quota can exist without geometry, in about 1% of cases [18]. The driver becomes tokens with two phases: 1,900 tokens in and 100 out is mostly prefill compute, while 100 in and 1,900 out is 1,900 decode steps holding cache memory. Productivity moves from utilization to goodput. (b) A schematic timeline: a training run is declared and still an intent while its power and cooling are committed years ahead, against a hardware generation that may not ship on time. A model launch is a transient spike on a persistent step, declared as two shapes. Illustrative.
Figure 44. For AI fleets the structure holds, but the units move: for the largest operators, by their own account, megawatts bind, an interconnect domain is a shape, a token has two phases, and a training cluster is a step change on both sides at once. In context: Section 11Open full size: Figure 44
Stacked bar of 100 accelerator-hours: 10 idle (unused line, service), 9 lost to failures and preemptions (owned by cause), about 24 below the program's achievable efficiency (workload), about 57 goodput. 0.9 × 0.9 × 0.7 ≈ 0.57, the ML Productivity Goodput split [105]; goodput is the blue slice. Illustrative.
Figure 45. Of 100 illustrative accelerator-hours, about 57 are real progress. Each of the other slices has its own owner, and folding them together charges the provider for the tenant's losses. In context: Section 11Open full size: Figure 45

Section 12 · For mid-sized companies

Translation map. Long-lead supply becomes multi-year cloud commitments, reserved capacity, colocation and license renewals, on the vendor's quarter-end calendar. The fulfillment gap becomes commitments that don't match the shapes and regions used, and licenses bought but not deployed. The coefficient becomes cost per customer, transaction or pipeline run. The unallocated line becomes untagged cloud spend plus licenses and AI model usage on separate invoices. The forum becomes a CTO–CFO meeting that owns the cut line. Chargeback may stop at showback. Below, the sales pipeline, with win rates by stage, feeds late-stage deals into the capacity plan, and they are scored against actual usage. A strip lists what not to do: chargeback before showback, a tool before drivers and owners, booking unit-cost gains as savings without checking volume, and forecasting a three-year commitment as elastic spend.
Figure 46. At a few hundred to a few thousand people, the long-lead supply is the cloud commitment and its renewal date, and the declaration register usually exists already as the sales pipeline. In context: Section 12Open full size: Figure 46

Section 13 · Where this breaks, and what is unknown

Two lanes from Figure 22, redrawn for the Meet case. Demand lane: the first signal is pages for regional capacity [7], and the stages arrive almost at once near the right edge; in the author's reading, declarations arrive too late for the slow layers. Demand grew 30x in three months [110]. Supply lane: the commit points of land, power and shell, and network sit far to the left, greyed as already past, also the author's reading. Machines are not greyed: they came through regular orders and borrowing [7]. Near the right edge, four fast levers: borrow, a bridge; re-shape; efficiency work; and escape hatches built ahead of need, inside a daily loop asking whether there is enough for the load one week out [7]. Schematic; a reading of a public case.
Figure 47. The Meet case on the two clocks: most slow layers' commit points had already passed; machines came through regular orders and borrowing, and fast levers, some built just ahead of need, did the rest. Schematic; a reading of a public case. In context: Section 13Open full size: Figure 47
Evidence ledger. Published: the cost-driver formula, computed at scale [1, 2]; attribution coverage and residuals [2] (tracing 52% of capacity usage in 2022; residuals of 3 to 5% for a stateless web product and 22% falling to 15% for databases), still open for stateful services and batched inference; and the nearest results on the mechanisms, parts safety stock at about 0.6 times under triangulation [8] and planning cut from three to four months to about one [34]. Published in part: lead times by layer [6, 8, 60–64, 109]; how long large new loads wait for power, on which little is published [65]; uncertainty at a commit point, with observational evidence only, a 2x difference in machine count forecasts [8]; and the pieces of the thirteen mechanisms [8, 31, 34]. Published in part, too: the slow end of the cover point rising with lead time [8]. Argued here: the cover point rising with lead time, not a published result; the thirteen mechanisms joined, argued from practice; and the commit-point method, untested. Not found in public sources: order-to-dock times, turn-up durations, hardware contract terms, coefficient drift over time and how often coefficients are recalibrated, how well declarations are calibrated by stage and how often launches slip, and mechanisms for arbitrating scarce accelerators between internal and external demand (one preprint covers internal teams only [18]; operators state splits and priority orders, not mechanisms [90, 102]). The tests of Section 9.2 have not been run. A footer says not found means in the sources the author could read, including the second edition of Site Reliability Engineering's capacity chapter [7].
Figure 48. What rests on published evidence, what this paper argues, and what nobody has measured in public, as far as the sources show. The method itself is untested. In context: Section 13Open full size: Figure 48

Section 14 · A minimum viable discipline

Six role cards around the cost formula, Cost = V × α × r, with the promises Section 14 lists. Product leaders confirm the pre-filled intake, sign what they change, and declare step changes in stages, slow attributes first. Platform leaders publish each material coefficient and rate with an owner and a change log, and own the unused and unallocated lines. Finance declares what fully loaded contains and agrees in advance the landing rule, the shortage-to-idle ratios, the re-cut order and who pays when a coefficient regresses or a change falls outside the bands. Planning keeps the fulfillment ledger, carries the gap and walks each step change through the commit-point method. A standing forum owns the ranked list and the cut line. Supply chain answers every approved ask with a dated commit or a named gap, sets change bands and keeps the commit-point map with planning, declares its own step changes in stages, and is scored on promised against actual.
Figure 49. A minimum viable discipline: six roles, each keeping one part of the agreement true. In context: Section 14Open full size: Figure 49

Appendix A · A worksheet for one declaration

Key. Five supply-layer glyphs from land, power and shell to placement, with the standard and high-memory machine blocks; five stage circles filling from Intent to Organic; timeline marks for commit point, need date, ready for service, cautious lead time, range still open and actual; the firm, flexible and named slices; option, bridge and named-gap marks; numbered method-step pills; and badges for product team, shared service, finance, supply chain and planning.
Figure A.1. The symbols used in this appendix. In context: Appendix A.0Open full size: Figure A.1
Worksheet page 1, a blank form. Header fields: declaration; declaring team and accountable lead; persistent, transient, or both; shared drivers with other declarations and shared supply dependencies; launch date and ready-for-service date; stage dates; planner, supply counterpart and finance counterpart; and shortfall tolerance: none, hours or days, and how much. Part A, Read, has one row per supply layer (land, power and shell; network; machines by shape; turn-up; placement; two blank rows) with columns for usual and cautious lead time, source, need date, commit point, stage at the commit point, open range (low, base, high) and whether the driving attribute is known, or which of the three choices was taken. The footer records the size band, date band and signatures for each stage move.
Figure A.2 (page 1 of 2). The worksheet for one declaration: copy one per launch. The header names the declaration and its counterparts; Part A reads the situation layer by layer; the footer records the change bands. Page 1 of 2In context: Appendix A.1Open full size: Figure A.2, page 1 of 2
Worksheet page 2, a blank form. Part B, Decide, has one row per supply layer with columns for the shortage-to-idle ratio, cover-to point, gross target, on hand, on order, due back (date, owner), retiring (date), net need, firm, flexible (instrument), named (bridge, owner, ready-by) and supply's answer, a commit or a gap. The firm, flexible and named heads carry the three slice swatches. Below, the eight steps of the commit-point method as one strip.
Figure A.2 (page 2 of 2). Part B of the worksheet records the decisions and supply's answer, one row per supply layer; the strip below is the method it follows. Page 2 of 2In context: Appendix A.1Open full size: Figure A.2, page 2 of 2
Case card. Service X is a shared document store and Product A its largest caller. A's peak rises from 400,000 to 500,000 requests per second: 40,000 organic and 60,000 from a launch at the start of the second quarter. The coefficient is 0.4 calls at 2.5 ms, 1.0 ms per request, so 1,000 requests per second keeps one core busy. Installed cores are twice busy cores (1.5 for failure domains times 4/3 for queueing headroom). A standard machine has 50 cores and 200 GB (1 NMU); a high-memory machine, 50 cores and 600 GB (1.4 NMU). Memory is 100 GB per TB stored. At a launch volume of L thousand, installed cores are 2 × (40 + L) and memory is 0.4 + 0.02 × L TB. The launch is an intent of 40,000–100,000 at the annual cycle, dated at −6 with a base of 60,000 and a high of 90,000, and configured at −3 with two regions and its stored data. The rate is $0.12 per busy core-hour. Illustrative.
Figure A.3. The case: one launch on one shared service. Everything the walk-through needs is on this card. Illustrative numbers. In context: Appendix A.2Open full size: Figure A.3
Three ten-outcome strips in thousand requests per second. Intent from −12: 20 to 100, fifth-lowest 60, eighth-lowest 85. Dated from −6: 35 to 90, fifth-lowest 60, eighth-lowest 80. Configured from −3: 40 to 90, fifth-lowest 60, eighth-lowest 70. An actual of 40, six weeks late, is marked on each. Illustrative.
Figure A.4. Ten equally likely outcomes at each stage, from the stage's record. The base stays at 60,000 while the eighth-lowest falls from 85,000 to 70,000; the landing at 40,000 sits inside all three. Illustrative. In context: Appendix A.3Open full size: Figure A.4
Subtraction tree working back from launch. One month of load tests sets ready for service at −1. One month of turn-up puts machines on the dock at −2. From −2: high-memory machines, nine months cautious (six usual), commit at −11, while the launch is an intent. Standard machines from the pool, one month cautious, commit at −3, at Configured. Power and positions, eighteen months cautious, commit at −20, before any declaration exists. A note says that without the method, the high-memory commit point was −6, the usual lead time counted back from launch; the order went in at −3 and the machines arrived at +3. Illustrative.
Figure A.5. Step 2 as arithmetic: each layer's need date is the next layer's start, and its commit point is that date minus a cautious lead time. High-memory machines move from −6 to −11, while the launch is still an intent. Illustrative. In context: Appendix A.4Open full size: Figure A.5
Ledger strip from approved to adopted. As planned: gross 6 machines, 7.2 NMU, net 5 new. After the push-out at −3: 5 machines, 5.8 NMU, net 4 once the reclaimed machine is counted. Committed to match, plus the reclaim due at −4, owned by X, and a pool replenishment of 3 owed by +3. The launch landed at 40,000, six weeks late, outside the configured band of 54,000 to 66,000 and ±2 weeks on both size and date, and is recorded against A's declaration. Illustrative.
Figure A.6. The fulfillment ledger line the walk writes, before and after the second high-memory order was pushed out, and the band check when the launch landed. Illustrative. In context: Appendix A.5Open full size: Figure A.6

Appendix B · What the public record says about supply

Key. A single reported value, or a source's example value, is a filled dot; an average is a dot with a bar over it; a median is a half-filled ring; a recommended value is a ring with a centre dot. A reported range is a capped bar; "more than" is the stated value's mark with an open arrow to the right; "up to" is a cap at the stated maximum with a short, fading arrow to the left, never a bar from the axis; a chevron at the axis edge marks a value off the scale. A value described in words is a text chip; a dashed empty row means no public value was found; a bracketed number is the source, listed in B.6. Filling squares show firmness, from less firm to more firm, in the order one source reports it.
Figure B.1. How the charts in this appendix mark each kind of public value. In context: Appendix B.0Open full size: Figure B.1
Dot-and-range chart on a log time axis from a week to five years, grouped by supply layer. Public reported values, each with its source: your own buildings, an example value that "could be five years" [6], against ten minutes for a small cloud service, off scale [6]; grid connection in primary markets, an average wait of more than four years [60]; power transformers 128 weeks, generator step-up transformers 143 weeks and switchgear 44 weeks, averages for the second quarter of 2025 [61]; high-capacity transformers, as long as four years, a cap at the stated maximum [62]; some components, over six months [8]; one accelerator vendor's own supply, more than twelve months [64]; cloud capacity reservations requested 5 to 120 days ahead, 56 recommended [109]. Land, utilities and buildings are "planned years in advance" [8] and backbone network takes "months or even years" [63], shown as text. No public value was found for order-to-dock or turn-up time.
Figure B.2. Public reported lead times by supply layer, each from one source at one date; see sources. Ranges stay ranges, "more than" stays open and "as long as" is a cap, not a range; an example is a single dot. No two sources are combined. Turn-up and order-to-dock times have no public value. In context: Appendix B.1Open full size: Figure B.2
Rows on a months axis, each counted from its own start. New generation's median wait from request to signed agreement was well over three years in 2025 [112]; that measures power plants, not data center loads. For a large new load, one transmission owner cited by Lawrence Berkeley National Laboratory expects studies to take 6 to 18 months, and construction needing a line extension at least 18 and up to 60 months. The two are durations, each on its own row with a faint baseline from zero, so they do not read as one timeline, and they are not added [65]. The average wait for a grid connection in primary data center markets is more than four years, a different measure [60]. A chip notes natural gas as temporary bridge power and increasingly permanent on-site generation [60].
Figure B.3. A large new load waits in the utility's own process, not the queue for new power plants. Public reported values, each in its own source's terms; the two parts of the load path are durations, each from its own start, not one timeline, and are not added. See sources. In context: Appendix B.2Open full size: Figure B.3
Two panels. (a) Commitment lengths in years: a 20-year power purchase agreement [113]; data center leases of 15 to 20 years [72]; a campus lease with a four-year initial term, options to extend, and a residual value guarantee for the first 16 years [75]; a utility tariff with a ramp of up to four years plus an eight-year initial term, drawn apart [114]; and customer contracts averaging about five years [68]. A note quotes that chip lifetimes and contract lifetimes are very similar [72], and a callout quotes Oracle that its leases typically do not align with customer contracts [69]. (b) AEP Ohio's load ramp: the contract capacity in effect is no less than 50, 65, 80 and 90% of the full contract capacity in years one to four, then full. A separate dashed line marks the minimum bill, a separate provision,, which cannot exceed 85% of contract capacity. A dotted line marks that after the fifth post-ramp year, a customer may leave by paying 36 months of minimum charges [114].
Figure B.4. Supply commitments often run longer than the customer contracts behind them. (a) Commitment lengths, each from its own source; (b) one utility tariff's load ramp, with its cap on the minimum bill drawn apart. Public reported values; different scales; see sources. In context: Appendix B.3Open full size: Figure B.4
Two bar panels in gigawatts, each with its own scale. Dominion Energy, as of July 2025, reports data-center contract capacity of 9.8 GW under electric service agreements, 7.1 GW under construction letters of authorization, and 30.1 GW under engineering letters of authorization, labeled potential future load [92]. CoreWeave reports about 3.1 GW of contracted power at the end of 2025, against more than 850 MW active [68]. Filling squares mark firmness in each source's own order. The panels are not comparable and the tiers are not added.
Figure B.5. Power reported by firmness: contracted far ahead of what is under construction or active. Two sources, two kinds of figure, two scales. Public reported values; see sources. In context: Appendix B.4Open full size: Figure B.5