Scorecard

The Scorecard (/scorecard) is a one-page summary of what Plutus has surfaced, caught, and watched for your account, organized into six sections. It’s built for the person who has to justify the subscription to whoever signs the renewal, and it’s readable by any role (viewer included) and on every plan tier — this is a look-back page, not a paid feature.

Find it under Account → Scorecard in the sidebar.

The six sections

Each section answers one specific question, shown as its subheading on the page.

• Coverage — “Is Plutus actually seeing our money?” Spend under management (lifetime), cost sources connected, business events on your timeline, and usage events ingested, plus a by-source spend chart.
• Detection — “Did it catch things we would have missed?” Cost anomalies detected, budget periods warned in time (before the period closed), alerts delivered and their delivery success rate, budgets watched, budget periods exceeded, commitments tracked, and connections needing attention. A calendar heatmap shows when alerts actually arrived.
• Opportunity — “How much money did it point at?” Identified monthly opportunity from open savings recommendations, an annualized run-rate, open and lifetime recommendation counts, waste findings (priced and unpriced), and unused commitment value, broken down by cost source.
• Outcomes — “What actually changed?” Recommendations acted on, split into three tiers of evidence (below), plus how many anomalies and waste findings your team has triaged.
• Adoption — “Is our team using it?” Changes made, members and how many are actively making changes, MCP tool calls, budgets, tag rules, teams, and alert channels configured.
• Cost of Plutus — “Is it worth the money?” Your plan price against identified opportunity and against spend under management, expressed as multiples (e.g. “12× your subscription in identified opportunity per month”).

A reporting-window selector (last 30 days / 90 days / 12 months / all time) at the top of the page controls every windowed metric at once; lifetime figures are unaffected by it.

Identified opportunity is not realized savings

The Opportunity section is worded deliberately: everything there is identified — what Plutus found and sized — not money actually saved. Acting on a recommendation is a separate decision your team makes, and the page never states or implies that identified opportunity has been captured.

Outcomes: three tiers of evidence, never summed together

The Outcomes section is ordered by how much each figure proves, and the tiers are kept separate rather than added into one number:

1. Confirmed done — a person on your team marked the recommendation done on /savings and the provider’s own engine has since stopped returning it. This is the only tier that carries a dollar figure (“value acted on”), captured at the moment the recommendation was marked done.
2. Marked done, still listed — your team recorded the change, but the provider hasn’t caught up yet (or disagrees). A human claim alone.
3. No longer recommended — the provider stopped returning the recommendation, with no human record of why. This is equally what unrelated resource churn (the resource being resized, replaced, or deleted for some other reason) looks like, so it’s reported as a count and a “value they carried” figure, not as a confirmed saving.

There’s no fourth tier claiming measured spend reduction. Even a confirmed-done outcome only reports the recommendation’s monthly value at the moment it was acted on — proving that spend actually fell afterward would need a counterfactual (what would have been spent otherwise) that nobody has.

Every metric states its own time window

Each tile on the page is more than a number — it carries a durability class that decides whether a window is shown at all:

• Durable — nothing purges the underlying data, so the figure is a genuine lifetime total (for example, spend under management, sourced from finalized billing-cycle history rather than raw cost_entries, which your plan’s retention does eventually delete).
• Tier-bound — capped by your plan’s cost/usage data retention window. If you ask for “all time” but your plan only retains 90 days, the page narrows the window to what’s actually available and says so, rather than silently reporting the smaller number as if it were the full history.
• Operational — capped by a fixed retention window that isn’t tied to your plan at all: alert delivery history is kept 180 days, MCP tool-call history 90 days. These counters don’t just stop growing once they hit that window — they can fall in a quieter quarter, because older deliveries age out. A figure like “alerts delivered” is really “alerts delivered in the last 180 days,” and the page labels it that way rather than letting it read as a lifetime count.

If you request a window wider than your plan’s retention allows, the page clamps the window and tells you it did — lifetime figures on the page are unaffected, since they come from finalized billing-cycle data your plan keeps regardless of retention.

New accounts see an “it’s early” state

An account with less than about two weeks of cost history gets a message explaining that the page fills in as data arrives, rather than a page of mostly zeros — anomaly detection and savings recommendations both need a baseline before they can report anything meaningful.

A failed section doesn’t take down the page

The Scorecard fans out across roughly ten subsystems (cost analytics, anomalies, budgets, savings recommendations, commitment tracking, alert delivery history, MCP usage, and more) in a single request. If one of those has a problem, only that section shows an “unavailable” message — the rest of the page renders normally with real numbers.

Exporting

The Export menu produces:

• A CSV with every metric on the page, one row each, including its section, window, and any caveat — so a figure doesn’t lose the context that qualifies it once it leaves the page.
• A PDF summary suitable for forwarding, built from the same underlying figures as the page itself (via the same report renderer used elsewhere in the app), so the document and the page can’t disagree.

Where the numbers come from

The Scorecard doesn’t run its own cost queries. Every cost figure is composed from the same query paths the Cost Explorer, Budgets, and Savings pages already use — the same base_cost currency handling, cost-source enablement filtering, and tag attribution rules described in Multi-currency and Savings & optimization apply here too. That’s a deliberate constraint: a page whose entire purpose is to be trusted is the worst place for its numbers to quietly disagree with the chart you’d check them against.