REALIZED SAVINGS LEDGER

How we count a saving.

Every "savings" metric on this site passed through four filters. Without all four, we don't count it as recovered. Audit knows the criteria, sales knows the criteria, and it doesn't change.

1. I.

   There is an approved CR

   Without dual approval recorded in the audit log, nothing counts. A suggestion is not a saving. An insight is not a saving. A recommendation in the inbox is not a saving. It only becomes a saving when two human approvers from your organization have signed the change request and it has been executed.

2. II.

   There is a pre and post measurement

   Resource cost is captured 4 weeks before and 4 weeks after execution, in contract currency. If the pre-post window doesn't cover 4 stable weeks on both sides, the row sits in "pending verification" and doesn't enter the ledger until it does.

3. III.

   The delta is positive and materially attributable

   Variance isolates the CR effect from other movements (price, mix, new) that ran in parallel. If it can't isolate — because a price hike or a new workload contaminated the post window — the row goes in as "inconclusive" and doesn't add up. Materially attributable means: the CR effect is the dominant explanation for the difference.

4. IV.

   It is in the Realized Savings Ledger

   Immutable row, linked to the CR, the pre evidence, and the post evidence. Auditable end-to-end. The ledger is the single source behind every number that leaves here — including console counters and sales-material totals.

Why this rigor

Unproven savings are vendor fiction. We've bought FinOps software that reported "$X saved" because someone recommended turning off a VM — and later discovered the VM had never been turned off, or had been turned off for another reason, or had a workload migrated elsewhere with the cost coming back through the side door. The ledger exists so we don't make that mistake with you.