# Incident Timeline & RCA Builder > Enter an incident's events as a small timeline and mark the contributing-factor domains you observed; a fixed rule set orders the timeline, derives the milestone spans, and structures candidate contributing factors with the evidence for each. It never names a root cause - candidates to investigate, not a verdict. - Tool: https://ronutz.com/en/tools/incident-timeline-rca-builder - Family: Operations & Fieldcraft --- ## What it does 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. Twelve vectors (six scenarios, six rejects) pin the current registry. 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. ## API input The API-parity entry takes a JSON object: `{"events": [{"id", "kind", "order", "note"}], "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; each factor needs a boolean `confirmed` flag. ## Standards and references - Original incident-RCA ruleset (D-18: original by construction) - the 7-rule registry, 9 contributing-factor domains with confirm/rule-out evidence, milestone/duration-band derivation, structural-completeness notes, and quality warnings are original editorial work encoding standard post-incident-review practice (timeline ordering, milestone spans, contributing-factor structuring, the no-root-cause-without-evidence discipline); no external framework or specification is claimed or reproduced ## Related reading - [Root Cause Is a Verb, Not a Noun](https://ronutz.com/en/learn/root-cause-is-a-verb-not-a-noun.md): The phrase root cause invites a single villain and a tidy ending. Real incidents rarely have one; they have contributing factors, and the honest work is structuring the candidates and the evidence that would confirm or rule out each - not naming a culprit before the evidence is in.