An AI Mission for Telecom: Outage Root-Cause Summaries

Every operator writes one document after a major outage, and it is read by four groups of people who want four incompatible things from it. The document is not the real artifact. The reconstruction underneath it is — and most organisations never build that separately.

Two weeks after service is restored, the hard part of an outage begins. The bridge calls have ended, the escalations have gone quiet, and somewhere a senior engineer has been handed the job of writing the account of what happened. They open a blank document and immediately face a problem that has nothing to do with the network. Their colleagues in engineering want to know the mechanism — what actually propagated, in what order, and why the safeguards that should have contained it did not. The regulatory affairs team wants a defensible chronology with impact figures attached to intervals, in language that will survive being read years later by someone with no context. The enterprise account team has three large customers asking, in essence, whose fault this was and what will stop it recurring on their service. And an executive somewhere upstairs wants to know the shape of the exposure: how bad, how public, how likely to become a pattern. The engineer writes one document. It goes through six rounds of review. By the time it is signed, it is precise enough to be unreadable, hedged enough to be uninformative, and it satisfies none of the four audiences it was written for.

This is not a writing problem, and treating it as one is why the same frustration recurs after every significant incident. Four audiences with genuinely different questions are being served by a single flattened artifact, and flattening is lossy in exactly the ways that matter most to each reader. The mechanism the engineers need gets compressed into a phrase because a reviewer found the detail alarming; the chronology the regulator needs gets softened at the edges because someone worried how an interval would read to a customer; the accountability the customer wants gets deferred to a remediation table. What emerges is a negotiated document, and a negotiated document is a poor record of anything.

The four readers are not asking for different tones of the same answer

It is tempting to believe these audiences want the same facts at different levels of technicality — that the executive version is the engineering version with the jargon removed, and the customer version is the regulatory version with the numbers rounded. That belief is the source of most of the pain, because the four readers are not requesting different registers. They are requesting different selections from the same underlying set of events, organised along different axes, with different tolerances for uncertainty.

The engineering audience is asking a causal question, and causal answers branch. They want the failure mode, the interaction that made a normally survivable condition unsurvivable, the assumption baked into a control that turned out not to hold, and — crucially — the parts that remain genuinely uncertain, because uncertainty is where the next investment goes. A statement like "the contributing factors are still under analysis" is not a weakness to an engineer; it is the most useful sentence in the document. To a regulatory reader, the same sentence reads as an incomplete answer, because their question is not causal but temporal and quantitative: when did it begin, when was it detected, when was it acknowledged, when was service restored, and what was affected in each of those intervals. That reader is indifferent to which subsystem was elegant or ugly. They want a sequence that holds up, with impact bound to it, stated consistently every time it is stated.

The enterprise customer is asking a third question that neither of the first two answers: whether what failed sits inside the boundary of what they were promised, whether their own service was affected the way they experienced it, and what specifically changes. That question is about accountability and continuity, answered in the language of commitments rather than mechanisms. The executive is asking a fourth question entirely — about exposure. How large is the affected population, how does this compare to the last three events, and is there a pattern forming across the estate that has not yet been named. That reader needs comparison and trend, which means they need this incident placed alongside others, which is information the incident document by definition does not contain.

Serving all four with one artifact means each reader is handed a document optimised for someone else and asked to extract their own answer from it, which they do by scheduling meetings — and the meetings are where the real cost sits. An engineer who has already written the account spends the following fortnight re-explaining it four ways to four rooms, each dissatisfied for a different and legitimate reason, and each leaving with a slightly divergent understanding of the same event. Six months later, three teams describe the outage in three mutually inconsistent ways, none of which quite matches the signed document, and nobody can say which is authoritative.

What is durable is the reconstruction, not the prose

The way out is to stop treating the summary as the primary artifact and start treating it as an output. What genuinely deserves the organisation's care is the reconstructed timeline: an evidence-bound record of what occurred and when, with each entry tied to the source that establishes it, each impact figure tied to the measurement that produced it, and each causal claim explicitly marked as established, probable, or unresolved. This is a structured object rather than a narrative — closer to a ledger than an essay — and it has a property the narrative can never have, which is that it can be queried rather than merely read.

Once that object exists, the four documents stop being four writing tasks and become four projections of one source. The engineering account is a rendering that keeps the causal chain and the open questions and drops the impact arithmetic. The regulatory chronology is a rendering that keeps the sequence and the measured impact and drops the speculative branches, because it is a projection along the time axis with uncertainty deliberately excluded. The customer letter is a rendering filtered to the entries that touch that customer's service and the commitments attached to it. The executive brief is a rendering that keeps the magnitudes and places them beside prior events. All four are consistent by construction, because all four descend from the same ledger, and none of them can drift from the others without someone changing the ledger — which is a visible, reviewable act rather than a quiet edit in a Word document.

The conflation of timeline with narrative is expensive precisely because it destroys this property. When the narrative is the record, every editorial softening becomes a modification of the organisation's memory of the event; nobody intends this, and it happens because the sentence that made a reviewer uncomfortable was the sentence carrying the timestamp. Separating the two protects the record from the editing, and it protects the writers too: a reviewer arguing about emphasis in a projection is arguing about emphasis, not quietly rewriting history. The constraint that must not bend is honesty about the sequence itself, and it is far easier to hold that line when the sequence lives somewhere the prose cannot reach.

Reconstruction is the work worth handing to a system

Building that ledger by hand is brutal, which is the real reason organisations skip it and jump straight to prose. It means pulling intervals from monitoring, correlating them with ticket and change records, reconciling systems that disagree about when something started, gathering what was said on the bridge, and — hardest of all — noticing where the sources conflict rather than silently picking one. It is days of unglamorous correlation performed by the people least available to perform it, after the adrenaline has gone.

This is precisely the shape of work an AI Mission is suited to: bounded, evidence-driven, tolerant of being re-run as new material arrives, and valuable in proportion to how exhaustively it is done. A reasoning system with access to enterprise knowledge and the operational systems of record can assemble the candidate timeline, attach each entry to its source, flag where two systems disagree instead of resolving it by fiat, mark which causal links are supported and which are inferred, and generate the four projections from it. What such a system must never do is author the attested account on its own. Every projection is a draft that a named human owns, corrects, and signs, and the causal claims in particular are human judgements that the system prepares evidence for rather than reaches. The value is not that the writing gets automated; it is that the correlation gets done at all, and done the same way every time, so that the document a person signs is built on a reconstruction rather than on a recollection.

It is also where the ambition of this kind of work most often collapses. Gartner has predicted that over forty percent of agentic AI projects will be cancelled by the end of 2027, citing unclear value and inadequate risk controls alongside what it calls "agent washing." A system pointed at the wrong artifact will earn that fate: something that drafts a plausible narrative from a handful of tickets is a summariser wearing a badge, and it produces exactly the flattened document the organisation already had, faster. The version that matters is pointed at the reconstruction, where the labour actually is and where the evidentiary discipline can be enforced. That distinction — between generating output and maintaining a record from which output is derived — is one of the sharper lines running through the current work on what an autonomous enterprise actually requires, and platforms such as StudioX are built around the record-first side of it, with human sign-off wired into anything that leaves the building.

The mental model worth carrying away is that a root-cause summary is not a document an organisation writes; it is a view an organisation renders. If the only place the event is stored is the prose, then every reader is negotiating with every other reader over a single shared surface, and the organisation's memory of its own failure is whatever survived that negotiation. If the event is stored as a reconstruction, the negotiation moves to where it belongs — into the framing of each projection — and the record underneath stays fixed. Operators who make that separation stop asking how to write a summary that satisfies four audiences, because the question dissolves. They start asking a better one: how completely, and how quickly, can we reconstruct what happened, given that everything anyone will ever read about it is only a view of that.