3 ms·
I think this is a very important area with applications to legal issues; in the computer systems domain, a close application I can think of is troubleshooting /
by xtacy 7y ago
I think this is a very important area with applications to legal issues; in the computer systems domain, a close application I can think of is troubleshooting / root-cause analysis.
In legal situations and troubleshooting alike, one is often interested not in the "general" causes of why things happen (e.g., an increase in load will contribute an increase in latency), but causes that explain specific cases (e.g., the increase in latency on this incident was because of an increase in file system latency at the backend.)
These concepts are quite interesting; one linked article discusses many variations and refinements in detail: https://plato.stanford.edu/entries/causation-law/ https://plato.stanford.edu/entries/causation-law/. I found these useful mental models to organize my thoughts when troubleshooting systems and doing root-cause analysis:
- But-for cause: We can say that A is the actual cause of B when the following holds: If not for A, not B. To avoid pathologies like "If not for big bang, this B wouldn't have happened", we have ...
- Proximal cause: In the causal chain of explanations: If not for A1, not A2; if not for A2, not A3, ..., the proximal cause of A(k) is the closest, i.e., A(k-1).
- Necessary element of a sufficient set (NESS criterion): Things get interesting here if we need a conjunction of many events to happen simultaneously for a desired effect. For simplicity, assume that events are boolean, and causal relationships can be defined using boolean formulae. Here, A is a cause of B in the NESS sense, when B = (A and C1) OR (C2 and C3) OR ... A here is "necessary" in the sufficient set {A, C1} for B to happen.
- whatshisface 7y agoOkay, so this is going to be a contraversial question but... How is any of that not obvious to someone who is investigating the cause of something?
- lmm 7y agoMost people have some vague sense that these aspects are important, and would probably come up with a similar taxonomy if pressed, eventually. But getting the details right and using consistent terminology matters; we don't usually notice how woolly our thinking is until we make a real effort to be precise. Think of something like the SemVer standard: "everyone knew" this was what version numbers meant, but writing it out explicitly in a precise way was actually really valuable.