Skip to main content

Configuration

All tunable behaviour for Change Risk Advisory lives at GenAI Settings → Change Risk Advisory. A tenant admin enables or disables individual signals, tunes weights, sets the thresholds that map score to risk band, defines the Standard Change Candidate thresholds, and configures the runtime policy rules that re-engage CAB.

Signal toggles and weights​

Every signal listed under Risk scoring is independently configurable:

  • Toggle - on or off. A tenant that doesn't tag CIs as Critical can turn the Critical CI signal off; a tenant without change freezes can turn Freeze-window overlap off.
  • Weight - the points the signal contributes to the total score when it fires. Increase the weight to make a signal more influential.
  • Mitigation template - the wording the AI uses when this signal triggers. Tenants can override the default to match internal terminology ("Set Rollback Required = Yes" instead of "Add a documented rollback plan").

Custom signals can also be added: a tenant can map their own metadata fields (e.g. a Hardware-Change Indicator custom field) to a signal with a defined weight and mitigation template.

Thresholds​

The mapping from total score to risk band is a pair of thresholds:

ThresholdDefaultBehaviour
Medium threshold30Total ≥ this value moves the band from Low to Medium
High threshold60Total ≥ this value moves the band from Medium to High

Tenants with a stricter risk appetite lower both thresholds. Tenants whose change process expects most changes to be Medium can raise them.

Per-band behaviour​

Each band has its own configurable response:

BandDefault behaviourConfigurable
LowNo banner; eligible for standard-change fast pathWhether to display a confirmation banner anyway
MediumBanner with mitigations; standard CABAdditional reviewers to notify; whether to require mitigation resolution before submit
HighBanner with mitigations; reviewer escalationHard-block submission until mitigations addressed; mandatory additional approvers

The most restrictive option - hard-block submission at High - is off by default. Most tenants prefer to let the requester submit and rely on approver review, with the score acting as a strong signal rather than a gate.

Outcome-data sources​

The outcome signals - closure codes, linked P1/P2 incidents, rollback flags - can be configured to read from:

  • The native change closure codes (default)
  • Custom closure codes the tenant has added
  • Specific Problem records that the team explicitly marks as caused by a change

The incident-linking window (how long after a change to attribute new P1/P2 incidents to it) is configurable, with a default of 72 hours.

Standard Change Candidate thresholds​

Three thresholds control when a pattern surfaces as a Standard Change Candidate (more detail):

ThresholdDefaultWhat it controls
Minimum instances20The cluster must contain at least this many past changes
Clean-run requirementZero rollbacks, zero linked P1/P2 incidentsThe outcome record the pattern must have
Clean-duration12 monthsHow long the pattern must have run clean to surface

Raise the minimum and the clean-duration if the tenant wants a very high bar for fast-track eligibility. Lower them to surface candidates faster.

Runtime policy rules​

The default rules under Standard Change Candidates → Runtime policy rules (freeze-window overlap, concurrent shared-CI change, blackout-period violation) are tenant-configurable:

  • Toggle each rule on or off
  • Define what counts - which calendar feeds the freeze windows, which CI tag flags blackouts
  • Add custom rules - any condition expressible in the workflow engine can be added as a rule that re-engages full approval

Batch cadence​

The Standard Change Candidates batch runs:

  • Default: daily, overnight
  • Maximum: twice per day
  • Minimum: weekly

Daily is sufficient for most tenants. Faster cadence is rarely worth it because the underlying signal moves slowly.

Privacy​

Clustering embeddings for the Change Risk Advisory engine are stored isolated per tenant. No cross-tenant pattern matching happens. Change history for one tenant is never used to score or cluster changes for another.