spend-anomaly-triagelisted

# Skill: spend-anomaly-triage ## Premise A cost spike has a cause, and the cause is almost always something a human did on a specific day. The triage is a correlation problem with a small suspect list: deploys, feature-flag changes, traffic changes, scheduled jobs and backfills, commitment expiries, provider price changes, and incidents. The failure mode is stopping at "service X went up" — that is the observation, not the cause. Every suspect carries a **confirm/refute test**: something cheap that would settle it. A suspect list with no tests is a list of theories. ## Halt conditions - **Daily granularity unavailable.** Monthly figures cannot be correlated with a deploy. Get daily (ideally hourly) cost data or say the anomaly is not triageable at this granularity. - **Change log unavailable** — no deploy history, no flag-change history. Say so; the correlation half of the method is unavailable and the output is a mechanism hypothesis at best. - **The "anomaly" is a billing artefact** — an unamortised upfront purchase, a support fee, a credit expiring, a period boundary. Check these first, always; they explain a surprising share of apparent spikes and cost nothing to rule out. - **Baseline never declared.** If no expectation existed, this is not an anomaly, it is a discovery. Say which — the follow-up actions differ. ## When to run - A cost anomaly detector fired. - The bill moved and nobody can say why. - A slow creep: a line that has roughly doubled over a quarter wi