CausalNex: a Bayesian network toolkit that reached end of life

What CausalNex was built to do, and who it was for

The README states the problem in one line: a data scientist generally has to use at least 3-4 different open-source libraries before arriving at the final step of finding the right intervention. CausalNex packages those steps into a single library so the workflow runs from a raw table to an estimated effect of an intervention without switching tools. The intended user is a data scientist who wants to reason about what happens when a variable is changed, not merely which variables move together. The README frames the contrast directly, arguing that Bayesian networks are more intuitive to describe causality than machine learning methods built on pattern recognition and correlation analysis. That is a design stance, not a claim the library can prove on your data. The second half of the pitch is about domain expertise. The stated aim is to let people encode or augment domain knowledge in the graph model, on the reasoning that causal relationships come out more accurate when a human who knows the system can edit the edges. So the target user is someone who has both a dataset and access to people who understand the process that generated it. If you have only the dataset, you lose a stated part of the value.

The four stages of the CausalNex workflow

The feature list maps onto a sequence. First, structure learning: the library uses what the README calls state-of-the-art structure learning methods to understand conditional dependencies between variables. That produces a graph rather than a fitted predictor. Second, augmentation: domain knowledge can be added to or removed from that graph, which is the point where a subject-matter expert edits the learned structure instead of accepting it. Third, fitting: the library fits probability distributions of the Bayesian network, so the graph becomes a model that can be queried. Fourth, intervention: do-calculus is used to analyse the impact of interventions, which is the counterfactual step the whole pipeline exists to reach. Around those stages sit two supporting pieces: standard statistical checks for model quality, and visualisation, which the README describes as a way to simplify how causality is understood in Bayesian networks. The architecture is therefore a chain of transformations over one graph object, with the graph as the shared artefact between stages. That is the practical difference from a scikit-learn style pipeline, where the fitted estimator is the artefact and the relationships between inputs are not represented explicitly. Here the edges are the model, and the distributions are attached to them.

Installing CausalNex and the Python versions it accepts

Installation is a single command, `pip install causalnex`. The README also documents a full install of dependencies with `pip install "causalnex[all]"`, which matters because structure learning and inference pull in numerical dependencies that the base install may not include. The Python version badge in the README lists 3.8, 3.9 and 3.10. There is no badge for 3.11 or later, and given the end-of-life notice described below, that range should be treated as a hard boundary rather than a floor. If your environment runs a newer interpreter, testing it is your problem, not the maintainers'. The README points to an installation guide covering Python virtual environments, and to a first tutorial that walks the end-to-end flow. It also notes that the notebooks and markdown files used to build the docs live in `docs/source`, which is useful when the rendered documentation is ambiguous: the source notebooks show the actual call sequence. Versioning follows SemVer, and the README's own guidance for upgrading is to read `RELEASE.md` for notable breaking changes before moving between versions. That file is the only upgrade path the project offers.

The end-of-life notice is the first thing to read

The README opens with an important notice, placed above the badges, stating that CausalNex is no longer actively maintained and reached end of life on 24th June 2026. McKinsey describes the repository as a historical archive and states that the codebase will receive no future updates, bug fixes, or security and vulnerability patches. Outstanding issues and pull requests will no longer be monitored or reviewed. The notice also states that the software is provided on an AS IS basis under the applicable open-source licence, without warranties of any kind, and that continued use, copying, modification or distribution is at the user's own risk. This is not a soft deprecation with a migration guide. There is no successor project named in the material. The last releases listed are 0.12.1 from June 2023, 0.12.0 from April 2023 and 0.11.2 from April 2023, so the gap between the final release and the end-of-life announcement is roughly three years. Anyone evaluating CausalNex today is evaluating a frozen artefact. That does not make it useless, but it changes what you are buying: a complete, documented, unpatched snapshot of a causal inference toolkit.

Licence status: an Apache 2.0 badge and a NOASSERTION identifier

The README displays an Apache 2.0 licence badge linking to opensource.org, and the licence section directs readers to `LICENSE.md` for more detail. The repository metadata, however, reports the licence as NOASSERTION, meaning the automated classifier could not confirm a standard licence from the files it examined. Those two signals disagree, and the material here does not explain why. The practical consequence is that you should open `LICENSE.md` and read it rather than trusting either the badge or the metadata field. The end-of-life notice adds a second layer: it says continued use, copying, modification or distribution is done at the user's own risk and that McKinsey disclaims liability arising from such use. Apache 2.0 normally includes an explicit patent grant and a liability disclaimer, so the notice reads as a restatement of the existing terms rather than a new restriction, but that is an inference from the badge, not something the material confirms. This is not legal advice. If CausalNex is going into anything commercial or regulated, have counsel read `LICENSE.md` and the notice together before you commit.

Where CausalNex stops being the right tool

The library assumes a directed acyclic graph over discrete or discretisable variables, because that is what Bayesian network structure learning and do-calculus operate on. The README does not describe a continuous-variable path, a time-series path, or a way to handle feedback loops, and nothing in the material suggests one exists. If your problem involves variables that influence each other in cycles, or effects that unfold over time, the graph representation is the wrong shape and no amount of tuning fixes it. The second limitation is the one the README itself concedes: the value of augmenting the graph with domain knowledge depends on having domain experts available and willing to sit with the model. Teams that want a fully automated answer from a CSV will find the augmentation stage either skipped or performed badly, and a structure learned purely from data is exactly the correlation-driven artefact the library was built to move away from. The third is the maintenance situation. With no security patches and no issue triage, a dependency conflict or a numerical edge case in your data is yours to diagnose. There is no upstream to escalate to. The fourth is version drift: the supported interpreters are 3.8 to 3.10, and those versions will keep aging out of managed environments while the package stays where it is.

Alternatives and the difference in approach

The obvious comparison is DoWhy, which also targets causal effect estimation but starts from a different premise. DoWhy asks you to state a causal graph and an identification strategy, then tests the estimate against refutation checks; the graph is an input you supply from domain reasoning. CausalNex learns the graph from data first and then lets you edit it, which puts structure discovery inside the library rather than in your head. If you already know the causal structure and want to defend an estimate, DoWhy's framing is closer to the task. If you do not know the structure and want a tool to propose one that experts can correct, CausalNex's framing is closer. A second comparison is to probabilistic programming libraries such as PyMC, where you write the generative model by hand and get full control over the likelihood and priors. CausalNex trades that control for a smaller number of decisions: it fits distributions to the graph for you. A third option, and the one worth weighing seriously given the end-of-life notice, is to skip the library and implement the approach. The README points at `docs/source` for the notebooks that build the documentation, and those notebooks are a readable specification of the workflow. For a one-off analysis, copying the method into your own code removes the dependency on an unmaintained package entirely.

Maintenance cost and the honest adoption call

The maintenance cost of adopting CausalNex is not the cost of upgrading it, because there will be no upgrades. It is the cost of owning it. You are responsible for the Python version constraint, for any dependency that breaks under a future interpreter, and for any bug you hit. Pinning the package version and the interpreter version in your environment file is the minimum discipline, and the README's own upgrade guidance (read `RELEASE.md` before changing versions) applies only to the versions that already exist. The releases listed stop at 0.12.1 in June 2023, so there is no later tag to move to. For a research notebook, a teaching example, or a proof of concept where the analysis has a defined end date, that ownership cost is small and the library's consolidation of four steps into one is a real saving. For anything with a multi-year lifespan, a security review, or an on-call rotation, the absence of patches is a standing risk that no amount of documentation offsets. The material does not include a migration path, a fork with active maintenance, or a stated successor, so the choice is between using the archive as-is and reimplementing the method. Check `LICENSE.md`, check the interpreter range, and read the notebooks in `docs/source` before you decide which of those two you are doing.

Editorial conclusion

Adopt CausalNex only for short-lived analysis where you can pin Python 3.8 to 3.10 and accept that no security or bug fixes are coming; do not build a production pipeline on it, and do not expect the maintainers to review issues or pull requests. Before writing any code, verify three things: that your interpreter falls inside the supported range, that the LICENSE.md file matches the Apache 2.0 badge the README displays, and that you can read the relevant notebook under docs/source, because that directory is where the working examples actually live.

Official sources

1. Issues
2. mckinsey/causalnex on GitHub
3. Project website
4. README
5. Releases