Temporal Root Cause Analysis with Immutable Event Logs

A protected event history is evidence to investigate, not proof of what caused an incident. Causal inference requires information and assumptions beyond the observed data. We therefore recommend separating the recorded sequence from the explanation for it before choosing a safety intervention.

The useful question is specific: which control should have operated, what evidence shows whether it did, and what will we change? We would start there rather than commission a system that promises to predict compliance breaches.

Establish what the record can prove

For this work, we use immutable event logs to mean records that ordinary application actions cannot overwrite, with separately defined retention and administrative controls. We would document that boundary rather than describe the entire system as tamper-proof.

There are distinct engineering mechanisms to consider. Signed syslog specifies authentication, message integrity, sequencing and detection of missing transmitted messages. NIST describes checking archived logs against protected message digests. Neither mechanism should be presented as a measurement of workplace safety or a causal explanation.

Our acceptance test would ask who can change the record, who can change the verification material and whether the reviewer can detect the attempted change. For a proposed SQL hash chain, require a demonstration with privileged access as well as an ordinary application account. Test replacement of both the records and their verification material, not merely an edit to one row. Keep the verification result with the investigation.

We would also distinguish an event that was never captured from a record that was subsequently changed. Do not report either as a successful inspection. Record gaps as gaps, with an owner responsible for resolving them.

Reconstruct time without inventing precision

NIST warns that inaccurate host clocks can produce misleading event ordering across logs. We recommend recording the reported occurrence time separately from the time the server received the event. Add the source, asset identifier, responsible account and any known uncertainty about the clock.

For offline field work, ask the investigator to review both times before deciding the order. Mark a late upload explicitly. Do not silently convert receipt order into a claim about when work happened.

Preserve the original entry when correcting a mistake. Our suggested correction record includes the earlier event identifier, the corrected value, the reason and the person authorising it. Keep the investigation's interpretation separate from these underlying records.

For each reconstructed step, label it observed, reported, inferred or unknown. Ask another reviewer to challenge the inferred steps and list the missing evidence. Only then write the account of the incident.

Investigate causes beyond the event sequence

HSE distinguishes immediate, underlying and root causes in its investigation guidance. Its approach includes physical evidence, witness accounts and written information. We would use the event history alongside that material, not let the database decide which explanation is true.

Consider a hypothetical equipment incident following an overdue inspection. Ask whether the inspection was actually missed, completed but recorded late, or entered against the wrong asset. Then ask whether the proposed inspection would have detected the defect involved. Treat each answer as a separate proposition requiring evidence.

If a graph is useful, draw the proposed relationships between the defect, inspection, work allocation and incident. Label each connection as a hypothesis and attach the evidence needed to assess it. A graph database is an optional way to organise this investigation, not our criterion for accepting its conclusions.

Causal analysis requires explicit assumptions about how the data arose. For that reason, we would ask what else changed before attributing an outcome to a missed check or a new intervention. Record plausible alternative explanations and the evidence against them.

Choose an indicator for a named control

HSE's process safety guidance defines leading indicators around routine checks that critical activities happen as intended. It also uses lagging indicators to examine failures of the intended safety outcome. Its stated audience is chemical and major hazard industries. We would not present that guidance as a validation study of predictive event-log software.

For the hypothetical inspection problem, we suggest monitoring overdue safety-critical inspections against the inspections due in the same period. Agree the eligible asset population before calculating the measure. Show missing or disputed records separately rather than treating them as completed work.

Choose a response with the safety lead before introducing an alert. Name the person who reviews it, the action they may authorise and the escalation route when the underlying record is uncertain. Do not describe the threshold as a validated predictor of accidents.

Keep near-miss reporting available for investigation. Avoid judging a team solely by a falling count of reports. We would ask whether the reporting process changed and whether workers still have a practical way to raise concerns.

Test the response and retain the reasoning

We recommend a small pilot around one control and one accountable owner. Write down the indicator definition, review interval and proposed response before examining the results. Preserve revisions so a later reviewer can distinguish a changed definition from a changed outcome.

Review a sample of alerts against the original evidence. Record false alarms, unresolved cases and occasions when the alert arrived too late to support the intended response. Keep those findings alongside the headline measure.

Do not infer prevention from an absence of incidents during the pilot. Ask whether the control operated as specified and what evidence would support a stronger outcome claim. Retain the decision, its evidence and its limitations with the action record.

Start with one incident reconstruction that another person can reproduce. Then test one indicator against a named control. We would only extend the system after reviewing the recording gaps, disputed explanations and response failures found in that exercise.

Update, October 2026

For related engineering reading, see our design rules for keeping summaries linked to original evidence.

Sources

• HSE, "Investigating accidents and incidents", HSG245, 2004.
• NIST, "Guide to Computer Security Log Management", SP 800-92, September 2006.
• IETF, "Signed Syslog Messages", RFC 5848, May 2010.
• HSE, "Developing process safety indicators", HSG254, first edition, 2006.
• Judea Pearl, "Causal inference in statistics: An overview", 2009.