8. The commit-point method

In short: one launch, every supply layer, eight steps on one page. For each layer, ask when it must be ordered in a slow case, and how firm the launch will be by then. Then ask what to commit, in what form, with whom owning the rest.

Section 7 shows what goes wrong, not the walk that would have prevented it. A planner who agrees with Sections 5 and 6 still faces a blank page on Monday: which layer first, which number where, who signs what? This section offers that walk. It puts the earlier pieces in order: stages (Section 5.4), supply layers and contracts (Section 6.2), and bridges and pegging (Section 6.4). Then come commit points and change bands (Section 6.5), and the ways a step can miss on either side (Sections 6.6 and 6.7). It's a way to think a launch through, not a model; Appendix A has the one-page worksheet and the full walk-through.

Every supply layer must be ordered by some date, and by then the launch has only firmed up so far. So for each layer ask: when must this be ordered, if the order is slow? How firm will the launch be by then? Given that, what do we commit, in what form, and who owns the rest? Then net against what you have, agree how much the launch may still change at each stage, and write it down where supply can answer it. Figure 33 shows the walk and what it writes down.

1. List the layers and their lead times, using the slow case. Take every layer the declaration touches: power and space, network, each machine shape, parts, turn-up, placement. Write each one's usual lead time and a cautious one, near the slow end of what you've seen (Section 6.2). A public value (Appendix B) is a sanity check, not your number. Why: in my experience (Section 6.2), deliveries are rarely early and sometimes very late.
2. Find each layer's need date and commit point. Work back from launch. The ready-for-service date sits ahead of launch by the testing the launch needs. Each layer's need date is the start of the layer after it; its commit point is that need date minus the cautious lead time. Why: layers stack, so a slow layer's real deadline is earlier than launch day suggests.
3. Read the stage at each commit point, and the range still open. Lay the declaration's stages (Section 5.4) on the same timeline. At each commit point, note the stage reached and the range still open, from the stage's record, not only the team's word. Then ask: is the attribute that drives this layer known by then? Memory drives a high-memory order; region drives power and network. If not, pick one of Section 6.5's three choices and write it down. Where the commit point comes before any declaration exists, as power and shell often do, the portfolio envelope serves that layer; record the launch's claim on it. Why: this question would have caught Section 7's memory problem in time.
4. Choose how far up the range to cover. Use the shortage-to-idle ratio agreed for this layer and kind of demand (Section 10.2), with supply's idle cost and liability terms. That ratio is the cost of running short against the cost of holding spare (Section 6.3). Failing that, start from Section 6.5's illustrative table (for turn-up, the ratio sets how much rate to staff). Convert the point into the layer's units: positions, machines of each shape, turn-up slots. Why: shortage and spare cost differently on each layer, so one level for all is wrong somewhere.
5. Net against what you already have. The net need is the target, minus what's on hand, on order or due back from reclaim, plus capacity due to retire that current load depends on. Each of those is a forecast too, so give each a date and an owner. A deferred retirement can bridge only if its hardware isn't in the space or power the new hardware needs, and a draw on a stocked pool leaves a replenishment owed. Why: each number subtracted is a forecast too, and a reclaim that doesn't happen looks like a supply failure (Section 6).
6. Split each layer into firm, flexible and named. Firm covers up to the base, as a plain order. Flexible covers from the base up to the step 4 target, as options, cancelable or reschedulable orders, or a named launch reserve. Named covers the rest, as a bridge with an owner and a ready-by date and, at the very top, admission control. Figure 34 draws the split. Since the most common timing miss is a slip (Section 6.6), prefer the right to push a delivery out over the right to cancel it. Why: each slice gets the cheapest form that covers it, and none is left without an owner.
7. Agree change bands per stage. With the declaring team, agree how far size and date may move at each stage before the move becomes a priced event (Section 6.5). Supply signs the same bands, because they're its buying assumptions. Bands tighter than the stage's record supports make every launch an exception. Why: a band says when the declaration has left the range supply bought against.
8. Write it down, and get supply's answer. Record the result in four artifacts. The first two are the declaration register entry, with its bands (mechanism 12), and one commit-point map line per layer (mechanism 13). The others are the supply request and supply's answer (mechanism 11), and the fulfillment ledger line, with net and committed columns (mechanism 5). Where a commit point fell before the event that resolves it, add a decision note: what was known, when, by whom, and what would have changed it. Why: an approval is firm only once supply has answered it, and a written decision can be defended later.

This is where "approval is not allocation," the second claim of Section 1, becomes an exchange with two halves.

Planning owes supply six things, per layer and before its commit point. The first three are the net requirement by shape, site and need date; the stage and open range, not just a point; and the signed change band. Next are the substitutes the team will accept (other shapes, other sites, a smaller first phase, a later date). Last come the ramp, not just the peak, and the launch's rank under shortage.

Supply answers each line with a dated commit (quantity, date, confidence, any substituted shape) or a named gap (how much, by when, why, and a proposed bridge with its owner). Until then, the approval is uncommitted (Section 6.1). Pegging each order to its declaration (Section 6.4) lets a late delivery be traced to the launches it hits, and a slipped launch hand its supply to someone else.

Both sides get scored: supply on promised against actual, demand on how much it changed inside supply's lead time. Figure 35 follows one ask across the four parties.

Appendix A walks Section 7's launch through all eight steps, with one added assumption that makes memory scale with the launch's size. A cautious lead time and a real need date move the high-memory commit point to −11, while the launch is still an intent. That's where step 3 catches the missing stored-data question. Who pays for the landing still follows the rule agreed with finance. The table compares the two:

The method doesn't make the launch more accurate. It moves the hard question to the date it was needed, and it gives every surprise an owner. Its cost shows, too. At 40,000, A's growth needs 160 installed cores against 250 held (five machines, sized to the configured 80th percentile of 70,000). So 90 sit idle, about $47,304 a year. Section 7's plan would have left 40 idle ($21,024), so the method's extra machine accounts for about $26,280. That's the plan working inside its 4:1 ratio for persistent demand, and the band records which declaration the spare waited on. Figure 36 draws the two timelines.

Almost nothing in the method is new on its own. Hixson and Guliani supply the frame: "You should plan at least as far ahead as the order time for your resources," use fungibility to delay deciding which product gets the capacity, and keep step changes itemized so the process can learn [6]. Their lead-time table, which ends at "Ready to serve," is step 2 in outline [6]. Olavson's team supplies the base-and-high consensus and execution to the high scenario [8]. Manufacturing supplies netting and time fences (standard practice) and postponement [73]. The operations literature supplies quantity flexibility [70, 71] and chained flexibility [77]. Textbooks supply the newsvendor formula behind the shortage-to-idle ratio [78], and Dixit and Pindyck the option value of waiting [76].

What the method adds, as far as the sources I could read show, is the walk. That's a fixed order of questions applied to one declaration across every layer, ending in signed artifacts. Its new parts would be commit points read against the stage, on a cautious lead time and a real need date, and a standing question about the driving attribute. The rest would be a firm, flexible and named split per layer, bands tied to the stages, and a supply answer per line. The 2026 SRE chapter supplies pieces of the read half (Section 3) [7]. Its Meet case study ran a daily loop asking whether there were enough resources for the load expected a week out [7]. As far as the public record I could read shows, the per-layer walk tied to a launch's stage isn't there.

It's not a model: the ten-outcome lists, ratios and bands write judgment down; they estimate nothing. It's untested: if it works, Section 9.2's tests should show fewer orders placed after their commit point, smaller bridge premiums, and band breaches growing rarer as records build up. It has blind spots: coefficient drift (mechanism 3 catches it), correlated launches (Section 6.6's shared-driver check does) and demand nobody can declare (Section 13). And it's not optimal. Buying to the 80th percentile on one layer and the median on the next is a rule of thumb. It's for layers that work together (Section 6.5, condition 1), not a joint optimum. 7A data scientist could do better.

Three explorations, labeled as such:

• A fast lane. Hixson and Guliani describe one: fungible pooled resources, provisioned "much more quickly than their full lead time" [6]. One way to think about it: Section 7's stocked pool is a fast lane, dearer than the slow lane but able to wait until the launch is configured. Its size is a decision. For example, if configured asks usually move by a tenth of their dated figure, and next quarter's dated asks total 50 machines, start from a pool of about 5 machines. Add cover for its own replenishment time. My guess is that with two lanes, the slow lane can be bought lower than Section 6.5's table suggests.
• Re-pegging. In the walk-through, the six-week slip freed a launch reserve for six weeks. Speculation: across enough launches, re-pegging may absorb a large share of timing misses at almost no cost. 8Nobody has measured it in public, as far as the sources show.
• A simulation. A spreadsheet can stress-test the hand calculation. Draw a few hundred random years from each declaration's stage ranges and each layer's lead-time spread. Then count which launches end up short, and because of which layer. It could show whether per-layer ratios come close to the best joint answer, and what bands and shared drivers change. That's a stress test, not a validation, and its answers would depend on the data used.