What it does

RCA stands for root cause analysis - the structured, evidence-first review of how an incident actually happened. Enter an incident's events as a small structured timeline - each event a kind (change made, symptom began, alert fired, detected, mitigated, resolved, and so on) with an order you control and an optional note - and mark which contributing-factor domains you observed. A fixed registry of seven original rules fires deterministically and produces three things. First, an ordered, labelled timeline with the detection, mitigation, and resolution milestones highlighted and the spans between them derived (in event-count terms, because the tool has no clock and you control the order). Second, a set of candidate contributing factors to investigate, drawn from nine domains, each with the evidence that would confirm it and, just as important, the evidence that would rule it out. Third, notes on the timeline's own completeness (no detection milestone recorded, a long gap before detection, no change in the timeline) and cautions about the input. One click exports a Markdown RCA scaffold for the review.

What it deliberately is not

This tool never names a root cause. That is the whole point of it. An RCA is written by people from evidence, in a real review; this scaffolds that work by structuring the candidates and the evidence each would need, so nothing is missed and no conclusion is jumped to. A factor is only ever shown as confirmed when you tick its own "mark confirmed" control, and it is always attributed to you, never asserted by the tool. It assigns no blame, makes no network connections, asks for no credentials, and replaces neither a post-incident review nor a vendor RCA. The free-text notes flow only into the exported scaffold; they never influence which rules fire.

How the scaffold is built - and how it is verified

The timeline is ordered by the position you give each event; the engine reads no clock. Milestone spans are reported as the number of events between two milestones, not as wall-clock time, which the tool has no way to know. Each contributing-factor domain you observe becomes a candidate; the timeline can add more (a change in the timeline adds the recent-change candidate; a long gap before detection adds the monitoring-gap candidate and a structural note). Every candidate carries both confirm and rule-out evidence, because an honest scaffold shows how to close a question either way. The "Why these candidates?" panel lists every fired rule with its reason, so the structure is auditable rather than oracular.

Because there is no single "correct" scaffold for an advisory tool, classic golden vectors do not apply. The verification model - the ruling set by the Fault Hypothesis Builder pilot for the whole Operations and Fieldcraft family - is rule-firing snapshot vectors: for each test input, the build asserts exactly which rules fire, the exact ordered timeline, the exact milestone spans, the exact candidate list with each candidate's confirmed flag, the exact structural notes, and the exact cautions. Eighteen vectors (ten scenarios, eight rejects) pin the current registry and the clock check below. One of them is a language invariant checked by machine: no candidate can ever be marked confirmed unless the input confirmed it, so the no-root-cause discipline is enforced by the build, not just by intent.

The clock check

Records from different sources carry times from different clocks, and putting them in order by their timestamps can claim an order the clocks cannot support. An optional section of the form takes, for any event, the time its source logged, that source's clock offset and the uncertainty left after correcting it, all in whole milliseconds on one shared scale. The offset uses NTP's own sign: RFC 5905 defines the offset as the time offset of the server clock relative to the system clock, so with a trusted reference as the server it is the reference minus the source, and a source running 100 ms fast has an offset of -100. Each event's corrected time is then the logged time plus the offset, widened by the uncertainty either side.

The tool compares consecutive clocked events in the order you gave. If the first interval ends before the second starts, the clocks support the order. If the second ends before the first starts, the clocks contradict it, and a caution says so. If the intervals overlap or merely touch, the clocks cannot establish the order at all, and a caution says to keep it only if other evidence supports it, such as one transaction identifier seen in both records. For example, a symptom logged at 1000 ms by a source 100 ms fast and a detection logged at 1100 ms by a synchronised source, each within 100 ms, give 800 to 1000 against 1000 to 1200: touching intervals, so the order is not established. The check is arithmetic only and never changes which rules fire; the export lists every pair under its own heading.

API input

The API-parity entry takes a JSON object: {"events": [{"id", "kind", "order", "note", "clock": {"reportedMs", "offsetMs", "uncertaintyMs"}}], "factors": [{"domain", "confirmed"}], "notes": {"summary", "followups"}}. Event kinds and factor domains use the closed vocabularies shown in the form; an out-of-vocabulary value is a format error, never a guess. events must not be empty; each event needs an id and a numeric order; clock is optional, and when present its three fields are whole milliseconds with uncertaintyMs 0 or more; each factor needs a boolean confirmed flag.

Sources