DOCS / GOVERNANCE

Cost rules

Three types. One measures a level — the product's total against its own budget. Two measure a movement — how much this change adds. They answer different questions, so a budget never displaces an increase cap.

The three types

RULE	MEASURES	THRESHOLD COMES FROM
Budget exceeding	The product's projected monthly total.	The product's own budget. The rule carries no figure.
Max cost increase ($)	How much this change adds per month, as an amount.	A number you set on the rule.
Max cost increase %	How much this change adds, as a percentage of the previous total.	A number you set on the rule.

On the wire, the CLI receives them as:

cost:
  currency: USD
  thresholds:
    - name: Budget exceeding
      type: absolute
      value: 400          # filled in from the product's budget
      action: block
    - name: No large jumps
      type: increase_absolute
      value: 50
      action: block
    - name: Soft growth warning
      type: percentage
      value: 20
      action: warn

Budget exceeding

A ceiling on the product's whole projected total, and the figure is always that product's own budget. The rule has no threshold field at all.

NOTE

A number on the rule would be a figure an administrator could set, review and approve while something else stopped the build. One ceiling, set where the money is agreed — which is at Commit, on the product.

The threshold is emitted only when all three of these hold:

A budget rule reaches this product through a policy.
The run resolves to a registered product.
That product has a budget.

Miss any one and no ceiling is emitted. The total is still reported, the run is still recorded, and nothing about cost stops the build. A rule that invented a ceiling for an unbudgeted product would be enforcing a number nobody agreed to.

A budget of zero is a real budget

Zero means any spend is an overrun, which is the opposite instruction from having no budget. Finowl distinguishes the two, so a product deliberately capped at zero is enforced rather than skipped.

Per-product severity

A product can carry its own budget enforcement setting, and it takes precedence over the rule's severity. That is how one organization runs the same budget rule as warn for exploratory products and block for the ones with a signed budget, without maintaining two policies.

Where a product sets nothing, the strongest severity among the rules that reached it wins. The same rule arriving through an organization-wide policy and one assigned directly collapses into one threshold, so no product is measured twice against one number.

Max cost increase ($)

Measured against the change, not the total. A product sitting at €90 against a €400 budget has plenty of headroom, and a single commit adding €200 a month is still worth stopping to look at.

Max cost increase ($)   increase_absolute   50.00   58.40   BLOCK

This is the rule that catches a cluster resize in a review. The budget rule catches accumulation over months; this one catches a step.

IMPORTANT

Until version 0.2.0 this type shared the absolutekind on the wire with the budget ceiling, which meant an increase cap was evaluated against the product's total and then deleted by any budget rule — a rule that did neither thing its name said. It now has its own kind, increase_absolute.

Max cost increase %

The same measurement expressed relative to the previous total. Useful where absolute amounts vary widely across products in one organization: 20% means something comparable to a €40 product and a €4,000 one.

Its weakness is the mirror image: 20% of a small product is a rounding error, and a new product going from nothing to something is an infinite percentage. Pair it with an absolute cap rather than relying on it alone.

Choosing thresholds

YOU WANT TO CATCH	USE	STARTING POINT
A product outgrowing what was funded	Budget exceeding	block, once the product has a committed budget
One expensive change slipping through review	Max cost increase ($)	warn at roughly 10% of a typical product's budget, then tune
Steady growth nobody notices	Max cost increase %	warn at 20%, and expect noise on small products

Start every rule at warn and read a fortnight of runs before promoting it. The threshold that looks obvious from a spreadsheet is usually wrong by a factor of two in one direction or the other, and finding out with block set costs somebody a blocked release.

How the guard evaluates them

Cost rules are evaluated against the diff between the deployed state and the planned bundle, at the P90 total rather than the midpoint.

A gate that fires only when the expected case breaches the budget lets through every change whose expected case sits exactly at the limit — which is most of them, because teams size to their budget.

When the plan shows no cluster changes, the cost check reports no movement rather than re-litigating a total nobody touched. When no cost rule reaches the product, the check is skipped and says so, and governance rules still run.

Details of the verdict output in finowl guard.

PREVIOUS

Policies and rules

NEXT

Governance rules