Skip to main content

Risk scoring

Every Change Request gets a risk score the moment it has enough text to score, and the score updates as the requester edits the form. This page covers what the score is made of, how the score becomes a risk band, and how past outcomes feed back into the model.

The signal set

The score is the sum of about ten weighted signals. Each signal is independently configurable per tenant (Configuration) - tenants can turn signals off, change their weight, or add custom signals. The default set:

SignalWhat it measures
Text similarity to past failed changesThe current change description compared against past changes that failed, were rolled back, or caused incidents
Critical CIWhether the change touches a CI tagged Critical in the CMDB - regardless of who's implementing it
Implementor-group track recordHistorical failure / rollback rate for the assignment group implementing the change
Freeze-window overlapWhether the proposed implementation time falls inside a configured change-freeze window
Concurrent-change density on shared CIsNumber of other open changes touching the same CIs in the proposed implementation window
Plan quality - rollback presentIs there a documented rollback plan?
Plan quality - test plan lengthHow thorough is the test plan? Short or empty test plans raise the score
Plan quality - attachment completenessAre the expected artefacts attached (design doc, test evidence, runbook)?
Business hours / high-risk time windowCalendar-based: month-end, quarter-end, business-hours implementation

How the score becomes a band

The total score maps to one of three risk bands:

BandDefault rangeWhat it triggers
Low< 30No banner; eligible for Standard Change Candidate fast path if the change is a candidate
Medium30 – 59Banner shows the risk and mitigations; standard CAB review
High≥ 60Banner shows the risk and mitigations; reviewer escalation; tenant-configurable additional approvers

Thresholds and per-band behaviour are tenant-configurable. See Configuration.

Outcome scoring

The model is only useful if it learns from what actually happens to changes after they ship. Three signals feed the outcome side:

Outcome signalWhere it comes from
Closure codeThe closure code on past changes (Successful, Failed, Rolled Back, Partial Success)
Linked P1/P2 incidentsIncidents linked to a change within a configurable window after implementation
Rollback flags from PIRsPost-Implementation Reviews where the team marked the change as rolled back or partially restored

These signals are used in two places:

  1. Per-change scoring - when a new change resembles past changes whose outcomes were bad, the Text similarity to past failed changes signal fires.
  2. Per-pattern scoring - the Standard Change Candidates batch reads the same outcome signals to decide whether a pattern is safe enough to fast-track.

When the score recalculates

  • On every edit to the change form - typing in description, attaching a file, setting an implementation date, changing the assignment group. The banner updates as the requester writes.
  • On every linked-ticket change - if an incident is linked to the change, scores recompute.
  • On schedule - for open changes that haven't been edited but where contextual signals can shift (concurrent-change density, freeze-window overlap), the score sweeps on a tenant-configurable cadence.

What the score does not do

  • It does not auto-reject changes. Even at the High band, a change is only blocked if the tenant has explicitly configured a hard-block rule for that band.
  • It does not auto-approve changes. The Low band is a fast-path eligibility signal, not an approval.
  • It does not move changes through workflow on its own. Workflow transitions are driven by the change process, not by the risk score.