DOCS / METHODOLOGY

The Finowl method

Five stages, two loops. Each stage narrows the uncertainty of the one before it and hands the next stage something specific — a figure, an agreement, a verdict, a measurement. Nothing here is advice. Every handoff is a record in the product.

Why the lifecycle and not the invoice

Cloud cost tools are built around the bill, because the bill is the only place the number is certain. The trouble is that certainty arrives after every decision that produced it. By the time a line item is unambiguous, the pipeline is in production, the team has moved on, and changing the cluster means a change request rather than a code review.

The cost of changing a data product does not rise smoothly. It steps. It is nearly free while the shape is still in a YAML file under review. It is expensive once the pipeline is deployed and something downstream depends on its output. It is political once the product is in a business report.

MOMENT	WHO CAN STILL CHANGE IT	WHAT IT COSTS TO CHANGE
During estimation	The product owner, by descoping	A conversation. Nothing has been built.
In a pull request	The engineer who wrote it, in the same review	Minutes. The reviewer is already looking at the file.
After deployment	The team, with a migration plan	Days. Something downstream now reads the output.
After the invoice	Nobody in the room where the invoice is read	A programme. The people who can change it are elsewhere.

Shift-left FinOps means putting the cost question at the top two rows, where the answer is still cheap to act on. Every mechanism in Finowl exists to make it available there: the estimator before the first commit, the CLI inside CI, the budget as a number the pipeline can read.

The five stages

STAGE	PRODUCES	WHO ACTS
1 — Estimate	A versioned estimate with a P50 midpoint, a P80 budget proposal, and the assumptions behind both.	Product owner, architect
2 — Commit	A budget. The estimate is frozen as the agreement, with who agreed it and when.	Sponsor, FinOps
3 — Build	A priced run per pull request, a delta against the deployed state, and a verdict per rule.	Engineers, CI
4 — Run	Actual month-to-date spend, attributed to the product that spent it, next to the projection.	FinOps
5 — Learn	The gap between what was estimated and what was billed, by team, domain and workload type.	FinOps, and the estimator itself

What each stage hands to the next

The method holds together because each handoff is a specific artifact rather than an intention. If you want to know whether a stage actually happened, look for its artifact.

Estimate → Commit.An estimate carrying two figures and its assumptions. Without it, Commit has nothing to freeze and the budget is somebody's recollection.
Commit → Build. A budget the CLI can fetch by product id. Without it, a cost rule has no ceiling and reports a total with no verdict.
Build → Run. A product identity written into finowl.yml and stamped on the compute as an attribution tag. Without it, the invoice cannot be split by product and Run measures nothing.
Run → Learn. A reconciled product: one baseline, one actual, one period. Without it, calibration has no observations and the next estimate starts where the last one did.

Two loops close it

The inner loop — keep this product inside its budget

Runs while the product is being built, on the cadence of pull requests. A change pushes the projection above the committed budget; the guard says so; the team either optimizes the change, descopes it, or goes back to the sponsor and re-commits at a new figure. All three are legitimate. What the loop removes is the fourth option — merging and finding out later.

The outer loop — make the next estimate better

Runs once per product, at reconciliation. Every finished product contributes one observation: what was estimated, what was billed, and the attributes that predicted the gap. Estimates for a team that consistently underestimates streaming workloads start closer to the truth, because the platform has seen it happen.

NOTE

The inner loop protects a delivery. The outer loop protects the next one. A team can run the inner loop from day one; the outer loop only produces anything after the first product reaches production and is reconciled against a real bill.

Where it stops working

Four failure modes account for most of the cases where Finowl is installed and governs nothing. Each has a single visible symptom.

FAILURE	SYMPTOM	FIX
No commitment	The product shows a projection with no verdict. Nothing about cost can fail a build.	Commit an estimate. Until that happens there is no agreed figure to measure against.
Rules in no policy	The rules page marks them Never runs.	Add the rule to a policy and target the environments it applies to.
Only one target worded	`guard` on staging or prod fails the workload gate, naming the computes with no word.	Run `finowl init --target <t>` once per environment the definition declares.
Untagged compute	Actual spend exists but is unattributed, so Run and Learn have nothing to reconcile.	Tag the cluster block, not the job. See Actual cost.

The stages in detail

1 — Estimate

Two figures, not one. Where P50 and P80 come from and why the budget is the P80.

2 — Commit

The single act that turns a proposal into money, and what re-estimation costs.

3 — Build

What the guard checks, what it does not check, and how a verdict is reached.

4 — Run

Two billing sources, one attribution tag, and why either half alone is wrong.

5 — Learn

Turning a reconciled product into a better starting point for the next estimate.

PREVIOUS

Terraform

NEXT

1 — Estimate