CAB meets every Wednesday for two hours and approves 80 changes, of which 60 are pre-approved standard models that nobody reads. The other 20 get less than three minutes each because the queue is long. The instinct is to automate the standard 60 away — correct — but the bigger opportunity is automating the prep so CAB can spend real time on the changes that need conversation.
Pre-classify before the meeting
Every change submitted should be auto-scored against risk, blast radius, complexity, and rollback maturity before it hits the CAB queue. The scoring uses fields the requester filled in, the affected CI’s criticality, and historical change-type success rate. CAB sees the score, the assumptions behind it, and a recommendation: standard auto-approve, normal review, or high-risk discussion.
score_inputs:
- ci_business_criticality (1-5)
- change_window_business_hours (bool)
- rollback_tested (bool)
- requester_change_success_rate_90d
- change_model_historical_failure_rate
output: low | medium | high | very_highStandard models drive auto-approval
Properly defined standard change models with successful track records earn auto-approval — no CAB time at all. The standard model definition includes pre-flight checks that must pass at submission. Maintain a quarterly review where models with degraded success rates lose standard status until remediated. Without the review, standard becomes a loophole.
Asynchronous CAB for normal changes
Most normal changes do not require synchronous discussion. Build an async approval flow: the change is posted to the CAB Slack/Teams channel with the score, summary, affected services, rollback plan, and a link to the record. Approvers vote with reactions or a structured form. Synchronous CAB is reserved for high-risk and very-high-risk changes only — the meeting shrinks from 80 changes to 5.
Conflict detection runs before submission
A change that conflicts with another scheduled change, a freeze window, or a blackout period should fail submission, not get caught in CAB. Use a Business Rule on change_request insert/update that queries cmn_schedule_blackout and concurrent change windows on shared CIs. The requester sees the conflict immediately and either reschedules or escalates with justification.
var conflict = new ChangeConflictChecker()
.checkBlackouts(current.start_date, current.end_date)
.checkConcurrentChanges(current.cmdb_ci, current.start_date, current.end_date);
if (conflict.hasErrors()) {
current.setAbortAction(true);
gs.addErrorMessage(conflict.getMessage());
}Risk acceptance with named accountability
When a change goes ahead despite a high score, the system records who accepted the risk by name, role, and reason. The acceptance becomes a queryable artifact, not a comment in a worklog. Quarterly reports surface frequent acceptors and high-acceptance change types — both are signals worth acting on.
Implementation sequence
Start with conflict detection and standard model auto-approval — these have the highest CAB-time payback and lowest risk. Add scoring next, with CAB seeing scores but not yet using them for routing. After three months of score validation, route low-score normal changes to async approval. Synchronous CAB-only-for-high-risk is the final state, not the starting point.
Common failure modes
Scoring weights tuned once and never revisited — re-tune quarterly against incident-rate-by-change-type. Auto-approval without a sampling audit — randomly route 5% of standard changes to CAB review to keep the standard models honest. Async approvals that quietly time out and proceed — set explicit non-response defaults (deny, escalate, or auto-approve with named risk owner).
What changed in 2026
Now Assist’s change-risk insights (where licensed) score changes using language analysis of the description plus historical patterns. Treat the insight as one input alongside the rules-based score, not a replacement. The two scores disagreeing is itself a useful signal — surface both to CAB.
What to do this week: pull last quarter’s CAB-approved changes that failed and bucket by score band — score bands with high failure rates need scoring-rule updates before more automation.
