What an Incident Review Actually Asks For

TL;DR: Incident reviews for automated systems follow a predictable sequence: what happened, what was supposed to happen, who authorised the difference, and what stopped it getting worse. Teams prepare exhaustively for the first and improvise the rest. The third question is the one that turns a technical postmortem into a governance finding.

Reviews are not a mystery, and they are not hostile

There is a persistent belief that an incident review is an unpredictable interrogation you survive by having good dashboards. It is not. Whether it is an internal postmortem, a regulator’s information request, or a committee with a transcript, the shape is remarkably stable. Four questions, roughly in order, each one only asked properly once the previous one has an answer.

Knowing the sequence changes what you build. Most observability investment answers question one very well and question three not at all.

One: what happened

Sequence of events, timestamps, blast radius. This is the part every team is ready for, because it is the part that looks like engineering. Metrics, traces, logs, a timeline reconstructed in the warroom.

Two notes, both learned the hard way.

Reconstruction takes longer than anyone expects when the actor was autonomous, because there is no human to ask. With a person you interview them. With an agent you have whatever it happened to write down, and if the interesting decision was a decision not to act, it usually wrote down nothing.

And timestamps from three systems will disagree. Whether they disagree by milliseconds or by a lot determines whether you can order the events at all.

Two: what was supposed to happen

Here the ground shifts, and reviews start going badly.

Somebody produces the runbook, or the policy document, or the config repository at HEAD. The reviewer asks a quieter question: was that what was in force at the time?

For most estates the honest answer is “probably, we would have to check”. Configuration drifts. Feature flags get flipped during an unrelated incident and not flipped back. A limit was raised for a migration in March and nobody lowered it. The document describing intended behaviour and the behaviour in production are different artefacts maintained by different processes, and only one of them was running.

This is why the intended state has to be sealed into the record at the moment of the decision, not looked up afterwards. A record that says “this action was evaluated against these limits, in this enforcement mode” is evidence. A config file you can read today is a description of now.

Three: who authorised the difference

This is the question, and it is where autonomous systems produce an answer nobody wants to give.

A human operator did something unexpected, so you interview them and they explain. Perhaps they were wrong, perhaps the procedure was wrong, perhaps they were right and the model of the system was wrong. Either way there is a person with reasons, and the review has something to work with.

An agent did something unexpected, and the chain of custody usually terminates in a service account. That is not an answer. It is the absence of one, formalised. The reviewer will keep pulling. The next stop is the team that deployed it, and the stop after that is whoever signed the change. By then the conversation has moved from “what went wrong” to “who is accountable for this class of thing”, which is a different and much worse meeting.

The way to answer it is to have decided in advance. A grant that names a human, a scope, a limit and an expiry, cited by every action taken under it. Then the answer is one query and it is boring, which is what you want.

Four: what stopped it getting worse

The most under-prepared question, and the one with the most upside.

Reviewers want to know that controls operated. Not that controls exist, because a design document proves existence. That they ran, and either held or did not.

Systems built to log successes cannot answer this. The refusal that mattered is the one where the code returned early, and returning early is exactly the path with no logging on it. So the honest answer becomes “we believe the limit would have applied”, which is a sentence that invites a follow-up you will not enjoy.

An agent that was stopped 40 times is a control demonstrating itself. An agent never stopped is either perfectly bounded or entirely unbounded, and from outside those are indistinguishable. Refusals are the cheapest evidence you can generate and almost nobody keeps them.

The one you should hope they ask

Occasionally a reviewer asks a fifth question, and it is the best one: how would you know if this were happening right now?

It is a question about detection rather than history, and it does not have a documentary answer. You either have a live view of what your agents are doing against what they are permitted to do, or you have a set of dashboards showing utilisation.

Teams that can answer it tend to have a specific property: the same mechanism that permits an action also records it. Not two systems that must be kept consistent. One path, where the check and the record are the same event. If enforcement and evidence are separate subsystems, they will drift, and the drift will be discovered during question three.

Preparing without a review pending

Three things, all cheap, all useful before anything goes wrong.

Run the four questions against last quarter’s real incidents. Not hypothetically. Actually try to answer them, with a stopwatch. The gaps are obvious within an hour and they are never where the team expected.

Find out what your agents did that you did not know about. Recording without refusing costs nothing operationally and the first week’s data reliably contains at least one surprise.

Make somebody own the sentence. For each consequential action an agent can take, one person should be able to say what it may do, up to what, until when. If nobody can say it, that is the finding, and you would rather have it now than in a transcript.

The bottom line

Incident reviews do not ask whether your model is good. They ask whether you were in control, and they ask it in a specific order that ends at a person. Build so that the third question has a one-line answer, and the rest of the review is engineering rather than accountability.