The CAB meeting where nobody can score the risk
Thirty changes, one hour, and no consistent way to judge any of them, which means the board is a scheduling meeting wearing the costume of a risk control.
What actually happens
The change advisory board is asked to assess risk it has no evidence about, in an hour, for thirty changes. It responds the only way it can, which is by pattern matching on who submitted them.
Change requests arrive with a description, a category chosen from a dropdown, a proposed window and a rollback plan written to a template. What they do not arrive with is any evidence about what the change actually touches.
The board has an hour and a queue. Thirty changes gives roughly two minutes each, and two minutes is not enough to interrogate any of them meaningfully, so the board falls back on heuristics: who submitted it, has this type of change gone wrong before, does the description sound alarming.
Those heuristics are not worthless, they encode real experience. They are also systematically blind to the specific thing that causes change failures, which is interaction: two changes in the same window touching the same dependency, or a change touching a service that is already carrying an open incident.
The board approves, the changes execute, and the one that fails is rarely the one anyone worried about. It is usually the routine change that collided with something the board had no way to see.
The post-incident review then adds a question to the change template, which makes the next board slightly slower without making it better informed.
The board is not approving on instinct because it is careless. It is approving on instinct because instinct is the only input anyone gave it.
The same board, two ways
The comparison here is not elapsed time. It is what the board actually knows about each change when it votes.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, thirty changes and an hour
- T-1 dayThirty change requests submitted. Description, category, window, template rollback plan.
- T-0WaitingBoard convenes. Roughly two minutes per change.
- T-0WaitingAssessment falls back on submitter reputation and change type. No collision or dependency evidence available.
- T-0All thirty approved. Windows unchanged.
- T+2 daysTwo changes in the same window touch a shared dependency. Service affected.
- T+3 daysWaitingReview adds a new question to the change template.
30 changes assessed · on almost no evidence
With risk scored before the board sits
- T-1 dayEach change parsed for what it actually touches: services, hosts, configuration and dependencies.
- T-1 dayCross-referenced against the change calendar for collisions in the same window on shared dependencies.
- T-1 dayCross-referenced against open incidents and problem records on the affected services.
- T-1 dayHistorical outcomes for comparable changes attached, including which ones were rolled back and why.
- T-1 dayEach change arrives at the board with a blast radius, a collision list and an evidence-backed risk position.
- T-0Board spends its hour on the six changes that carry evidence of risk, not two minutes each on thirty.
Attention concentrated on the changes that warranted it
There is no time saving to claim here and it would be dishonest to lead with one. The board still meets for an hour. What changes is where that hour goes.
The metric worth tracking is change failure rate, and specifically the proportion of failed changes that were approved as low risk. In most estates that proportion is uncomfortably high, and it is the direct consequence of assessing risk without evidence.
The mechanism is parsing what the change touches rather than what it says. A change description is a claim; the configuration it modifies, the services that depend on it and the other changes scheduled in the same window are facts, and all three are available before the board sits.
Collision detection is the single highest-value input. Two individually safe changes in the same window on a shared dependency is the most common shape of change-induced incident, and it is invisible to any assessment that looks at changes one at a time.
Why the number is what it is
There is no time saving to claim here and it would be dishonest to lead with one. The board still meets for an hour. What changes is where that hour goes.
The metric worth tracking is change failure rate, and specifically the proportion of failed changes that were approved as low risk. In most estates that proportion is uncomfortably high, and it is the direct consequence of assessing risk without evidence.
The mechanism is parsing what the change touches rather than what it says. A change description is a claim; the configuration it modifies, the services that depend on it and the other changes scheduled in the same window are facts, and all three are available before the board sits.
Collision detection is the single highest-value input. Two individually safe changes in the same window on a shared dependency is the most common shape of change-induced incident, and it is invisible to any assessment that looks at changes one at a time.
The mechanism is parsing what the change touches rather than what it says.
Who decides to press go
Nothing here approves a change. The board approves changes, and it continues to.
Parsing changes, computing blast radius, detecting collisions and attaching historical outcomes all run under policy. None of it approves or schedules anything.
A proposed window change or a hold is raised as a recommendation with the collision evidence attached. The board or the change manager decides.
The output is evidence, not a verdict. A risk score that the board cannot interrogate would be a worse control than the instinct it replaced.
Change requests submitted with description, category, window and template rollback. No evidence attached about affected scope.
Each change parsed for affected services, hosts, configuration and dependencies. Cross-referenced against the change calendar, open incidents and historical outcomes for comparable changes.
Blast radius, collision list and evidence-backed risk position attached to each request before the board sits. Window changes proposed as recommendations.
Outcomes fed back so comparable future changes carry real history. Collision patterns that recur promoted into scheduling rules.
This is a platform capability, not a published customer deployment for this exact scenario. The mechanism, which is cross-system correlation followed by governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today across managed estates; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Parsing changes, computing blast radius, detecting collisions and attaching historical outcomes all run under policy. None of it approves or schedules anything.
If it reschedules or blocks a change
A proposed window change or a hold is raised as a recommendation with the collision evidence attached. The board or the change manager decides.
What Sentinel did, step by step
- ObserveChange requests submitted with description, category, window and template rollback. No evidence attached about affected scope.
- InvestigateEach change parsed for affected services, hosts, configuration and dependencies. Cross-referenced against the change calendar, open incidents and historical outcomes for comparable changes.
- ActBlast radius, collision list and evidence-backed risk position attached to each request before the board sits. Window changes proposed as recommendations.
- OptimizeOutcomes fed back so comparable future changes carry real history. Collision patterns that recur promoted into scheduling rules.
Bring us last quarter of failed changes
We will check how many were approved as low risk and what evidence was missing.