Applied is not the same as gone
Automation that stops at “action executed” quietly shifts the work onto humans: someone still has to confirm the alert is actually quiet. The failure shape is specific and common — the fix succeeds, the wrong cause was treated, and the incident returns at the next cycle while the ticket already says resolved.
So we treat a fix as half an investigation. The detection that opened the incident is the only thing allowed to close it.
How the re-check works
Every fixer returns a verification obligation with its action:
- Re-run the same probe that found the problem, not a weaker one.
- Wait out the period the failure needs to show itself again: for a pod that restarts on a schedule, that means at least two full cycles, not one lucky one.
- Check the blast radius of your own change: the restart fixed the loop and broke the probe, or the deleted pod came back on a node that cannot fit it.
- Only a passed re-check marks the incident resolved. A failed one re-opens it with the evidence attached and escalates to a human with the fix reverted or rolled forward — never with a silent retry loop.
The obligation is part of the action, not a policy on top of it. A fixer that cannot declare how its fix will be proven does not ship.
Where the trust comes from
This is the mechanism behind our autonomy ladder. A class of fix earns more freedom only after its re-checks keep passing on your clusters — and loses it the moment they stop. The evidence is the same signed trail you can read yourself: action, re-check, outcome, hash-chained.
Measured over a quarter, the metric we care about is not fixes attempted or time-to-action. It is time-to-confirmed-resolution: the signal says gone, on the same probe that said broken.
The whole model is on the docs page: how much Srenix may do on its own, how approvals work, and how to read the trail.