10:02 deployment completed
10:07 error rate increases
10:11 engineers discuss the failures
10:18 rollback starts
Every line in that timeline can be accurate, and it still explains nothing. Read it once and a story assembles itself: the deployment broke something, the errors followed, the engineers noticed, the rollback fixed it. None of that is in the list. It is in the reader. Four events close together in time invite a causal reading, and the timeline does nothing to confirm or resist it.
Order is not explanation. A timeline tells you what happened when. An explanation tells you what the evidence supports and why: whether the deployment caused the errors, whether the discussion at 10:11 was about the same failure, what anyone learned between 10:07 and 10:18 that made rollback the right call, and how sure they were.
The timeline is not wrong. We ask it to carry more than it contains.
Chronology is not causality
Those four lines contain no claim that the deployment and the error rate are connected, only the fact that one preceded the other. There is no record of which evidence made that connection credible, how confident anyone was, or what would have weakened the belief. The relationships that turn a sequence into an explanation live somewhere else: in an engineer's head, in a chat thread, or nowhere at all.
A deployment landing minutes before an alert is worth investigating first without being treated as guilty. The timeline cannot make that distinction. It only knows the order.
Order is necessary for understanding an incident, and nowhere near sufficient for it.
An incident is a set of competing hypotheses
Nobody understands an incident all at once. At 10:07 the deployment looks suspicious, mostly because it is the most recent thing that changed. By 10:09 the error rate is rising on the deployed service and nowhere else, which strengthens the case. At 10:11 one engineer reports that checkout is failing for some users, which fits, and another reports that search is slow, which does not. At 10:14 a shared dependency starts timing out, and now there are two live explanations: the deployment broke something, or the dependency is failing and the deployment happened to land nearby.
This is incident reasoning from the inside: several hypotheses being weighed against evidence that keeps arriving. The best reading at 10:09 may be wrong by 10:14, not because anyone made a mistake, but because the evidence changed.
A retrospective summary flattens all of that into the one story that leads to the ending. It is the wrong shape for anything meant to help while the incident is still moving.
Evidence has to survive the AI
Point a language model at the timeline and the chat channel and ask for a narrative, and the result will read well. That is the problem. "The deployment introduced a regression that caused the error rate to increase, prompting a rollback" is a perfectly plausible sentence, and nothing about its plausibility tells you whether it is true. Narration is cheap. What engineers need is the link from the claim back to something observable.
Take a claim like: the deployment is the likely cause of checkout degradation. Which deployment? What did it change, and does the change plausibly touch checkout? Which metric moved, and how closely did it track the deployment window? Is the error confined to instances running the new revision? Each of those has an answer in a real system: a diff, a metric, a deployment log. The claim earns its place by pointing at them.
That is the difference between plausible narration and an evidence-backed engineering claim. A model can generate hypotheses, rank them, and draft the sentence. It should not become the source of truth. That stays in the engineering evidence, and anything the model says should trace back to it. Incident AI has to show its work; an assessment that cannot be traced is the timeline problem again, with better prose.
Context is what connects the evidence
Each line in the timeline is already evidence: something observable, recorded by a real system. What it lacks is any statement of what it relates to. "Deployment completed at 10:02" does not say what was deployed, which service it touched, or what depends on that service. "Error rate increases at 10:07" does not say on which service, whether that rate is unusual for the time of day, or whether queue depth and latency moved with it.
Add the context and the same evidence starts to bear weight. The deployment carried a change to session validation on the payments service. Checkout depends on that service. The error rate that moved is checkout's, it is well outside its normal band for a Tuesday morning, and queue depth rose in step with it. A similar sequence happened six weeks ago. Nothing new has been observed; the evidence has been tied to the systems it describes and to each other, and now it can support one hypothesis and weaken another.
The aim is not more signals. Engineers are not short of events; they are short of the relationships between them, and those relationships are what an assessment is built from.
The output is an assessment, not a summary
The useful output is not a summary of the timeline. A summary reads something like: "A deployment at 10:02 was followed by increased errors and a rollback at 10:18." True, and inert. Compare it with something closer to an engineering assessment:
Deployment 4f2a is currently the leading explanation for checkout degradation. Confidence increased after the error-rate and queue-depth changes aligned with the deployment window and the diff was found to touch session validation on the checkout path. Customer impact is bounded to a subset of sessions, so there is not yet enough evidence to recommend rollback over a targeted fix. A configuration change in the same window has not been ruled out.
That paragraph is an illustration, not the output of a production system. What matters is what it contains that the summary does not. A conclusion, stated as the leading explanation rather than a verdict. The confidence behind it, and what moved it. The evidence it rests on. The current impact. A recommendation with its reasoning attached. And an open alternative the assessment could still swing towards.
Each of those parts can be challenged, which is the point; a summary offers nothing to push against. It is worth being precise about what an assessment should contain. Each missing part is a question the team has to answer by hand.
It has to be able to change its mind
A postmortem tells a clean story because it is written once everyone knows the ending. An operational system does not have that luxury: the evidence is incomplete, some of it contradictory, and the most important fact may not have arrived yet. It has to hold its conclusions provisionally and say so.
In practice that means standing behind a sequence like this:
- 10:09: the deployment is currently the leading explanation.
- 10:13: a second symptom on an unrelated service has weakened that hypothesis.
- 10:15: a shared dependency is now the more likely cause; the deployment is not ruled out.
- 10:17: the dependency has recovered and the errors have not; rollback is now more strongly supported.
Each is a different assessment, and each was right when it was made, given the evidence available. A system that revised its view three times in eight minutes did not fail three times. It did its job. The failure would have been to commit at 10:09 and stop listening, which is how a plausible early story becomes a misdiagnosed incident.
That is continuous reasoning, and the record it leaves behind is more honest than a timeline: it keeps the hypotheses that were abandoned as well as the one that survived.
Incident intelligence should represent what the evidence supports now, not pretend the final answer was always obvious.
From timeline to assessment
The conventional pipeline runs from event collection to a timeline and, with luck, from there to understanding in somebody's head. That last step is where the real work happens, and none of the tooling does it.
events
→ timeline
→ understanding, in somebody's head
evidence
→ context
→ evolving assessment
→ action
The second sequence is the shape Ember is being built around: evidence kept in context, an assessment that moves as the evidence does, and the decision left with the team. The chain was already forming before the first alert; the assessment is that chain, kept connected and kept current. Whether AI can hold up its end of that is what our feasibility study with Robert Gordon University set out to test. Read the research.
The future of incident intelligence is not a better incident transcript. It is a system that remembers what happened, understands how the evidence connects, changes its mind when the evidence changes, and can show you why.
The timeline will still be there. It was never the problem. The problem was mistaking it for understanding.