The single most valuable capability in technical remediation is precedent recall. Not “find me a document about Exchange failures” but “walk me through exactly what happened the last time we had a mail flow failure at a financial services client, including what I tried, what worked, what did not, and what I wished I had done differently.”
I call this Incident Replay. It is Tessera’s killer feature for remediation work, and it required a dedicated architecture component to get right.
How Incident Replay Works
An Incident Replay query triggers a specialized retrieval path. First, the graph is traversed to find all Incident nodes matching the criteria. Each incident has a chronological chain of Decision nodes, Communication nodes, and Outcome nodes. The chain represents the full timeline of the incident from detection through resolution.
Second, the chain is serialized into a narrative: what happened, in what order, with what result. The narrative includes my decisions at each stage, the reasoning behind them (if captured in the artifacts), the stakeholder communications, and the final outcome assessment.
Third, the narrative is compared to the current situation. Where are the parallels? Where do the situations diverge? What decisions from the precedent are applicable and which are not? The comparison is surfaced alongside the replay so I can make informed judgments rather than blindly following past patterns.
The Chronological Challenge
Building accurate timelines from unstructured artifacts is harder than it appears. Emails have timestamps, but the decision they document may have been made hours or days earlier. Meeting notes reference dates inconsistently. Some artifacts have no reliable timestamp at all.
Tessera uses a multi-signal approach to timeline construction. Email timestamps are primary. Referenced dates in the content are secondary. Causal ordering (this decision must have preceded this outcome) provides constraints even when timestamps are missing. The resulting timeline is approximate but useful, and the approximation is disclosed in the replay narrative.
Accuracy matters here because remediation decisions are often time-sequenced. The order in which actions were taken matters as much as the actions themselves. Presenting a timeline with incorrect ordering could suggest a causal relationship that does not exist, leading to wrong conclusions about what worked and why.
What Makes This Different
A standard RAG system could find documents related to a past incident. Tessera does something fundamentally different: it reconstructs the incident as a decision sequence and presents it as a coherent narrative that I can learn from and apply to the current situation.
The difference is between finding information and understanding experience. Information tells you what happened. Experience tells you what it felt like to navigate it, what was confusing, what was clear, what you would do differently. Tessera captures experience, not just information, because the artifacts it ingests include my reflections, my corrections, and my post-mortems alongside the operational data.
This is the capability that justifies the entire project. Everything else, the life assistant features, the scheduling support, the personal management capabilities, those are valuable. But Incident Replay under pressure, when a client is down and I need to make good decisions fast, that is where Tessera earns its existence.