Skip to main content

Standard Change Candidates

A daily batch job clusters past changes by similarity and overlays the outcome data the risk model already tracks. Patterns that have been running cleanly for long enough surface on the Problem / Major Incident / Change Management Dashboard as Standard Change Candidates - patterns that may be safe to fast-track through a standard-change workflow instead of taking up CAB time.

How candidates are detected​

The batch clusters tenant change history on four dimensions:

DimensionWhat it means
Text similarityDescription and summary similarity across past changes
CIThe same configuration item or service in scope
Assignment groupThe same implementation team
Change typeSame change-type taxonomy (where the tenant uses one)

Within each cluster, the engine reads the outcome data: how often did this pattern ship? How many of those ships had no linked P1/P2 incidents? How many were rolled back? A pattern is surfaced as a candidate only when:

  • The cluster size meets a tenant-configurable threshold (e.g. at least 20 instances)
  • The clean-run threshold is met (e.g. zero rollbacks and no linked P1/P2 incidents in the last 12 months)
  • The time-since-last-incident threshold is met (e.g. clean for at least 6 months)

All three thresholds are tenant-configurable. See Configuration.

What the Change Manager sees on the dashboard​

Each candidate row shows:

  • Pattern summary - AI-generated description of the change being clustered
  • Frequency - how often the tenant runs this change
  • Success rate - percentage of clean ships in the analysis window
  • Rollback history - count and timing of any rollbacks in the analysis window
  • First seen / Last seen - the time range the cluster covers

The Change Manager reviews each candidate and chooses Accept, Reject, or Snooze.

Accepting a candidate​

On accept, the pattern wires into the tenant's standard-change workflow:

  1. The cluster fingerprint is stored as a standard-change template.
  2. New Change Requests that match the fingerprint are matched automatically.
  3. Matching Change Requests skip CAB by default and go straight through the standard-change approval path.

The Change Manager can edit the matching fingerprint after accepting (e.g. broaden to include adjacent CIs, narrow to a single assignment group).

Runtime policy rules​

A matching Change Request doesn't get a free ride. Even after a pattern is accepted, runtime policy rules can re-engage full CAB approval for a specific instance when conditions warrant. The default set of rules:

RuleWhen it firesWhat happens
Freeze-window overlapThe change's implementation window falls inside a configured freezeFull approval re-engaged; banner cites the rule
Concurrent change on shared CIAnother open change targets the same CI in an overlapping windowFull approval re-engaged; banner names the conflicting change
Blackout-period violationThe change touches a CI inside an active blackout (e.g. customer-facing during a sales event)Full approval re-engaged; banner cites the blackout

When a rule fires, the requester sees a banner naming the specific rule:

This change normally follows the standard-change fast path, but Freeze-window overlap applies. Full approval required for this instance.

The agent does not hide the standard-change status. The requester knows their change is normally fast-tracked but knows specifically why it isn't this time.

Rejecting a candidate​

Reject removes the pattern from the candidate list and signals back to the AI that this cluster shouldn't be re-suggested. The Change Manager can give an optional reason ("This cluster overlaps with a known-fragile dependency"). The reason is shown next to the rejection in the Recent Actions log.

Snoozing a candidate​

Snooze is the middle option: not yet, but maybe later. The Change Manager picks a re-evaluation date and the candidate hides until that date.

Recent Actions​

A log section on the same dashboard tracks every Accept, Reject, and Snooze, with the reason and the manager who did it. Useful for auditing how the standard-change list grew over time.