Stage 5 — Learn
What one observation contains
A reconciled product produces a record with four parts. Missing any one of them makes it useless for calibration, which is why reconciliation is a step rather than a glance at a dashboard.
| PART | WHERE IT COMES FROM |
|---|---|
| The estimate | The committed baseline, with its P50, P80 and the assumptions recorded during Stage 1. |
| The actual | Attributed spend for a settled period — a full month, not a partial one. |
| The gap | Actual against P50, as a signed percentage. Direction matters as much as size. |
| The attributes | Team, domain, workload type, whether it was a migration or greenfield, whether it used serverless. |
What usually predicts a gap
Estimation error is rarely random. It clusters, and the clusters are legible once you have a handful of observations.
- Workload type. Streaming and continuous pipelines are the most common source of underestimation, because a 730-hour month is easy to say and hard to picture.
- Migration versus greenfield. Migrations are estimated against a known source system and tend to land close. Greenfield work spreads wider in both directions.
- Team. Consistent bias by team is common and is usually about how the team interprets the questions, not about their engineering.
- Serverless adoption. Serverless shifts cost from predictable VM hours to consumption that depends on data volumes, which widens the band.
Running the stage today
- Pick settled products. A product in production for at least one full billing month, with attribution complete. A partial month or an unattributed half produces a gap that measures your setup rather than your estimating.
- Record the four parts above, per product, in whatever your FinOps practice already uses for review.
- Look for direction before size. Five products all 15% over is a systematic bias worth correcting. One product 300% over is a specific story worth reading, and averaging the two together loses both.
- Feed it back as an assumption. When the estimator asks about a streaming pipeline for a team that has run three of them, the honest input is what those three cost — not what the model would guess unaided.
Cadence
Quarterly is usually right. The stage needs settled bills, and a monthly review mostly re-reads products that have not changed. What is worth doing every month is checking that attribution is still complete — an untagged cluster added in the meantime removes a product from this stage entirely, and does so quietly.
Why this is the outer loop
The inner loop protects a delivery: it runs on pull requests and keeps one product inside the budget agreed for it. This loop protects the next delivery. It runs once per product, and its output is not a verdict but a better prior.
A team that has run both loops for a year estimates differently. Not because the tool got smarter, but because the gap between what they guessed and what they were billed stopped being invisible.