2608.07230-From probability to causality in probabilistic logic programming

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "From probability to causality in probabilistic logic programming".

Jane: The paper was written by Zora Wurm, Kilian Rückschloß and Felix Weitkämper from Ludwig-Maximilians-Universität München and Eberhard-Karls-Universität Tübingen and German University of Digital Science.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Paper summary: Tom: This week we're looking at a paper that asks a deceptively simple question: when you learn a probabilistic logic program from data, can you trust it to answer causal questions? Not just probabilistic ones, but questions about what happens when you intervene in the system.

Jane: And the short answer is only sometimes, and the paper tells you exactly when. It's written by Zora Wurm, Kilian Rückschloß, and Felix Weitkämper, from Munich, Tübingen, and Potsdam.

Lu: For anyone who hasn't met one, a probabilistic logic program is a logic program where each rule carries a probability. So a rule might say that with probability pi, burning things produce smoke. The program as a whole induces a probability distribution over what's true.

Tom: Right, and the paper starts from the observation that learning such a program from data gives you only the probabilistic information. It doesn't tell you the direction of causation.

Jane: And that matters because the same distribution can be explained by fire causing smoke, smoke causing fire, or a hidden third cause behind both. The moment you want to intervene — force a variable, prescribe a treatment — the direction of those arrows is everything.

Meng: So they borrow a well-established idea from causal Bayesian networks, Markov equivalence and orientability, and bring it into logic programming.

Tom: Exactly. Orientability asks whether an edge direction is forced by every network encoding the same distribution. The paper transfers that question to logic programs, and then adds something the graph literature doesn't have — relational structure.

Lalam: And that's the part

Page 1 of the paper: Tom: So here's where the paper starts setting up the problem: once you learn a probabilistic logic program from data, you only get probabilities, and the causal direction might still be ambiguous.

Jane: Right, and on the very first page they make the connection to a classic idea — that a single probability distribution can be explained by multiple causal orders, like smoke coming from fire, fire from smoke, or a hidden cause behind both.

Tom: But what I found interesting on this page is how they frame the goal. They're not trying to learn causality from scratch. They're asking whether a program that's already been learned can support interventional reasoning at all.

Jane: And their bridge is the Bayesian network. They point out that any acyclic probabilistic logic program induces a distribution that can be represented as a Bayesian network, and prior work already showed that intervening on the program matches intervening on that network.

Tom: So the whole idea is to take the existing tool from Bayesian network literature — the orientation rules that tell you which edges are forced by the data — and transplant them into logic programming.

Jane: But then they add something that's genuinely new on this page. The relational structure gives you extra constraints that a plain propositional network doesn't have.

Tom: Exactly. If you have a rule that says a student's intelligence affects whether they pass a course, then every ground instance of that rule should have the same causal direction. The vocabulary itself imposes symmetries.

Jane: And that means you can orient edges that would otherwise be unorientable. The example they give is the burning objects — bonfires, houses, cigarettes — where the same cause-effect mechanism repeats across different instances.

Tom: That's the part I had to read twice. They're saying the relational alphabet itself is background knowledge, and you can use it to constrain the space of causal explanations.

Jane: So even with a single ground instance, as long as you accept the symmetries encoded by your predicates, you might still determine the causal order.

Tom: Right, and that's a big deal for practical use, because learned programs don't usually come with enough data to orient every edge locally.

Jane: Next they'll actually define the formal machinery — the dependency graphs, the orientation rules, and how symmetries are encoded. That's where things get technical.

Tom: Let's get to it.

Page 2 of the paper: Tom: Last time we set up the challenge: a probabilistic logic program learned from data gives you the probabilities, but not necessarily the causal order.

Jane: And page 3 makes that concrete with the drug example. You see patients on a drug with high blood pressure, and three stories fit the same numbers — the drug raises blood pressure, high blood pressure prompts the drug, or a hidden illness drives both.

Tom: That's the classic correlation-versus-causation moment. And it's why they bring in Pearl's causal Bayesian networks.

Jane: So they define a causal Bayesian network formally: a directed acyclic graph where each node carries a conditional probability given its parents. The graph encodes which way the arrows point.

Tom: Then they give the semantics — the probability of a configuration is the product of those conditionals. And here's a nice side note: once the graph is fixed, the parameters are actually uniquely determined.

Jane: That's a big deal, because it means all the ambiguity lives in the arrows. The numbers don't give you freedom; only the directions do.

Tom: Which brings them to interventions. The do-operation deletes all edges pointing into the node you're acting on, and forces the value you want.

Jane: So if you intervene on drug, you cut off whatever causes someone to take it, and you set it to "yes" or "no." Then you can read off the effect on blood pressure.

Tom: That matches the logic programming intuition too — you remove the rules that produce the atom and add a fact instead.

Jane: But they're careful to say this only works if your arrows actually follow the true causal flow. If the graph is wrong, your intervention is just graph surgery on a fiction.

Tom: And that raises the question they'll tackle next — when can the data itself tell you the arrows are forced? That's where Markov equivalence and faithfulness come in.

Jane: Let's look at that.

Page 3 of the paper: Tom: So last time we saw why the causal arrows matter, and we got the basic toolkit of d-separation and faithfulness.

Jane: Now page 5 gives us the payoff: a precise definition of when an edge’s direction is genuinely forced by the data.

Tom: Yeah, they call it orientability. An edge is orientable if it appears in every graph that’s Markov-equivalent to yours — meaning every graph encoding the same probabilistic independencies.

Jane: And then they bring in Meek’s classic result. He found a small set of local rules that, when you iterate them, give you every orientable edge in the graph.

Tom: So you start with the obvious cases — like an unshielded collider, where two arrows point into the same node and the sources aren’t connected. That direction is forced.

Jane: But the clever part is that orientable edges can then unlock other edges. Once you know one arrow’s direction, you can propagate that knowledge through the graph following those rules.

Tom: And this is exactly what the paper wants to borrow. If you have a probabilistic logic program, and its dependency graph turns out be fully orientable, then any other program that produces the same distribution must have the same graph.

Jane: Which means its interventions will match too. That’s their Proposition 3, and it gives a simple verifiable condition — orientability — for when a learned program supports causal reasoning.

Tom: But the page doesn’t stop there. It starts building the formal bridge, introducing propositional ProbLog programs with an external vocabulary for background facts and an internal vocabulary for the random variables.

Jane: And they are careful to restrict probabilities to values strictly between zero and one, because deterministic rules would break faithfulness and the whole orientability argument.

Tom: So the theory is clean for propositional programs. But logic programming is usually about relations, not just single propositions.

Jane: That’s the next piece — how to lift all this to relational programs. Let’s see how they handle that.

Page 4 of the paper: Tom: Last time we had the formal machinery for orientability; now we see how it actually plays out on a concrete program.

Jane: And the example they use is really intuitive: things burn if they're flammable, and burning things tend to smoke, especially if they're not dry.

Tom: So the program has three clauses, with the external facts like flammable and dry acting as background conditions.

Jane: And depending on which external facts hold, different clauses get activated. If flammable is true, you get the burns-to-smokes chain; if not, maybe nothing happens at all.

Tom: The key part is how they build the dependency graph from the activated rules, and then the semantics use noisy-or. So each clause contributes an independent chance of causing the effect.

Jane: That noisy-or is a nice fit for logic programming, because multiple rules can point to the same head, and the probabilities combine like independent mechanisms.

Tom: Then they define interventions on the program itself. You delete every clause that has the target atom as its head, and if you're forcing the atom true, you add a fact.

Jane: So if you want to force smoke, you cut the rules that produce smoke from burning, and you just assert smoke directly.

Tom: And Proposition 2 says something reassuring: doing that to the program gives exactly the same distribution as performing the corresponding intervention on the Bayesian network.

Jane: That's the bridge that makes everything else possible. It means the program's intervention semantics are faithful to the network's do-calculus.

Tom: So now they can claim their first real goal: verifying that a propositional program supports interventional reasoning, just by checking orientability.

Jane: And they're careful to note that faithfulness is required, and that deterministic rules would break it. So you should push those into the external database.

Tom: That's a pragmatic design choice, and it keeps the theory clean. But the example is still propositional — just a few atoms.

Jane: Real programs have relations, with variables and groundings. That's where the paper's own contribution really starts.

Tom: Let's see what happens when we move to relational programs and those causal symmetries.

Page 5 of the paper: Tom: Last time we saw how interventions work on propositional programs; now the paper moves to relational programs, where rules have variables and you ground them against a database.

Jane: And that’s a big step, because real probabilistic logic programs are almost always relational. You write one rule about students and courses, and it applies to every student and every course.

Tom: Right, so they lift the whole machinery. A relational clause looks like before, but the head and body are relational atoms with variables.

Jane: And the grounding step is the key: you take a database, say who takes which course, and substitute constants for variables. Every possible grounding becomes a propositional rule.

Tom: So the grounding produces a plain propositional program, and then everything from the earlier pages applies — the dependency graph, the Bayesian network, the interventions.

Jane: They’re careful to separate external predicates, which live in the database, from internal ones, which are the random variables. So "takes" is external, while "passes" and "int" are internal.

Tom: The example they give is nice — a single clause saying a student passes a course if they’re intelligent and they take the course. With two students and three courses, you get a cluster of edges.

Jane: And each edge points from the student’s intelligence to their grade in a particular course. So the same causal mechanism repeats across all the ground instances.

Tom: That repetition is exactly what the next section will exploit. The grounding produces many edges that all share the same direction because they come from the same rule.

Jane: So even if one of those edges can’t be oriented on its own, the others might help. That’s the seed of the causal symmetry idea.

Tom: Let’s see how they formalize that.

Page 6 of the paper: Tom: Last time we saw how relational programs ground into many edges that all come from the same rule; now the paper turns that repetition into a formal tool called a causal symmetry.

Jane: And it’s a clever twist on the standard orientation rules. Normally you only orient an edge if it’s forced in every Markov-equivalent graph. But now you can also say: these edges must all point the same way.

Tom: That’s Definition 17. A set of causal symmetries groups directed edges together, and a graph respects the symmetry if every edge in the group points in the same direction — all forward or all backward.

Jane: So if you know the cause-effect direction runs from intelligence to grades, that applies to every student and every course. You can’t have it point one way for Moe and the opposite way for Ana.

Tom: That immediately gives Proposition 4, which feels almost obvious: if one edge in a symmetry group turns out to be orientable, then all the others are orientable too.

Jane: Because any graph that respects the symmetry would have to flip them all together. So orienting one orients the whole group.

Tom: Then comes the real pay-off, Proposition 5. Standard Meek rules can orient unshielded colliders, where two arrows point into the same node. But they can’t orient an unshielded fork, where one node points to two separate nodes.

Jane: With a symmetry group, you can. If two edges form a symmetric fork and they belong to the same group, then orienting one forces the other, and you rule out the reversed fork entirely.

Tom: And that matters because forks are everywhere in relational data. A student’s intelligence causes their grade in math and their grade in English — that’s a fork.

Jane: So the paper gives you two new rules, and they work together. Proposition 5 gets you started on a fork, and Proposition 4 spreads the orientation to every edge in the symmetry group.

Tom: But the definition leaves the symmetry sets abstract. Where do they come from? The paper says you can take them from the relational vocabulary itself — that’s predicate symmetry.

Jane: We’ll see how that works, and where it can go wrong.

Page 7 of the paper: Tom: And now we get the concrete example that shows how powerful predicate symmetry really is.

Jane: Yeah, they take the UWCSE advisor example from the cplint suite. You have students, professors, projects, and the r11 relation that links them through publications.

Tom: The ground graph fragment is a tangle of r11 nodes pointing into advisedby nodes.

Jane: And if you only use the standard Meek rules, you can orient just one collider — the starred arrows.

Tom: But with the predicate symmetry assumption, all edges between r11 and advisedby must point the same way.

Jane: So once you orient one of those edges, every other edge between those two predicates follows automatically.

Tom: That's Proposition 4 in action. It turns a sparse local pattern into a global orientation.

Jane: And the nice thing is, this isn't an artificial toy. It comes from a real dataset about university webpages, the kind of relational data people actually work with.

Tom: So the practical payoff is clear. If you accept that the same pair of predicates always has the same causal direction, you can recover enough of the orientation to answer interventional questions.

Jane: They're upfront about that being a strong assumption. But they argue the relational vocabulary itself carries that assumption — it's part of how you define the domain.

Tom: They even point out where it breaks down, like time-stratified programs where causality flows one way between time steps and the other way for immunity.

Jane: In those cases you use prescribed orientations instead of symmetries, and they mention you can specify that in the implementation.

Tom: And speaking of implementation, they've put the whole thing on GitHub — in Prolog, using Logtalk and tabling.

Jane: So you can load your own program and see which edges come out orientable.

Tom: That makes this more than a theoretical contribution. You can actually test it.

Jane: Next they'll compare with earlier relational causal discovery work and talk about what's still missing.

Tom: Let's hear that.

Conclusion: Tom: So today we saw how to tell whether a probabilistic logic program actually supports causal reasoning, and the short version is: check if its dependency graph is orientable, and if you’re working relationally, use the symmetries in your vocabulary to get even further.

Jane: And the nice part is that this gives you a practical verification step for learned programs. You don’t have to trust that the learner found the true causal order; you can check whether the order is actually pinned down by the distribution.

Tom: Right, and if it isn’t, you know your interventional answers are ambiguous. That’s a real safeguard for anyone building decision systems on top of these programs.

Jane: They also made the whole thing concrete by showing how predicate symmetry can turn a single oriented edge into a whole family of oriented edges, like in that university advisor example.

Tom: And they were honest about the limits. The symmetry assumptions are strong, and determinism can break faithfulness entirely.

Jane: But they pointed to promising fixes, like the determinism-aware search method and the open question of whether these symmetry rules can be made complete.

Tom: The fact that they shipped an implementation on GitHub makes it even more useful. You can actually run this on your own programs.

Jane: Exactly. It moves the idea from a neat theoretical result to something you can test and build on.

Tom: For us, the big takeaway is that causal questions aren’t automatically off-limits just because you learned the program from data.

Jane: You just have to verify the conditions first, and now there’s a method for doing exactly that.

Tom: Next time we’ll pick up another paper that pushes statistical relational reasoning further, and we’ll see what other bridges can be built between logic, probability, and causation.

Jane: Looking forward to it.