Deployment-Correlated Rollback Gate

Problem

Letting the agent roll back on any incident is unsafe, because a rollback aimed at a failure a deployment did not cause is a blind change that can compound the outage. Gating purely on the agent's confidence is weak, because a model can be confidently wrong about cause. What distinguishes a safe autonomous rollback from one that needs human judgement is whether a deployment actually precedes and plausibly caused the failure — a structural fact the agent can check rather than guess.

Solution

Give the agent a rollback action but gate it on a deployment-correlation check rather than on its confidence. When an incident fires, the gate looks for a deployment to the affected service whose timing precedes and aligns with the failure onset. If a clear correlation holds, the agent may execute the rollback of that release within its policy bound, because the change to undo is identified. If no deployment correlates — a novel failure, a dependency outage, a traffic spike — the gate keeps the agent advisory: it can recommend and gather evidence, but the rollback decision goes to a human. The correlation is computed from deployment and telemetry events, so the unlock is a checkable fact, not the agent's belief about cause.

When to use

• An incident-response agent can execute rollbacks and both deployment and failure events are observable and timestamped.
• Many incidents are deploy-caused, so deploy correlation is a meaningful unlock signal.
• Fast autonomous mitigation is valuable for the deploy-caused cases while unknown-cause cases should stay human-judged.