Causal inference, causality operators and actionable information

Following on a comment by David on the CEP forum, I think that it’s important to recognize the various ideas that are being discussed here.

We have been discussing the idea of a “causality operator,” by which I mean the kind discussed by David Luckham in The Power of Events (see this post). If you have a set of events and you can form a relation where you know exactly which events “caused” which other events, then you can write Y<X for “Y is caused by X” and will have created a POSET or DAG structure on those events.

But forming a graph of causality is not the same as causal inference and certainly not the same as recognizing a pattern that provides actionable information. Most pattern detection and even causal inference stops well short of forming a causality graph for all data. Many methods explicitly focus on summarizing all the relationships in a sample rather than on the relationship between any two specific observations. But none the less, these methods can produce actionable information. For example, no one would argue that good grades cause a student to be a better driver, but still most automobile insurance in the US gives students a discount for good grades.

To make forming the graph even harder, many causal relationships come down to a statement that two events were probably caused by the same external event, but we can’t really be sure what that external event was. We can’t even find a definition of a causality operator that everyone will agree on. Let’s say that both events X and Y “caused” event Z. We could write this as “Z<X and Z<Y”. But do we mean that Z would absolutely not have happened without both X and Y? Or that Z might have happened given only X, but then Y made Z certain to happen? Or that X and Y are the only two events that we know of, which contributed to Z, but that there are probably other factors?

And then sometimes we do have an identifiable and explicit causality relationship (like the ones that fill The Power of Events).

Given the broad nature of the topic here, I think that it’s easy to see why attempts to summarize the capability of particular pieces of software using single sentence descriptions doesn’t go over well. These applications are trying to solve many different problems at once and most of them do it in ways that defy a simple description.