Skip to main content

Mitigations

The risk score is half the picture. The other half is what to do about it. For every signal that fires, the agent drafts a specific mitigation in plain language: "Add a documented rollback plan", "Reschedule outside the month-end freeze window", "Coordinate with the team running CHG-0124 on the same database".

The same set of mitigations follows the change from the form through to CAB, with the resolution state of each one tracked along the way.

On the requester's screen​

While the requester is writing the change, the banner shows the risk band and a bulleted list of mitigations - one per triggered signal. Each mitigation is concrete enough to act on:

Mitigations • Add a documented rollback plan. The change description doesn't reference one. • This implementation date falls inside the November month-end freeze window. Reschedule for after the freeze ends. • Test plan is shorter than expected for changes of this scope. Add specific test cases for the affected services.

Each line that gets addressed - the requester adds a rollback plan, picks a date outside the freeze, expands the test plan - disappears from the list as the form re-scores. The banner shrinks accordingly.

When all mitigations are addressed, the band drops, the banner closes, and the change can be submitted with the lower risk read.

On the approver's screen​

When the change reaches the approver, the same mitigations are shown - but with their resolution state. Mitigations the requester addressed are marked with a green check. Mitigations that are still outstanding are highlighted.

Mitigations ✓ Added a documented rollback plan ✗ Implementation date overlaps the November freeze window ✓ Test plan expanded with affected-service cases

The approver can see at a glance whether the requester worked through the recommendations or whether they submitted anyway. Outstanding items are the natural starting point for the approver's review.

At CAB​

For changes that go through CAB, the same engine surfaces what remains unaddressed on the CAB review view. Multiple changes scheduled for the same CAB are grouped by common mitigation themes ("Five changes this CAB still need rollback plans") so the CAB chair can address recurring patterns without re-reading every change individually.

The Suggest review action​

From the approver screen or the CAB view, the Suggest review action drafts a note back to the requester citing the outstanding mitigation - with no manual typing. The note text uses the same plain-language mitigation already shown on screen, so the requester reads exactly what the approver saw.

Example draft:

Reviewing this change ahead of CAB. Two items to address before we approve: • The implementation date overlaps the November freeze window. Please reschedule for December 5 or later. • The test plan doesn't include cases for the customer-portal service. Please add or link a test report. Once these are addressed, the change is ready for CAB.

The approver reviews the draft, edits if they want, and sends. The note is appended to the Change Request as a public note.

How mitigations are generated​

Mitigations are drafted by the AI from a per-signal template that already knows what the signal measures and what addressing it looks like. The signal Plan quality - rollback present maps to a mitigation that asks for a rollback plan, with the wording adapted to the change context (service name, affected CIs). Each tenant can override the per-signal template language to match their internal terminology and process.

This is a draft for the human; it does not auto-edit the change. The requester decides what to act on. The approver decides what to send.