Reading a Timeline to Separate Cause From Coincidence

Why this matters

A single claimed link is easy to test: did the storm cause this or not. The harder version is a call with three or four events piled into the same few weeks, a repair, a remodel, a heat wave, a new appliance, and one symptom that started somewhere in the middle. You cannot interrogate each pair in isolation; you have to lay every event on one ordered line and read the shape of it. Get that reading wrong and you blame the wrong event, quote the wrong fix, and point the customer at the wrong contractor. The timeline is a diagnostic artifact. This is how you read it.

Build the line before you read it

Put every dated event on one sequence: symptom onset, any repairs or installs, weather events, other trades' visits, usage changes, power events. Get the customer to anchor each to something they remember rather than a vague month. The goal is order and gaps, not perfect dates. Once it is on the line, stop adding and start reading the relationships between entries.

The tells that turn a cause into a coincidence

• The symptom predates the suspect. If the problem was already happening before the event that supposedly caused it, the case is closed against that event, no matter how confident the customer is. This one tell overrides all the others. Always pin symptom onset first.
• The latency is wrong for the mechanism. Every real cause has a plausible delay. A surge damages electronics now, not gradually over two months. A slow leak stains over weeks, not the same afternoon. If the gap between event and symptom does not fit any physical path, the timing is likely coincidence, unless you can name a delayed mechanism (a slow corrosion, a filter loading up) that actually fits the gap.
• No dose-response. A big cause usually makes a big effect. A minor event followed by a catastrophic failure, or a violent event followed by a trivial one, is a mismatch that argues for coincidence, though a marginal component already at the edge can be tipped by a small push, so weigh its prior condition.
• The survivor test fails. If identical neighbors saw the same event and are fine, the event alone does not explain the failure. One unit down out of several that shared the same storm points more to that unit's own condition than to the storm.

When two suspects share one day

The messy case is two plausible causes landing together: the panel upgrade and the new appliance the same week, the roof work and the first hard rain. You cannot attribute to one without a differentiator. Find the evidence that only one of them would produce: a failure signature that matches an electrical cause but not a water cause, damage located where one path reaches and the other does not. If nothing separates them, say so, and treat both as open rather than picking the one that is easier to bill or blame.

The reversibility check

The strongest confirmation on a live system is to undo the suspected cause and watch. Stagger the two appliances that supposedly conflict; disable the newer control; take the added load off. Safety branch first: before you back out any wiring, gas, or pressure change to test a theory, de-energize or relieve pressure and verify it is safe, never test-by-reversal on an energized or pressurized hazard. If removing the suspect makes the symptom go and restoring it brings the symptom back, that is causation you can stand behind. If nothing changes either way, the timeline was coincidence.

Say what the line shows, and what it does not

Bring the customer onto the timeline with you. Acknowledge the event they noticed, then show them the tell that confirms or clears it: the symptom that predates it, the neighbor that survived it, the reversal that changed nothing. A root-cause statement built on order, latency, and a matching signature holds up. One built on nothing but before and after does not, and a customer walked through the evidence accepts a coincidence far better than a flat contradiction.

References

• Basic principles of root-cause analysis (5 Whys, cause-and-effect method)
• Trade-standard practice for multi-event fault attribution
• See related: Distinguishing Coincidence From Causation in Fault Timing; Building a Forensic Timeline From Physical Evidence