In Chapter 1, I said that my goal was to get definitions of notions like causality, responsibility, and blame that matched our natural language usage of these words and were also useful. Now that we are rapidly approaching the end of the book, it seems reasonable to ask where we stand in this project.

First some good news: I hope that I have convinced most of you that the basic approach of using structural equations and defining causality in terms of counterfactuals can deal with many examples, especially once we bring normality into the picture. Moreover, the framework also allows us to define natural notions of responsibility, blame, and explanation. These notions do seem to capture many of the intuitions that people have in a natural way.

Next, some not-so-good news: One thing that has become clear to me in the course of writing this book is that things haven’t stabilized as much as I had hoped they would. Just in the process of writing the book, I developed a new definition of causality (the modified HP definition) and a new approach to dealing with normality (discussed in Section 3.5), and modified the definitions of responsibility, blame, and explanation (see the notes at the end of Chapters 6 and 7). Although I think that the latest definitions hold up quite well, particularly the modified HP definition combined with the alternative notion of normality, given that the modified HP definition is my third attempt at defining causality, and that other researchers continue to introduce new definitions, I certainly cannot be too confident that this is really the last word. Indeed, as I have indicated at various points in the book, there are some subtleties that the current definition does not seem to be capturing quite so well. To my mind, what is most needed is a good definition of agent-relative normality, which takes into account the issues discussed in Example 6.3.4 (where A and B can flip switches to determine whether C is shocked) and meshes well with the definition of causality, but doubtless others will have different concerns.

(p.204) Moreover, when we try to verify experimentally the extent to which the definitions that we give actually measure how people ascribe causality and responsibility, the data become messy. Although the considerations discussed in Chapter 6 (pivotality, normality, and blame assignments) seem to do quite a good job of predicting how people will ascribe causal responsibility at a qualitative level, because all these factors (and perhaps others) affect people’s causality and responsibility judgments, it seems that it will be hard to design a clean theory that completely characterizes exactly how people acribe causality, responsibility, and blame at a more quantitative level.

So where does this leave us? I do not believe that there is one “true” definition of causality. We use the word in many different, but related, ways. It is unreasonable to expect one definition to capture them all. Moreover, there are a number of closely related notions—causality, blame, responsibility, intention—that clearly are often confounded. Although we can try to disentangle them at a theoretical level, people clearly do not always do so.

That said, I believe that it is important and useful to have precise formal definitions. To take an obvious example, legal judgments depend on causal judgments. A jury will award a large settlement to a patient if it believes that the patient’s doctor was responsible for an inappropriate outcome. Although we might disagree on whether and the extent to which the doctor was responsible, the disagreement should be due to the relevant facts in the case, not a disagreement about what causality and responsibility mean. Even if people confound notions like causality and responsibility, it is useful to get definitions that distinguish them (and perhaps other notions as well), so we can be clear about what we are discussing.

Although the definition(s) may not be able to handle all the subtleties, that is not necessary for them to be useful. I have discussed a number of different approaches here, and the jury is still out on which is best. The fact that the approaches all give the same answers in quite a few cases makes me even more optimistic about the general project.

I conclude the book with a brief discussion of three applications of causality related to computer science. These have the advantage that we have a relatively clear idea of what counts as a “good” definition. The modeling problem is also somewhat simpler; it is relatively clear exactly what the exogenous and endogenous variables should be, and what their ranges are, so some of the modeling issues encountered in Chapter 4 no longer arise.

8.1 Accountability

The dominant approach to dealing with information security has been preventative: we try to prevent someone from accessing confidential data or connecting to a private network. More recently, there has been a focus on accountability: when a problem occurs, it should be possible after the fact to determine the cause of the problem (and then punish the perpetrators appropriately). Of course, dealing with accountability requires that we have good notions of causality and responsibility.

The typical assumption in the accountability setting, at least for computer science applications, is that we have logs that completely describe exactly what happened; there is no uncertainty about what happened. Moreover, in the background, there is a programming language. An adversary writes a program in some pre-specified programming language that interacts with the system. We typically understand the effect of changing various lines of code. The (p.205) variables in the program can be taken to be the endogenous variables in the causal model. The programs used and the initial values of program variables are determined by the context. Changing some lines of code becomes an intervention. The semantics of the program in the language determines the causal model and the effect of interventions.

The HP definitions of causality and responsibility fit this application quite well. Of course, if some logs are missing, we can then move to a setting where there is an epistemic state, with a probability on contexts; the contexts of interest are the ones that would generate the portion of the log that is seen. If we are interested in a setting where there are several agents working together to produce some outcome, blame becomes even more relevant. Agents may have (possibly incorrect) beliefs about the programs that other agents are using. Issues of which epistemic state to use (the one that the agent actually had or the one that the agent should have had) become relevant. But the general framework of structural equations and the definitions provided here should work well.

8.2 Causality in Databases

A database is viewed as consisting of a large collection of tuples. A typical tuple may, for example, give an employee’s name, manager, gender, address, social security number, salary, and job title. A standard query in a database may have the form: tell me all employees who are programmer analysts, earn a salary of less than $100,000, and work for a manager earning a salary greater than $150,000. Causality in databases aims to answer the question: Given a query and a particular output of the query, which tuples in the database caused that output? This is of interest because we may be, for example, interested in explaining unexpected answers to a query. Tim Burton is a director well known for fantasy movies involving dark Gothic schemes, such as “Edward Scissorhands” and “Beetlejuice”. A user wishing to learn more about his work might query the IMDB movie database (www.imdb.com) about the genres of movies that someone named Burton directed. He might be surprised (and perhaps a little suspicious of the answer) when he learns that one genre is “Music and Musical”. He would then want to know which tuple (i.e., essentially, which movie) caused that output. He could then check whether there is an error in the database, or perhaps other directors named Burton who directed musicals. It turns out that Tim Burton did direct a musical (“Sweeney Todd”); there are also two other directors named Burton (David Burton and Humphrey Burton) who directed other musicals.

Another application of the causality definition is for diagnosing network failures. Consider a computer consisting of a number of servers, with physical links between them. Suppose that the database contains tuples of the form (Link(x , y), Active(x ), Active(y)). Given a server x, Active(x) is either 0 or 1, depending on whether x is active; similarly Link(x, y) is either 0 or 1 depending on whether the link between x and y is up. Servers x and y are connected if there is a path of links between them, all of which are up, such that all servers on the path are active. Suppose that at some point the network administrator observes that servers x0 and y0 are no longer connected. This means that the query Connected (x₀, y₀) will return “false”. The causality query “Why did Connected(x₀, y₀) return ‘false’?” will return all the tuples (Link(x , y), Active(x ), Active(y)) that are on some path from x₀ to y₀ such that (p.206) either server x is not active, server y is not active, or the link between them is down. These are the potential causes of Connected (x₀, y₀) returning “false”.

I now briefly sketch how this is captured formally. As I said, a database D is taken to be a collection of tuples. For each tuple t, there is a binary variable X_t, which is 0 if the tuple t is not in the database of interest and 1 if it is. We are interested in causal models where the context determines the database. That is, the context determines which variables X_t are 1 and which are 0; there are no interesting structural equations. There is assumed to be a query language L^Q that is richer than the language L(S) introduced in Section 2.2.1. Each formula φ‎ ∈ L^Q has a free variable x that ranges over tuples. There is a relation ⊨ such that, for each tuple t and formula φ‎ ∈ L^Q, either D ⊨ φ‎(t) or D ⊨ ¬φ‎(t) (but not both). If D ⊨ φ‎(t), then t is said to satisfy the query φ‎ in database D. In response to a query φ‎, a database D returns all the tuples t such that D ⊨ φ‎(t).

We can easily build a causal language based on L^Q in the spirit of L(S). That is, instead of starting with Boolean combinations of formulas of the form X = x, we start with formulas of the form φ‎(t), where φ‎ ∈ L^Q and t is a tuple in addition to formulas of the form X_t = i for i ∈ {0, 1}. If M is a causal model for databases, since each causal setting $\left(M,\overrightarrow{u}\right)$ determines a database, $\left(M,\overrightarrow{u}\right)$ ⊨ φ‎(t) exactly if D ⊨ φ‎(t), where D is the database determined by $\left(M,\overrightarrow{u}\right)$ and $\left(M,\overrightarrow{u}\right)$ ⊨ X_t = 1 exactly if t ∈ D. We can then define $\left[\overrightarrow{X}\leftarrow \overrightarrow{x}\right]\phi$ just as in Section 2.2.1.

Of course, for causality queries to be truly useful, it must be possible to compute them efficiently. To do this, a slight variant of the updated HP definition has been considered. Say that tuple t is a cause of the answer t^ʹ for φ‎ if

D1. $\left(M,\overrightarrow{u}\right)$ ⊨ (X_t = 1) ∧ φ‎(t^ʹ) (so t ∈ D and D ⊨ φ‎(t^ʹ), where D is the database determined by $\left(M,\overrightarrow{u}\right)$); and

D2. there exists a (possibly empty) set T of tuples contained in D such that t /∈ T, D − T |= φ‎(t^ʹ), and D − (T ∪ {t}) ⊨ ¬φ‎(t^ʹ).

If the tuple t is a cause of the answer t^ʹ for φ‎ in $\left(M,\overrightarrow{u}\right)$, then X_t = 1 is a cause of φ‎(t^ʹ) in $\left(M,\overrightarrow{u}\right)$. D1 is just AC1. Translating to the kinds of formulas that we have been using all along, and taking ${\overrightarrow{X}}_T$ to consist of all the variables X t^ʹʹ such that t^ʹʹ ∈ T, the second clause says: $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_T\leftarrow \overrightarrow{0}\right]\phi \left(t^{\prime }\right)$ and $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_T\leftarrow \overrightarrow{0},X_t\leftarrow 0\right]\neg \phi \left(t^{\prime }\right)$. Thus, it is saying that $\left({\overrightarrow{X}}_T,\overrightarrow{\text{0}}\text{,0}\right)$ is a witness to the fact that X_t = 1 is a cause of φ‎(t^ʹ) according to the original HP definition; AC2(b^o) holds. Note that AC3 is satisfied vacuously.

This does not necessarily make X_t = 0 a cause of φ‎(t^ʹ) according to the updated HP definition. There may be a subset t^ʹ of T such that $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_{T^{\prime }}\leftarrow 0\right]\neg \phi \left(t^{\prime }\right)$, in which case AC2(b^u) would fail. Things are better if we restrict to monotone queries, that is, queries ψ‎ such that for all t^ʹ, if D ⊨ ψ‎(t^ʹ) and D ⊆ D^ʹ, then D^ʹ |= ψ‎(t^ʹ) (in words, if ψ‎(t^ʹ) holds for a small database, then it is guaranteed to hold for larger databases, with more tuples). Monotone queries arise often in practice, so proving results for monotone queries is of practical interest. If φ‎ is a monotone query, then AC2(b^u) holds as well: if $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_T\leftarrow 0\right]\phi \left(t^{\prime }\right)$, then for all subsets T^ʹ of T, we must have $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_{T^{\prime }}\leftarrow 0\right]\phi \left(t^{\prime }\right)$ (because $(M, \overrightarrow{u})\models \left[{\overrightarrow{X}}_{T^{\prime }}\leftarrow 0\right]\phi \left(t^{\prime }\right)$ iff D − t^ʹ |= φ‎(t^ʹ), and if T^ʹ ⊆ T, then D − T ⊆ D − T^ʹ, so we can appeal to monotonicity). It is also easy to see that for a monotone query, this definition also guarantees that X_t = 1 is part of a cause of φ‎(t^ʹ) according to the modified HP definition.

(p.207) The second clause has some of the flavor of responsibility; we are finding a set such that removing this set from D results in t being critical for φ‎(t^ʹ). Indeed, we can define a notion of responsibility in databases by saying that tuple t has degree of responsibility 1/(k + 1) for the answer t^ʹ for φ‎ if k is the size of the smallest set T for which the definition above holds.

Notice that I said “if t is a cause of the answer t^ʹ for φ‎ in $\left(M,\overrightarrow{u}\right)$, then X_t = 1 is a cause of φ‎(t^ʹ) in $\left(M,\overrightarrow{u}\right)$” I did not say “if and only if”. The converse is not necessarily true. The only witnesses $\left(\overrightarrow{W},\overrightarrow{w},\text{ 0}\right)$ that this definition allows are ones where $\overrightarrow{w}=\overrightarrow{0}$. That is, in determining whether the counterfactual clause holds, we can consider only witnesses that involve removing tuples from the database, not witnesses that might add tuples to the database. This can be captured in terms of a normality ordering that makes it abnormal to add tuples to the database but not to remove them. However, the motivation for this restriction is not normality as discussed in Chapter 3, but computational. For causality queries to be of interest, it must be possible to compute the answers quickly, even in huge databases, with millions of tuples. This restriction makes the computation problem much simpler. Indeed, it is known that for conjunctive queries (i.e., queries that can be written as conjunctions of basic queries about components of tuples in databases—I omit the formal definitions here), computing whether t is an actual cause of φ‎ can be done in time polynomial in the size of the database, which makes it quite feasible. Importantly, conjunctive queries (which are guaranteed to be monotone) arise frequently in practice.

8.3 Program Verification

8.4 Last Words

These examples have a number of features that are worth stressing.

• The language used is determined by the problem in a straightforward way, as is the causal model. That means that many of the subtle modeling issues discussed in Chapter 4 do not apply. Moreover, adding variables so as to convert a cause according to the updated HP definition to a cause according to the original HP definition, as in Section 4.3, seems less appropriate. There is also a clear notion of normality when it comes to accountability (following the prescribed program) and model checking (satisfying the specification). In the database context, normality plays a smaller role, although, as I noted earlier, the restriction on the witnesses considered can be viewed as saying that it is abnormal to add tuples to the database. More generally, it may make sense to view removing one tuple from the database as less normal than removing a different tuple.

• In Chapter 5, I raised computational concerns on the grounds that if causality is hard to compute and structural-equations models are hard to represent, then it seems implausible that this is how people evaluate causality. The examples that people work with are typically quite small. In the applications discussed in the chapter, the causal models may have thousands of variables (or even millions, in the case of databases). Now computational concerns are a major issue. Programs provide a compact way to represent many structural equations, so they are useful not only conceptually, but to deal with concerns regarding compact representations. And, as I have already observed, finding special cases that are of interest and easy to compute becomes more important.

• (p.212) It is certainly important in all these examples that responses to queries regarding causality agree with people’s intuitions. Fortunately, for all the examples considered in the literature, they do. The philosophy literature on causality has focused on (arguably, obsessed over) finding counterexamples to various proposed definitions; a definition is judged on how well it handles various examples. The focus of the applications papers is quite different. Finding some examples where the definitions do not give intuitive answers in these applications is not necessarily a major problem; the definitions can still be quite useful. In the database and program verification applications, utility is the major criterion for judging the approach. Moreover, even if a database system provides unintuitive answers, there is always the possibility of posing further queries to help clarify what is going on. Of course, in the case of accountability, if legal judgments are going to be based on what the system says, then we must be careful. But in many cases, having a transparent, well-understood definition that gives predictable answers that mainly match intuitions is far better than the current approach, where we use poorly defined notions of causality and get inconsistent treatment in courts.

The applications in this chapter illustrate just how useful a good account of causality can be. Although the HP definition needed to be tweaked somewhat in these applications (both because of the richer languages involved and to decrease the complexity of determining causality), these examples, as well as the many other examples in the book, make me confident that the HP definition, augmented by a normality ordering if necessary, provides a powerful basis for a useful account of causality. Clearly more work can and should be done on refining and extending the definitions of causality, responsibility, and explanation. But I suspect that looking at the applications will suggest further research questions quite different from the traditional questions that researchers have focused on thus far. I fully expect that the coming years will give us further applications and a deeper understanding of the issues involved.