Causal discovery for data scientists
Where causal discovery fits next to machine learning: prediction versus intervention, a workflow from question to validated effect, common pitfalls (leakage, colliders, too many columns), and how to use UCMT Labs from your own pipeline.
Prediction is not intervention
A model with excellent accuracy can still give the wrong answer to "what if we change X?". It learns whatever predicts the target, including variables that only move with it or are caused by it. Feature importance and SHAP values explain the model, not the world: a high importance does not mean that changing the feature changes the outcome.
Causal discovery addresses the other question. It estimates the structure behind the data, so that effects of interventions can be reasoned about and estimated on the right set of variables.
A workflow
- Question and target. Name the outcome and the variables you could change. A causal question has an action in it.
- Data check. One row per unit, numeric columns, no IDs, no columns computed from the target.
- Discover with two or more methods from different families (see Choosing a method). Keep the links they agree on.
- Add what you know. Time order and known impossibilities remove whole classes of wrong arrows.
- Estimate effects on the paths that matter.
- What-if scenarios for the decisions on the table.
- Validate on a hold-out period, or better, with an A/B test on the top recommendation.
Pitfalls
| Pitfall | What goes wrong | What to do |
|---|---|---|
| Leakage | A column measured after the outcome (or computed from it) appears as its cause | Keep only variables measured before the outcome, or check arrow directions against time |
| Colliders | Filtering rows on a common effect creates false links | Avoid selecting rows on variables the outcome affects |
| Too many columns | Weak links vanish, run time grows, results get unstable | Start from tens of meaningful variables; add more once the core graph is stable |
| Derived duplicates | Ratios and totals next to their parts confuse every method | Keep either the parts or the ratio |
| Few rows | Only strong links are found | More rows, fewer columns; UCMT Labs warns below 500 rows |
| One method only | Results reflect one set of assumptions | Compare methods; treat disagreements as open questions |
Using UCMT Labs from your pipeline
- In the browser: upload CSV or JSON, run and compare methods, explore paths and what-if scenarios, and explain contributions to a target in the XAI tab.
- Exports: the graph as PNG, SVG or PDF, and the relationships as CSV, to feed your own estimation code.
- REST API on eligible paid plans: upload datasets and run discovery from scripts and notebooks. See the API reference.
Good practice
- Write down the assumptions you are making, and which method makes which.
- Report undirected links as undirected; do not force a direction for a nicer chart.
- Version the dataset and the method with each result, so a graph can be reproduced.
- Treat agreement between methods as evidence, not proof; reserve claims of causation for links that survive a test.