Stage 2 — Commit
Why it is a single act
Approving an estimate and setting a budget could be two steps. They are not, and the reason is the window between them. In that window an estimate is agreed and no money is allocated: the product looks governed, the board shows a figure, and no rule can fire because there is no ceiling. That state is worse than having neither, because it reads as protection.
Committing therefore does four things at once:
- Freezes the estimate as the baseline for this product.
- Sets the budget to the figure agreed — the P80 by default.
- Records the actor and the timestamp.
- Clears the flag marking the product as having no committed budget.
Before it happens
Until a product is committed, its estimate is a proposal. The product is flagged on the board as having no committed budget, and there is no agreed figure for anything to be measured against. A finowl guard run on that product still checks governance rules, still reports its total, and still records a run — but a budget rule finds no ceiling to apply and drops out of the verdict.
Who commits
The sponsor — the person accountable for the money — or a FinOps officer acting for them. The distinction from Stage 1 is deliberate: the product owner produces the figure, and someone else agrees to fund it. A method where the same person does both has an estimate and no commitment.
What changes afterwards
Two things can move, and they are different acts with different consequences. Confusing them is the most common way a team ends up telling its engineers their code is out of date when nothing about the code changed.
| ACT | MOVES | LEAVES ALONE | REQUIRES |
|---|---|---|---|
| Change the budget | The money. | The estimate and its version. The baseline is untouched. | Nothing beyond the authority to do it. |
| Re-estimate and commit | The money and the baseline. The previous estimate is superseded. | The product, its identity and its full run history. | A reason. It is the only record of why the agreement moved. |
Changing the budget without re-estimating
Legitimate and common. The scope did not change, but the funding did — a department reallocation, a negotiated rate, a decision to accept more risk. The estimate still says what it always said, and it should not be rewritten to match a funding decision it did not cause.
Re-estimating
Legitimate when the work itself changed. It produces a new estimate; committing that estimate supersedes the previous one, which is kept and marked superseded. The reason you supply is what a reader in six months has to work with when they ask why the number doubled.
What Commit hands to Build
A budget the CLI can fetch by product id. That is the entire interface between this stage and the next. When finowl guardruns, it asks the platform for the rules that apply to this product and environment, and a budget rule arrives carrying that product's own figure.
No rule holds a budget number. A rule named “Budget exceeding” has no threshold field at all, because a threshold there would be a figure an administrator could set, review and approve while something else stopped the build. See Cost rules.