FinOps Recommendation Titles Now Say What to Do

A recommendation title is where cost visibility either lands or doesn’t. “EBS volume vol-1 is not encrypted at rest” states a fact. It doesn’t state what to do about it, so every person who scans that list has to do the same small translation from finding to action, one recommendation at a time, forever.

FinOps is the practice of giving engineering, finance, and product teams shared, real-time visibility into cloud cost so spending decisions get made where the usage happens. ZopNight’s recommendation titles now lead with the action instead: “Encrypt EBS volume.” The drawer underneath separates what was observed from what’s recommended, so the fact that justified the action is still there, just not standing in front of it.

1,563 Recommendations Across 53 Rules Were Measured, Not Assumed

All 660 registered rules now declare an action-first headline. 161 of those were reviewed directly against their source workbook. The remaining 393 were extrapolated from each rule’s own prose. A rule’s existing description already implies what the fix should say, once someone reads it that way.

The scale of the fix is the part worth sitting with. This wasn’t checked against a handful of sample rules picked because they were easy to verify. It was measured against 51,228 production recommendations, pulled from 16 real organizations. The visible gap, meaning recommendations whose title still described the problem instead of the action, came out to 1,563 recommendations across 53 rules. That number is zero now, not because the rules were rewritten by hand one at a time, but because every rule was required to declare the action-first form as part of shipping this release.

Severity and Observation Are Resolved on Read, Not Stored

The drawer’s copy, the reason a recommendation carries a given severity and the observation that backs it, isn’t written once and saved. Three fields, a severity reason, an observation, and the recommendation itself, are transient: none of them are persisted anywhere. Each one resolves at read time from the rule’s own declarations.

That choice pays off in two ways that a stored-copy version wouldn’t. A rule that later gets retired carries no orphaned reason text sitting in a database somewhere, because there was never a stored copy to orphan. And a copy edit to how a rule explains itself applies to every recommendation that rule has ever produced, instantly, the next time any of them is read, with no backfill job needed to touch old rows. This works when a rule’s own declaration stays in place for every read that needs it. It fails if that declaration goes missing, since there would be nothing left to resolve.

Severity Gets a Sentence, Confidence Gets a Word

Severity used to be a colored label with no explanation attached. It now comes with a sentence stating why that severity applies to this specific finding. Confidence moved the other direction: what used to be a percentage next to a bar now reads as High, Medium, or Low, a coarser scale that’s honest about how much precision a confidence estimate actually deserves. A new ResourcePanel consolidates a resource’s identity and region into one place at the top of the drawer instead of scattering them through the surrounding text, and attributes and tags now show as chips with room to expand for the full list. Excel exports gained a Confidence column to match.

None of This Needed a Migration

The whole change ships scoped to the recommender’s model and rule declarations, plus the app’s recommendations drawer and list. No migration, no new environment variable. That’s not an incidental detail. It’s the direct payoff of resolving severity reason and observation on read instead of storing them: a fix to how a rule explains itself doesn’t need a backfill script to reach recommendations that already existed, because nothing about those recommendations was ever frozen in the first place.