Outcome
By the end of this lesson, you will be able to distinguish the status and resolution_state columns, interpret the six ways they can disagree, and explain why both error directions occur in real estates.
| Tier | Engineer |
| JTBD | ”Stop reporting savings we did not capture, and stop missing savings we did.” |
| Personas | Platform Engineer · FinOps Lead · Engineering Leader |
| Prerequisites | M2.13.L1 |
| Time | 9 minutes |
| Bloom verb | Distinguish (Analyze), Interpret (Understand), Explain (Understand) |
1. Concept
One idea carries this entire module:
statusis a claim.resolution_stateis a fact.
They are two independent columns, and the whole point is that they are allowed to disagree.
status what the customer SAID they did applied / dismissed / optimised Set by a human clicking a button.
resolution_state what we MEASURED verified_adopted / verified_unchanged / verified_diverged / verified_reverted / abstained / pending Set by a probe reading the estate.A single column cannot carry both, because they answer different questions and they are wrong in different directions.
The six disagreements
status resolution_state what actually happened──────────────────────────────────────────────────────────────applied verified_adopted They clicked, and the estate changed to match. The good case.
applied verified_unchanged THEY CLICKED AND NOTHING CHANGED. This is the lie the two-column model exists to kill.
applied verified_diverged They acted, but differently from what was asked.
optimised verified_adopted Silent adoption. They fixed it and never told us.
optimised verified_unchanged Our rule stopped firing and nothing was fixed.
dismissed verified_adopted Dismissed, then fixed anyway. The reopen cooldown must not reopen this one.Both error directions are real, and they were measured
This is not a hypothetical design exercise. One enterprise audit found:
FALSE POSITIVES 2 of 3 recommendations marked `applied` were false. The resource was still exactly what the rule flagged. The team had stopped the instance three weeks later, for unrelated reasons, and the click had changed nothing at the time it was made.
FALSE NEGATIVES 36 resources had genuinely changed to match their recommendation. The status field called none of them `applied`.Over-claiming and under-claiming were both happening in the same estate, simultaneously. A savings report built on status alone was wrong in both directions and confident about it.
Why this matters more than it sounds
The number a FinOps team reports upward is “savings captured”. If that number is built on a claim field, then:
- Every rubber-stamped Apply inflates it.
- Every silent fix deflates it.
- Neither error is visible, because nothing disagrees with the claim.
The two-column model does not make the number bigger. It makes it defensible, which is worth more the first time someone audits it.
verified_diverged is the interesting one
THE REC SAID m5.2xlarge -> m5.xlargeTHE CUSTOMER DID m5.2xlarge -> t3.large
Status: appliedresolution_state: verified_divergedThe customer solved the problem. They did not do what was asked. Calling this verified_adopted would overstate our contribution; calling it verified_unchanged would be false. It gets its own value because it is genuinely a third thing, and it is common: engineers who know their workload frequently make a better choice than the rule’s target.
What the model deliberately does not do
IT DOES NOT OVERWRITE THE CUSTOMER'S CLAIM. A recommendation marked applied that the estate contradicts stays marked applied. The verdict sits beside it. We report what we measured; we do not relabel what they said.
IT DOES NOT MANUFACTURE A VERDICT. Where no honest measurement is available, the answer is `abstained`, not a guess. L4 covers the buckets and why roughly two thirds of the catalogue abstains today.That first restraint is a discipline worth naming. It would be easy to “correct” a status that the evidence contradicts, and it would destroy trust the first time the correction was wrong.
Where the verdict is and is not shown
The verdict and the closure reason are the customer’s to read. The engine bookkeeping beside them is not, and the split is on the surface rather than on permissions (L1). Where a status genuinely cannot be reconstructed, the feed says so rather than inventing one.
2. Demo
The audit that produced the numbers above, walked through:
ORG: 340 recommendations closed in the last two quartersREPORTED SAVINGS, from `status` alone: $84,200/mo
AFTER VERIFICATION RAN
applied + verified_adopted 61 recs $31,400/mo Genuine. Clicked, and the estate moved.
applied + verified_unchanged 44 recs $28,900/mo CLAIMED AND NOT CAPTURED. The single largest line, and it was being reported upward as real.
applied + verified_diverged 18 recs $9,100/mo Real savings, different shape. The customer picked a different instance family than we suggested. Counted, with the divergence noted.
optimised + verified_adopted 27 recs $11,300/mo SILENT ADOPTION. Nobody clicked anything. These were invisible in the old report and are real money.
optimised + verified_unchanged 52 recs $0 The rule went quiet. Nothing was fixed.
dismissed + verified_adopted 9 recs $3,500/mo Dismissed as not applicable, then fixed anyway.
abstained 129 recs n/a No honest verdict available (L4).
DEFENSIBLE FIGURE adopted + diverged + silent adoption $31,400 + $9,100 + $11,300 + $3,500 = $55,300/mo
Reported before: $84,200/mo Defensible: $55,300/mo Over-claim: $28,900/mo (34%)
THE PART NOBODY EXPECTED $14,800/mo of the defensible figure came from recs the old report counted as ZERO: silent adoptions and dismissed-then-fixed. The correction was not purely downward.The last block is why this lands with FinOps teams rather than being resisted. It is not an accusation; it is a better instrument, and it finds money in both directions.
3. Hands-on (6 min)
1. Pull your closed recommendations for last quarter. Total reported savings from status: $________
2. Split by resolution_state: verified_adopted ____ recs $________ verified_unchanged ____ recs $________ verified_diverged ____ recs $________ abstained ____ recs n/a
3. Your defensible figure (adopted + diverged): $________ The gap against line 1: $________ Gap as a percentage: ________%
4. Find one `applied` + `verified_unchanged` rec. Open its History (L1). Was there a reopen? Y / N Ask the person who applied it what they did: ______________________________________________
5. Find one `optimised` + `verified_adopted` rec. This is money you fixed and never counted. How much? $______4. Knowledge check
Q1
A recommendation shows status = applied and resolution_state = verified_unchanged. ZopNight’s handling:
A. Corrects the status to open, since the evidence contradicts it
B. Deletes the recommendation
C. Reopens it automatically after a cooldown
D. Leaves the claim standing and records the verdict beside it
Show answer
Correct: D. The two columns are independent by design: we report what we measured without relabelling what the customer said, so the disagreement stays visible rather than being resolved silently in either direction. Overwriting a customer-set status would destroy trust the first time the correction was wrong. Making the disagreement visible is the entire point: this exact combination was the largest single line in the audit, at $28,900/month being reported as captured.
Q2
An enterprise audit found 36 resources that had genuinely changed to match their recommendation, none of them marked applied. This is:
A. The false-negative direction of the same problem
B. A bug in the status field
C. Expected, since only ZopNight-initiated changes count
D. A discovery lag
Show answer
Correct: A. Silent adoption is invisible to a status-based report, so the old figure was wrong in both directions at once: over-claiming on rubber-stamped applies and under-claiming on fixes nobody reported. This is why the two-column model is not purely a downward correction. In the worked audit, $14,800/month of the defensible figure came from recommendations the old report counted as zero.
Q3
A recommendation asked for m5.2xlarge → m5.xlarge. The customer moved the resource to t3.large instead. The correct verdict:
A. verified_adopted, since the resource was rightsized
B. verified_unchanged, since the target was not met
C. abstained
D. verified_diverged
Show answer
Correct: D. They acted, differently from what was asked Calling it adopted overstates our contribution and calling it unchanged is false, so it is a third value: engineers who know their workload frequently pick a better target than the rule’s. Diverged findings still count toward the defensible savings figure; the divergence is recorded so the contribution is described honestly rather than claimed as ours.
5. Apply
Rebuild your last savings report with resolution_state as the filter rather than status, and present both numbers side by side the first time. The gap is the credibility of every future number you report, and the silent-adoption line is usually enough good news to carry the conversation.
Related lessons
- L1: The recommendation timeline
- L3: Frozen baselines and declared observables (next)
- L4: The seven verification buckets
- T2.M2.2.L4: When evidence disagrees with the bill
Glossary terms touched
resolution_state · verified_adopted · verified_diverged · Silent adoption