Change Risk Advisory
An AI agent that reads every Change Request as it's being written, scores it across about ten signals, and gives the requester (and later the approver) a clear read of the risk plus specific mitigations to address. When the same change pattern runs cleanly for long enough, the agent proposes it as a Standard Change Candidate so future identical changes can skip CAB and ship faster.
It runs on the same AI-driven case-cluster engine that powers Problem and Major Incident Detection. The engine is general-purpose; this feature applies it to Change Requests instead of Incidents.
Where it shows up
| Surface | Who sees it | What appears |
|---|---|---|
| Banner on the Change Request form | Requester | Risk band (Low / Medium / High) plus a list of specific mitigations to address before submitting |
| Banner on the approver screen | Approver | Same risk band, with mitigations grouped, and any mitigation the requester hasn't addressed called out as outstanding |
| CAB review view | Approver / CAB chair | Aggregated risks for the change under review and an inline Suggest review action that drafts a note back to the requester |
| Problem / Major Incident / Change Management Dashboard | Change Manager | Standard Change Candidates surfaced from successful change patterns, with frequency, success rate, and rollback history |
The risk read happens as the requester writes, not just at submit time. Adding a rollback plan or attaching a test report immediately lowers the score and updates the banner.
Personas served
- Requester sees the risk band on the change form and the per-signal mitigations. They can fix the issues in line before submitting.
- Approver sees the same risks with their resolution state. Mitigations the requester addressed are checked off; outstanding ones are highlighted. The Suggest review action drafts a note citing the outstanding items so the approver doesn't have to write it themselves.
- Change Manager uses the dashboard to monitor risk trends and to convert proven-safe change patterns into Standard Change Candidates.
What you can do with this feature
| Capability | Page |
|---|---|
| The ~10 signals, how they become a risk band, outcome scoring | Risk scoring |
| AI-generated mitigations on the form, on the approver screen, at CAB | Mitigations |
| Detecting safe patterns, the dashboard surface, runtime policy rules | Standard Change Candidates |
| Per-tenant signal toggles, weight tuning, thresholds, policy rules | Configuration |
How it relates to Problem and Major Incident Detection
The same engine groups incidents into clusters and groups changes into pattern candidates. The difference is what it does with the cluster:
| Family | Cluster signal | Action |
|---|---|---|
| Problem / MI Detection | Cluster of similar incidents in a short window | Surface as MI or Problem candidate; agent declares |
| Change Risk Advisory | Cluster of similar past changes with outcome data | Surface as Standard Change Candidate; manager accepts |
The same clustering also powers a defensive signal on individual Change Requests: when a new change resembles a past cluster that produced incidents or rollbacks, the risk score goes up before the requester even submits.
Privacy
The clustering embeddings the engine uses to compare changes are stored isolated per tenant. No cross-tenant pattern matching happens. Your change history is only ever compared against your own change history.
Related topics
- Risk scoring
- Problem and Major Incident Detection - same engine, applied to incidents
- Change ticket type - the underlying ticket structure