Your FY27 AI number locks in November. Right now it’s a guess.

Cloud is smooth because a server-hour is consumed every hour whether anyone shows up. AI spend is decided — someone chooses to start an agent — so it arrives in bursts of wildly different size.

Croston, and the Syntetos–Boylan refinement of it, are the published methods other industries use once demand stops arriving smoothly and starts showing up in occasional bursts of variable size — landing gear, not milk. Whether AI spend formally fits that same shape is untested: nobody, including us, has run the numbers on real AI usage.

So the deliverable isn’t a better trend line. It’s a range with named assumptions, and how much of it to commit forward versus leave on pay-as-you-go.

Layer one: was it consumed at all? Commits, expiring credit pools, and per-seat allowances all get billed as spend whether or not anyone uses them. Gas markets have a whole function that checks whether a buyer consumed what it committed to; AI billing has none, so a credit pool expires unused on one team while another pays overage the same month.

Layer two: was the consumption productive? An agent retry loop, a wrong-model default, and a debugging spiral all draw down the same balance as work that shipped — waste and necessary iteration are the same event in billing data. One vendor survey puts the waste share at roughly 1 in 4 AI dollars (Harness, Jul 2026, N=700) — a vendor’s own estimate, not something anyone has measured on their own spend.

So the deliverable is a consumed-versus-bought figure for every instrument you hold — what each commit, credit pool and seat allowance was billed for against what was actually drawn down — and the same period split into work that shipped versus retries. Nobody has published that ratio on real spend. The first company measured gets the first one.

Outcome-per-spend requires observing the work an AI dollar produced, and no invoice, dashboard, or usage report captures that — only the spend. It’s a structural, industry-wide gap, not a discipline problem any one team can solve alone.

Here’s the path: measure the work inside the agent loop, the only place it’s observable — not the invoice.

A bill identifies price × work delivered as one number, never the two separately. Price is printed; capability per token is not.

Three tiers sit between a model and your bill, and only the last one is yours. The people who make these models set a list price. The people who sell them to you — a cloud reseller, or the tool your developers actually open — set what you are charged per, the markup on it, and often which model runs by default. They can change any of that in a month when no list price moved at all. Your own teams set how much gets used.

A vendor-or-us split has nowhere to put that middle tier, so it charges the whole amount to your teams and the variance report points at the wrong door.

There’s a second gap under the three tiers: nothing classifies a change as one-time or likely-to-continue — the split the audit committee already requires for every other material variance. Absent a timestamp on the work itself, a deliberate optimization and a silent quality regression are the same event in the billing data.

The decomposition — price, volume, mix, and capability — split out individually, tagged with which tier moved it and whether the move is one-time or likely to continue. Provable from any billing export, not a survey stat.