From optimisation candidate to approved decision
This walkthrough follows one important motion: how CloudKnife surfaces optimisation opportunities, ranks them for review, and carries evidence through to an approval or hold. It complements the platform story with concrete queue behaviour, what reviewers see in product, and what happens after someone says yes.
Inside one optimisation decision
After you scan the list, this is the surface a reviewer uses: assumptions, resources, Confidence, and status in one place before approve, reject, or hold.
CPU stays below the safety buffer, and tail behaviour remains stable in the decision window after review.
Ownership and policy boundaries stay visible for audit and review.
- Evidence and assumptions
- Impact and affected resources
- Safety headroom and risk context
Optimisation-specific fields stay together so approvers see savings, safety, and ownership without switching tabs.
One motion: ranked candidates, one review surface, then action only where policy allows.
Optimisation types you will see in the queue
Six recurring candidate shapes. Same review row pattern for each; grouping is only how you scan the catalogue.
Rank weighs savings you can challenge, environment and tier, and how much review each item needs, so the top of the list matches how FinOps and engineering prioritise together.
Capacity and runtime
What runs, when it runs, and how you pay for capacity.
Rightsizing
Surfaces SKUs or tiers that overshoot observed load. Review checks headroom and production tier before any change.
Runtime alignment
Surfaces off cycles or scale windows for steady patterns. Review pairs impact with change windows and blast radius.
Reservations and commitments
Surfaces lock-in options with break-even against on-demand. Review brings finance and the owning service into one line item.
Hygiene and fit
Cleanup, better-fitting services, and placement under your rules.
Idle and orphaned resources
Surfaces spend with weak or missing ownership. Review confirms intent and routing before cleanup work.
Service and architecture fit
Surfaces simpler or cheaper services when constraints allow. Review matches workload needs to the suggestion.
Region and placement
Surfaces placement differences under governance and latency expectations. Review keeps policy visible next to savings.
Why an optimisation is safe to approve
Governance is not a separate screen. It sits on the candidate so reviewers see savings next to blast radius, policy, and owners.
Rationale and expected impact, built for decision-making.
Optimisation starts as observation and candidates in queue. Nothing executes until your review rules allow it.
Each item states why this change is reasonable here, what evidence supports it, and what could go wrong if assumptions are wrong.
Prod versus non-prod, critical tiers, windows, and blast radius stay visible in the same item as the optimisation, so approvers see policy and savings together.
Routing and accountability stay with the candidate so the right service team approves before work reaches production.
From optimisation candidate to governed action
Detect, rank, review, execute only where your rules allow.
Usage, configuration, and ownership context feed optimisation detection, starting from read-only access where that applies.
Candidates sort by impact, risk, and how much review they need, so the queue matches how FinOps and engineering actually prioritise work.
Open an item to see rationale, resources, Confidence, and policy context together before approve, reject, or hold.
Approved optimisations move to governed automation or tracked manual change, depending on rules you set, not a silent default.
Start read-only, run the queue with your teams, then widen approvals and automation where policy supports it.