Act on a cost finding
Turn an optimization-hunter finding into a defendable, executed saving — without leancosts ever touching your cloud.
1. Find the opportunity
Section titled “1. Find the opportunity”Findings surface in two converged places, both fed by the same hunter fan-out:
- Savings Register (
/savings-register) — the daily landing and your team’s shared decision-of-record. Open findings, cost anomalies, and savings in flight all live here. - Hunters hub (
/optimization-hunter) — a savings-portfolio overview, then per-category pages (Compute, Database, Storage, Network, Observability & AI, Integration) plus the standalone SQL-Migration hunter.
Low-confidence candidates are withheld by default — leancosts ships fewer, trustworthy numbers rather than a wrong one. Each finding carries an estimated monthly impact and a confidence score.
2. Draft a change request
Section titled “2. Draft a change request”Every finding’s primary action drafts a change request (CR) — the signed ledger entry that makes the action auditable. You can draft a CR from:
- a hunter finding,
- the Copilot (when an answer is an actionable saving, it shows “Draft a change request”), or
- an Auto-Remediation Playbook — per-category vetted CR templates, available
as a panel on the Change Requests page (
/change-requests).
The CR is created in draft status with a written rationale, a scope, and the
estimated monthly impact (negative = savings).
3. Submit → approve (dual control)
Section titled “3. Submit → approve (dual control)”The CR lifecycle is draft → submitted → approved → executed:
- Submit the draft. Approval is per-kind — a tag-only approver sees tag CRs to approve, an infra approver sees infra CRs.
- An approver in the allowlist (someone other than the author) signs off. The signatures + rationale become the audit trail that later explains why a month’s variance moved.
4. Apply the change yourself
Section titled “4. Apply the change yourself”leancosts never mutates your cloud. For tag changes it produces a guided CLI
kit (az tag, aws resourcegroupstaggingapi, gcloud); for infra changes it
records the decision. You run the change in your own environment, then mark the
CR executed with the date.
5. Prove the saving
Section titled “5. Prove the saving”Once executed, post the saving to the Realized Savings Ledger (sidebar: Savings): each claimed saving must trace back to its executed CR and a measured before/after cost delta. Claims without evidence cannot be posted. The ledger then feeds the ROI line in your email digest and the Savings Register’s savings report.
The loop, end to end
Section titled “The loop, end to end”hunter finding ─────────► draft CR ──► submit ──► approve ──► you execute ──► realized-savings ledger (Savings Register/Hunters) (rationale + impact) (dual control) (guided CLI kit) (evidence-backed)