Change Risk Assessment

Score this change on two axes — how much breaks if it goes wrong (blast radius), and how
confidently it can be undone (rollback confidence) — and land it in the right approval
class.

1. Read the change ticket in full — what, scope, when, rollback — plus any thread
   discussion that changes the picture.

2. Score BLAST RADIUS — who feels it if this goes wrong — citing the scope evidence and
   scoring the dependency, not the component ("one switch" carrying a whole site is HIGH):
   - LOW: single user or single non-critical device, no shared service in the path.
   - MEDIUM: a team, a site, or one shared service; workarounds exist during an outage.
   - HIGH: client-wide, multi-client, or a service with no workaround (auth, primary LOB
     app, core network, backup infra).

3. Score ROLLBACK CONFIDENCE:
   - HIGH: a tested reversal path, or inherently reversible (config flag,
     snapshot-verified VM change), with a known reversal time.
   - MEDIUM: a documented but untested reversal, or one slower than the window allows.
   - LOW: a one-way door (data migration with cutover, deletions, firmware), or an empty
     or hollow rollback field. "Restore from backup" is LOW unless a restore has actually
     been tested and that evidence is cited.

4. Classify from the two scores:
   - Standard: LOW blast radius + HIGH rollback confidence + a match in the client's
     documented pre-approved standard-change list. No documented match, no standard —
     whatever the scores say.
   - Emergency: only when active or imminent service impact makes waiting for normal
     approval more damaging than acting, and the incident justifying it is named. Route to
     emergency-change-handling; emergency is a speed lane, not a lower bar.
   - Normal: everything else. HIGH blast radius or LOW rollback confidence means CAB-level
     review; recommend mitigations too (staged rollout, pre-change backup verification,
     on-call coverage in the window).

5. Leave the assessment as a note: both scores with their evidence, the classification,
   the recommended approval path, and any required mitigations (apply the PSA Note
   Discipline base skill — plain text, no markdown or emojis). Set the change ticket's
   type/priority to match where the desk uses one. If scores changed because scope grew
   since a prior assessment, say so — re-classification resets the approval.

Guardrails: you recommend a class, a human approver ratifies it — never green-light
execution. Emergency needs a named, current incident or imminent harm; "the client is
impatient" is normal-track. "We do this all the time" in a thread is not a documented
procedure. When the ticket lacks the information to score an axis, score it at the riskier
level and say why — uncertainty is risk, not a pass. Never soften a score to avoid
friction — the honest HIGH that starts a CAB conversation is the product.