Solution
Cited RCA and Postmortem
A root cause analysis nobody can check is an opinion with a timestamp on it. Every finding here links back to the change record, the signal or the log line behind it, so a reader can argue with the evidence rather than with the author.
- Every claimLinked to the change record, signal or log line that supports it, not summarised from them.What citation means here
- From the trailThe postmortem is generated from what actually happened, not reconstructed from memory afterwards.How it is assembled
- Amber existsSherlock returns verdicts nobody wanted, including that the symptom cleared while the cause stayed open.A design property
- Eleventh timeRecurring signatures become a problem record with an owner rather than another closed incident.Problem detection
What it changes
What citation buys you that a well-written summary cannot
Any competent language model can produce a fluent root cause narrative. Fluency is not the problem and never was. The problem is that a narrative you cannot check has to be believed or discarded whole, and neither is a reasonable thing to ask of an engineer.
Check one clause, not the whole chain
When each claim carries its source, disagreeing takes seconds. Without citations the only way to test a conclusion is to redo the investigation, which is why most people either accept the summary or ignore it.
Survive a regulator or an audit
In a regulated estate the question after an outage is not what you concluded, it is what you can show. A cited analysis and a generated action trail answer that directly, in the form the question is usually asked.
Stop closing the same incident forever
A signature that recurs is promoted into a problem record with an owner. Closing the same fault eleven times in a quarter produces a healthy-looking metric and an unhealthy system, and only one of those is visible on a dashboard.
Get told when it is not resolved
A procedure that finished is not an incident that ended. The verdict distinguishes the symptom clearing from the cause being addressed, and says which one happened.
How it works
The postmortem is the action trail, rendered
Nothing is written up after the fact. What was observed, which hypotheses were tested and dropped, which procedure ran and who approved it, what the post-check proved against live signals, and what remains open are all recorded as the incident happens. The document is a view of that record.
The uncomfortable design decisions
Two things that make this less impressive and more useful
Both cost us something in a demo. Both are the reason an engineer can read a closed ticket here and believe it.
A validator that only knows how to say yes is not a validator
Sherlock is built to return the answer nobody in the room wants. The most common version of that is an amber verdict where the symptom has cleared but the change that caused it is still in place, which is exactly the state that produces the same incident again next week.
Verification is also deliberately a different component from execution. The thing that ran the fix does not get to grade its own work, and that separation is doing more for trust than any accuracy claim would.
Say what would change the verdict
Every verdict states, up front, what evidence would move it. A reviewed rollback of the change, or a documented decision to keep it. That turns a conclusion into something a team can act against rather than something they have to accept or reject wholesale.
It also makes the platform falsifiable, which we think is the minimum bar for software allowed anywhere near a production incident record.
Evidence
What is actually recorded
Two different tiers below, labelled as such. Provenance on every automated fix is a structural property of a production deployment. Automated postmortem generation was demonstrated in a proof of concept and has not yet been measured in production, and we are not going to blur the two.
- Production deployment100%Of automated fixes carry full provenance: the RCA path that justified them, the actions taken, and the closure state.Basis: every fix, not a sample. A structural property rather than an average.Closed-loop automation →
- Production deployment7Network data domains correlated into one loop, where there had previously been seven separate systems of record.Basis: counted. Improvement percentages on that study are indicative, so we have not used them here.Closed-loop automation →
- Proof of conceptAutomatedPostmortems produced from the full investigation and action trail, rather than written up afterwards.Basis: generated from the action trail in a POC. Demonstrated, not measured in production.Orchestration POC →
See it on a real fault
Four analyses this describes
Each one walks a specific fault to a conclusion, including what the evidence supported and where it stopped short.
- SherlockThe same incident, for the eleventh time this quarterRead the walkthrough →
- Service OpsThe CPU spiked at 3am and the pager did its jobRead the walkthrough →
- Telemetry OpsThe break is somewhere on forty kilometres of fibreRead the walkthrough →
- Process OpsThe end-of-day batch that died at 23:52Read the walkthrough →
Questions we get asked
Frequently asked questions
What does cited actually mean? Every vendor says explainable.
Explainable usually means the model produced prose describing its reasoning, which is not the same as evidence. Cited here means each clause in a finding carries a link to the specific artefact behind it: a change record number, a counter at a timestamp, a log line. You can open the thing itself. If a claim has no artefact behind it, it is marked as inference rather than dressed up as fact.
How often is the root cause wrong?
We do not have a measured accuracy figure and will not invent one, because the honest answer depends heavily on how well instrumented an estate is. What we can tell you is how the design handles being wrong: the citations make the weak link findable in seconds, the verdict states what evidence would change it, and verification is run by a different component from the one that acted.
Can it produce a postmortem our regulator will accept?
It produces the record a regulator normally asks for, which is what was observed, what was decided, what ran, who approved it and what was verified afterwards, with the underlying artefacts linked. Whether a specific regulator accepts a specific format is a question about your obligations rather than about the platform, and we would want to see the actual requirement before answering it.
Does it work if we already have an incident management tool?
Yes, and it should. The platform writes into ITSM through native connectors rather than asking teams to work somewhere new. The analysis, the citations and the action trail attach to the record you already run your process on.
Go deeper
Where to read next
- SolutionL2, L3 and SRE AugmentationThe investigation that produces the analysis in the first place.
- SolutionGoverned Autonomous ExecutionWhy a failed post-check fires a rollback instead of closing a ticket.
- Case studyClosed-loop network automationProvenance on every automated fix, across seven data domains.
Bring us a postmortem you were not happy with
Preferably one where the conclusion was probably right and nobody could prove it. We will walk through which clauses could have carried a citation, and what the verdict would have said was still open.