Recommendation statuses¶

Every recommendation moves through a defined set of statuses as the team reviews and acts on it. Some statuses are set by users; others are set automatically by the engine.

Status reference¶

Dismissed and Implemented cannot be set manually. Both are set exclusively by the engine.

State transitions¶

Users can move a recommendation to the following statuses from each starting point:

Moving a recommendation back to New clears all lifecycle metadata (snooze date, reason, accepted tier, ticket, and target date).

What each transition does¶

In Review — the champion opens a conversation with the resource owners. Use this when you have sent a message or raised a ticket, and the team is actively evaluating the recommendation.

Planned — the team has confirmed they will implement the recommendation. When setting Planned, you can optionally record a ticket reference (Jira, Linear, or any URL) and an implementation target date. Both are shown on the recommendation detail page while the status is Planned or Implemented.

Snoozed — the team wants to revisit the recommendation at a specific date. A snooze always requires a future date. When the date passes and the engine runs, the recommendation moves to Resurfaced if the condition still applies. Snooze is per-recommendation: other recommendations for the same resource are not affected.

Ignored — the team will not act on this recommendation. Use this when the resource requires a specific SKU for performance, compliance, or contractual reasons and the recommendation does not apply. Marking a recommendation Ignored requires selecting a reason category (Too risky, Not now, Wrong data, or Other). It does not expire and does not affect other recommendations on the same resource.

What the engine updates per status¶

When the recommendation engine runs, it only modifies a recommendation if its status permits it. This controls how pricing changes, SKU ladder changes, or updated metrics affect a recommendation that the team is already working on.

Why user-managed statuses are frozen¶

Once a recommendation reaches In Review, the team has started a conversation — with the resource owner, in an email thread, or in a planning meeting. The savings figure has been shared. Allowing the engine to silently revise that figure after the conversation has started would make the data inconsistent with what was communicated, and would undermine confidence in the numbers.

The same reasoning applies to Snoozed and Ignored: the team made a decision based on a specific savings figure and a specific recommended action. If the underlying pricing data changes, that does not retroactively invalidate the decision. The original figures are preserved so the decision can be understood in context.

Why New, Grouped, and Resurfaced are not frozen¶

No user action has been taken on these recommendations yet. The team has not discussed them, and no figures have been shared externally. Keeping the data current is more useful than preserving an older calculation.

Grouped means the recommendation has been placed under an initiative for tracking, but the Champion has not yet reached out to the resource owners. The status reflects organizational grouping, not user intent about the recommendation itself.

Stale conditions on user-managed recommendations¶

If the condition that triggered a recommendation resolves while the recommendation is In Review, Planned, Snoozed, or Ignored, the engine does not change the status or zero out the savings. The recommendation stays in its current status with its original figures intact. The team can see in the History tab whether the underlying condition has changed by reviewing recent engine runs and inventory snapshots.

For New, Grouped, and Resurfaced recommendations, the engine dismisses them automatically when the condition no longer applies.

Snooze vs Ignored¶

Both Snoozed and Ignored defer action, but they are different:

• Snoozed always has an expiry date. On that date, if the condition still exists in the estate, the engine resurfaces the recommendation automatically.
• Ignored has no expiry. The team has made a deliberate decision not to act. The recommendation stays Ignored until someone reverts it to New.

Dismissed vs Ignored¶

Both remove a recommendation from the active list, but they come from different sources:

• Dismissed is set by the engine when the underlying condition no longer applies — for example, the resource is now properly utilized, or it has been terminated. The team did not act; the problem resolved itself or the resource changed.
• Ignored is set by the user. The condition may still apply, but the team has decided not to act. The engine does not automatically clear Ignored recommendations.

How Implemented is detected¶

The engine checks each Planned recommendation on every run. For rightsize and scale-down recommendations, it compares the resource's current SKU in the latest inventory snapshot against the recommended SKU (or the agreed SKU if a tier override was set). If they match, the recommendation moves to Implemented automatically. For terminate recommendations, the engine checks whether the resource is still present in the estate.

Implemented items are used to calculate realized savings — the total savings from changes that are confirmed to be in place.

Tier override¶

For scale-down and rightsize recommendations, the champion may agree to a partial change with the resource owner. For example, if the engine recommends moving from P3v3 to P1v3, but the team agrees to move to P2v3 instead, the champion can record this as the agreed tier.

The tier override is available only when the recommendation is in In Review status. Opening the status modal shows a tier picker with all available tiers in the same SKU family, along with the estimated monthly savings for each. The savings figure updates in real time as you select a different tier — no engine run is required. When you save, the agreed tier is stored on the recommendation and the savings figure is recalculated immediately.

The engine uses the agreed tier (not the originally recommended one) when checking whether the recommendation has been Implemented on subsequent runs.

Planned fields: ticket and target date¶

When moving a recommendation to Planned, you can record:

• Ticket — a reference to a work item in Jira, Linear, or any other system. Enter the ticket key or a full URL. URLs are displayed as clickable links.
• Implementation target date — the date by which the team expects the change to be in place.

Both fields are optional and visible on the recommendation detail page while the status is Planned, Snoozed, or Implemented.

Resource exemptions¶

An exemption prevents the engine from creating new recommendations of a specific type for a resource. For example, if a VM must stay on its current size for compliance reasons, you can exempt it from rightsize recommendations while still receiving terminate or scale-down recommendations if they apply.

Exemptions are per resource and per recommendation type. To exempt a resource from all recommendation types at once, use the Exempt all button in the Exemptions panel.

Setting an exemption from the inventory page: open a resource in the Inventory section, scroll to the Exemptions panel, and click Add exemption. Select the recommendation type and enter a reason.

Setting an exemption from the recommendation detail page: open a recommendation in In Review, Planned, or Snoozed status and use the Exempt action in the status panel.

When an exemption is in place:

• New recommendations of the exempt type are created as Dismissed with the exemption reason recorded.
• Existing recommendations already in In Review, Planned, Snoozed, or Ignored are left untouched — the engine does not override user intent.

To remove an exemption, go to the resource's Exemptions panel in the Inventory section and remove the relevant row. The next engine run will create a new recommendation if the condition still applies.