> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Change Intelligence & Risk Control
> Decide whether the change that just shipped is good — and undo it if not — with a verdict backed by the signals inside its blast radius.
Change Intelligence & Risk Control owns the minutes and hours around a change landing in production. It watches the
signals inside that change's blast radius, compares a canary against its baseline, and returns a
ship, hold, or roll back verdict with the evidence behind it. This page covers the outcome the
module owns, the three workflows inside it, and what you need connected before it can judge
anything.
## What this module owns
The verdict on a deploy already exists — it is just made informally. Someone merges, watches a
dashboard for two minutes, sees nothing obviously red, and moves on. The judgement is real work
being done with no baseline, no idea which of forty panels sits inside the change's blast radius,
and no record of the decision.
The failures that slip through are specific: the regression that only appears under the traffic
pattern arriving at 4pm, the change that is fine at p50 and doubles p99, the deploy that is correct
on its own and interacts badly with a migration from an hour earlier. Change Intelligence & Risk Control makes the
verdict explicit — a stated comparison against a baseline, on the signals that belong to this
change, producing a decision you can audit and a rollback you can approve.
Good looks like a trustworthy verdict within minutes of a deploy, most rollbacks starting from that
verdict rather than from an incident, and a false-rollback rate low enough that nobody overrides the
module by week two.
## The workflows inside it
This module contains **3 workflows**.
### Post-deploy verdict
Starts when your delivery system reports that something shipped. It identifies the blast radius of
the change, watches the signals inside it over a soak window, and returns ship, hold, or roll back
with the comparison that produced the answer.
### Canary judgement
Starts at a canary step in a progressive rollout. It compares the canary against its baseline on
latency, errors, and cost together, then promotes or aborts — so a canary that is marginally faster
and substantially more expensive does not pass unnoticed.
### Change blast-radius brief
Runs before the change ships. It states what this change can break, who owns those services, and
which signals to watch — the pre-flight brief nobody writes by hand.
Because a verdict is a watch-and-compare loop over a soak window rather than a single request, each
of these workflows spans several steps and several runs. The whole sequence is durable: it survives
a restart mid-soak.
## What it needs connected
| Requirement | Why | Where to set it up |
| --------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| A deploy event source | Something has to say "reality just changed" — an endpoint your GitOps or CD system posts to | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| Observability access | So the verdict is computed from your own latency, error, and cost signals | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| Rollback credentials | A rollback is a write to production, so the agent that performs one is bound to a narrowly scoped credential | [Credentials & secrets](/manage-your-agents/build/credentials-secrets) |
| Evaluation judges | A verdict is a rubric-scored decision; judges are what make it reviewable | [Evaluations](/manage-your-agents/optimize/evaluations) |
## Enabling it
Change Intelligence & Risk Control appears in the AI Software Operations family with the three workflows it contains.
Enabling the module adds Change Intelligence & Risk Control to your sidebar.
Create the endpoint your CD system posts deploy events to, then bind an agent to each step you
expect to run.
## What you see when it runs
The module lists every change it has judged. Each record carries the change that triggered it, the
blast radius it derived, the signals it compared and over what window, and the verdict — with the
runs behind each stage available to open.
A roll back verdict is a proposed production action, so it arrives as a decision for a human rather
than something already done. You approve or reject it with the comparison in front of you.
## Next steps
Keep the delivery path healthy before and after a change merges.
Where a missed verdict ends up.
How a rollback waits for a human decision.
How a workflow starts, on a schedule or from an endpoint.
## Related topics
- [Production Readiness & Standards](/modules-and-workflows/ops-automation/production-readiness.md)
- [CI/CD Health & Remediation](/modules-and-workflows/ops-automation/ci-cd-pipeline-health.md)
- [Modules & workflows](/modules-and-workflows/overview.md)
- [Alert Intelligence](/modules-and-workflows/sre/alert-hygiene.md)
- [Observability Cost](/modules-and-workflows/cost-optimization/observability-optimization.md)