3. What is published, and what it leaves open

In short: the formula is published. What this paper adds, as far as the sources I could read show, is a rule tying each supply order to how firm a launch is. It also adds the governance that keeps the numbers true.

Before redesigning an intake, look at what's public: three families of work, which differ mainly in when they decide.

The closest prior art, and the base for much of this paper, is Hixson and Guliani's 2015 article [6]. It treats capacity planning as one problem seen by engineering, product and finance, and asks for the fewest drivers that capture most demand. It suggests weighting actions with "costs" so they normalize into one driver, and builds blow-up factors from design choices. Both are early forms of this paper's coefficient. It asks product to project usage "in the growth dimensions used by the engineering model," and ties the planning horizon to resource order time. It also asks finance how confident the models are. Demand that hasn't resolved, it answers with fungibility. For example, it suggests "building out datacenter space based on past growth trends for the company, but not deciding which product you would fund until right before the machines landed" [6].

This paper works inside that frame and adds mostly mechanics. It works the fungibility answer out layer by layer (Sections 5.4 and 6.5), and adds the governance that keeps the numbers true (Section 9). Charging cost to the callers who cause it, and formal sign-off among the three perspectives, are outside the article's scope; they take most of this paper's words.

Others name pieces. Auxon's performance data state "for every unit of demand X in cluster Y, how many units of dependency Z are used?" [1]. ITIL, the FinOps Foundation, sales and operations planning and the standard capacity texts name the parties and stages [19–24]. The FinOps Foundation's data center guidance, added in 2025, also notes planning horizons "typically requiring months or years of lead time" [19–24].

The discipline is older than any of them. Its oldest root may be telephone engineering: Erlang's 1917 formula for loss and waiting time was soon used by telephone companies in many countries [A1]. Cockcroft and Walker's 2001 book is described, in its publisher's words, as treating capacity planning as "a well known discipline, particularly for sites that have a mainframe oriented background" [25]. Gunther made it tactical in 2007, forecasting from whatever performance data is at hand [26], and Allspaw brought it to web operations in 2008 [24]. At SREcon24, two Elastic engineers argued it should become a more prominent SRE skill [27].

The second edition of Site Reliability Engineering (September 2026) has a capacity planning chapter by Gordon, Kirby, Hixson and colleagues; Hixson co-wrote the 2015 article too. The chapter says it explains how Google tackles "operational and mid-term capacity planning" [7]. It splits inorganic demand into planned and unplanned, and asks for probabilistic forecasts and backtesting. It turns an unconstrained forecast into a "capacity plan of record (PoR)" under supply's real limits [7]. It also covers pooling across services, reclaiming stranded capacity and shaping demand to fit supply. Its two case studies cover Google Meet during COVID-19 and scaling for AI [7]. Much of what this paper builds on is there first, and the sections below say where. When this paper calls a topic missing from the published record, that includes the chapter.

The form has converged; it hasn't been solved, and the authors say so. In 2022, tracing covered 52% of capacity usage in Flux, with over 90% expected with adoption. Flux's residual (Section 2's δ) is 3–5% for a stateless web product. For database infrastructure it fell only from 22% to 15%, "primarily due to improved attribution accuracy and coverage," and load-test models cover 46.4% of capacity [2]. Netflix reports that "Services can have multiple owners, cost heuristics are unique to each platform" [28]. Dapper warned that with coalesced work "a traced request can be blamed for a deceptively large unit of work" [12]. I found no published time series of coefficient drift.

How were the errors shrunk? Flux's authors "improved planning accuracy significantly, primarily by working with service owners to improve their attribution and capacity models" [2]. Borg's users "overbuy" quota as insurance [17]. Flux's first author recalls that before it, each ordering cycle was a negotiation between planners and service owners, "leaving nobody happy in the process" [29]. These are facts about people, reported in engineering papers. Microsoft's researchers describe the supply side the same way. They note that "Cloud supply chain operations were largely executed manually due to their complexity and dynamic nature" [A2].

Step-change demand has a smaller public record, mostly about who supplies the number. Hixson and Guliani define organic growth as coming from "the natural adoption and usage of your product by customers" and inorganic as "step changes, likely the result of a feature launch, a marketing campaign, or business-driven change to how your product is being used," and advise keeping step changes itemized [6]. Google SREs sketched the split in 2020: add planned new consumers to the organic forecast, and make the service behave reasonably under unexpected demand [30]. The 2026 SRE chapter, with Hixson among its authors, splits inorganic demand in two [7]. Planned demand is launches, promotions and known events such as Black Friday, accounted for "during launch planning" [7]. Unplanned demand is viral trends and news, met with buffers, autoscaling and demand shaping [7]. Hixson and Guliani warn of "a very natural tendency to overstate the potential upside of a launch," and suggest planning for only some of several launches to succeed [6]. Operators add detail:

• A Google data science team describes customer forecasts as capturing "future inorganic growth events or trends that are difficult to extract as features for a predictive model," reconciled monthly between customers and finance into base and high scenarios "so that all downstream teams could confidently execute according to the high scenario forecast," with misses traced to "the consensus forecast of record at lead time" [8].
• Meta's planners give the forecast to products ("Products forecast capacity: They tell us what they want, how much of it, and where") and the promise to infrastructure [31]. They frame it as an agreement: "Capacity contracts are the commitments between Meta Capacity Planning, Platforms, and Products" [31]. This paper extends the idea from the amount of capacity to the coefficient and rate behind its price.
• Netflix predicts new titles from "various internal and external forecasts" and will "use human judgement to pin certain upcoming titles high in the popularity ranking to ensure that we have adequate capacity to serve them" [32].
• Alibaba, planning a one-day shopping event, concluded that "Capacity can be predicted, but cannot be planned for, and we can only limit it," and set hard limits on transaction throughput [33].
• A practitioner account replaces machine counts with "expected traffic growth, data ingestion, retention, replication" and deducts a team's idle capacity from its future forecast [34].

Outside computing, Kahneman and Lovallo trace optimistic forecasts to an "inside view" that "anchors predictions on plans and scenarios" and neglects "the statistics of the past" [9]. Flyvbjerg's reference class forecasting bases a project's forecast on the outcomes of comparable past projects [10].

So the sources agree: step changes are declared, declarations run optimistic, and someone must hold them to account. What I haven't found, in the sources I could read, is a rule tying each supply layer's commitment to the stage a declaration has reached by that layer's commit point. That's the last date its order can be placed. Sections 5.4, 6.5 and 8 propose one. The closest public pieces are in the 2026 chapter. It asks for percentile forecasts and backtesting to choose a "target confidence level," and for supply's limits "at different time horizons" [7]. So the chapter has the ingredients. As far as I can read, it doesn't combine them into one rule per supply layer, tied to how firm a launch is when that layer must be ordered. If it does, I'd welcome the correction. Figure 6 places the published families by when they decide, on Hixson and Guliani's frame.