OutputValues icon
Queries icon
Log icon
UploadFiles icon
If icon
Fail icon
Set icon
Schedule icon

Score change requests on risk and build the CAB agenda, pre-approving the low-risk ones

Change risk scoring in Kestra and DuckDB. Blast radius from dependencies, team failure rate, freeze windows, collisions, pre-approval and CAB agenda.

Categories
DataInfrastructure

Most change advisory boards spend their hour on changes that never needed them, and wave through the one that takes production down. ITIL 4 change enablement and the DORA research make the same point: route changes by risk, pre-approve the low-risk ones, and spend the board's time on what is actually dangerous. That needs a risk score everyone can read. It should come from what the change touches, how big it is, whether it can be rolled back, and how the team's recent changes went.

This flow scores the week's change requests, catches the ones in a freeze window or colliding with another change on a related service, and writes the CAB agenda. Outcomes recorded after implementation feed each team's failure rate for the next scoring.

It runs with no setup and no network. The demo has eight services with dependencies, two freeze windows, 90 days of change history per team, and eight change requests:

  • a certificate rotation;
  • a database upgrade and an MFA change scheduled in overlapping windows;
  • a large payment routing change with no backout plan;
  • a checkout change in a launch freeze;
  • an emergency hotfix.

The score

Factor Points
Service criticality 1 to 4 30, 20, 10, 0
Blast radius: services that depend on it, directly or not 4 each, up to 20
Size 8 above 15 files, 15 above 50
No backout plan 15
Not tested in staging 10
Team change failure rate over 90 days 8 above 10%, 15 above 15%
Downtime, or business hours on a critical service 10, or 5

The score is capped at 100. Every change lists the factors that scored, so the requester sees what to fix to lower it.

Routes

Route Rule
REJECT_FREEZE The window overlaps a freeze covering the criticality of what the change affects: reschedule
ECAB_RETRO_REVIEW Emergency change: implemented with emergency CAB approval, reviewed at the CAB
CAB Overlaps another change on the same service or a direct dependency, or scores 50 or more
PEER_REVIEW 25 to 49
PRE_APPROVED Under 25

How it works

  1. state loads the change outcomes recorded at earlier CABs.

  2. score (io.kestra.plugin.jdbc.duckdb.Queries) holds the services, dependencies, freezes, change history and requests. It checks the data, computes the blast radius with a recursive query, the team failure rates, the freeze and collision checks, the score and the route.

  3. log_score prints the routes, the scores, the agenda and the failure rates. evidence_blockers stores blockers.csv.

  4. gate stops on blockers before anything else is written:

    • a change for a service not in the CMDB;
    • a window that ends before it starts;
    • an outcome that is not SUCCESS or FAILED;
    • an outcome for a change that was never implemented.

    Otherwise evidence stores changes.csv (every factor's points) and agenda.csv.

  5. save (io.kestra.plugin.core.kv.Set) keeps the outcomes. A failed change raises its team's failure rate at the next CAB.

Tested end to end

On Kestra 2.0.5 OSS.

Run Inputs Result
1 2026-10-06 8 changes. CAB: the core-db upgrade (75) and the MFA change (38), which overlap, and payment routing (69: no backout plan, 63 files). The checkout copy change is rejected, inside the launch freeze. The hotfix goes to ECAB review, 2 changes to peer review, and the certificate rotation is pre-approved (0). Platform failure rate 33.3%
2 Outcomes: 3 Payments changes failed Payments failure rate 3.3% to 12.1%: payment routing goes from 69 to 77
3 No outcomes Same as run 2: the outcomes were kept
4 An outcome for an unknown change, and ROLLED Blocked, nothing kept
5 ISSUES Blocked: a service not in the CMDB, an inverted window

I recomputed the blast radius, the team failure rates from the history, and the score of the 8 changes independently in Python. Every value matches.

Inputs

Input Default Purpose
cab_date 2026-10-06 CAB date
outcomes {} Outcomes of implemented changes
scenario CLEAN Demo only

Use it with your data

  • Replace changes with your ITSM change requests (ServiceNow, Jira Service Management), and services and depends_on with your CMDB.
  • Fill outcomes from incidents linked to changes, or let a task after the implementation window record them.
  • Approve PRE_APPROVED changes in the ITSM tool from a task after save, and send agenda.csv to the CAB before the meeting.

Things to know

  • The weights are a starting point. Compare the scores with the outcomes after a few months, and adjust the factors that predict failures.
  • Collisions are checked on the same service and on direct dependencies, which is where two changes most often interfere.

Links

This blueprint was created by zkasuran.

See How

New to Kestra?

Use blueprints to kickstart your first workflows.