Change Management
The Change Management studio scores a change for deployment safety and risk. Paste a change-management doc, runbook or migration plan and it returns a deterministic 0–100 safety score with a per-dimension breakdown — and it verifies every alarm the plan names against your real monitor catalog, so a plan can't claim a safety net that doesn't exist. It's the "is this actually safe to run?" check, computed rather than guessed.
A score you can trust, because it's deterministic. The rubric grades the same eight dimensions the same way every time, so a "72" means something you can compare. And the part that catches real incidents: the studio checks each monitor the plan leans on against the live catalog — an alarm that doesn't exist is flagged as a false safety claim, not taken at its word.
⚑ A safety score
A deterministic 0–100 with a verdict — the same rubric, every time.
⚑ Eight dimensions
Rollback, monitoring, blast radius, window, approvals, clarity, validation, data.
⚑ Real alarm checks
Every named monitor verified against the live catalog — missing ones flagged.
⚑ A narrative read
A plain-English write-up of the risk for the on-call engineer who'll run it.
What it is#
Change Management is the studio for assessing whether a change is ready to deploy. Its purpose is to replace a gut-feel "looks fine" with a structured, repeatable read — one that asks the questions a seasoned reviewer would (is there a real rollback? what's the blast radius? can someone follow this at 2 AM?) and grounds the monitoring claims in what's actually configured. It's for the migration, the runbook, the change ticket — anything where a bad deploy means downtime.
Scoring a change#
Bring in the full text of a change and the studio scores it: a deterministic 0–100 safety score and a verdict, rendered as a card with a copy-pastable summary. Because the score is computed in code from a fixed rubric, it isn't something a model talked itself into — it's the same measure applied consistently, so scores are comparable across changes and over time.
The safety dimensions#
The score breaks down across the eight dimensions that actually determine whether a change goes well — each scored, with the plan's strengths and gaps called out:
So a plan that ships fast but has no rollback, or clear steps but no validation, scores exactly where its weakness is — and you see which dimension to fix before you run it.
Verifying the alarms#
This is what makes the review more than a checklist. When a plan says "we'll watch the error-rate alarm during rollout", the studio extracts every monitor it names and checks each one against the live Chronosphere catalog. A monitor that exists is confirmed; one that doesn't is flagged as missing — a false safety claim. A plan can't earn safety credit for a net that isn't actually there.
The narrative read#
Alongside the numbers, the studio can produce a narrative read — a concise, plain-English write-up of the change's operational safety, the way a review panel would summarize it. Not a restatement of the score, but the story it tells: what's solid, what's risky, and what an on-call engineer should watch for. It's the human-readable companion to the deterministic breakdown.