Causal Software Engineering

• Causal Software Engineering is an emerging paradigm that integrates causal models, do-calculus, and counterfactual reasoning into software processes for improved diagnosis and testing.
• It employs structural causal models, estimation techniques, and data-driven inference to assess the effects of software changes, configurations, and interventions.
• The approach enhances traditional practices through human-machine co-design, better fault localization, and integration into CI/CD pipelines for robust software quality.

Causal Software Engineering (CSE) is an emerging paradigm that brings structural causal models, do-calculus, uncertainty-quantified effect estimation, and counterfactual reasoning into software engineering practice, so that software changes, configuration choices, test scenarios, and operational interventions are analyzed not only through associational queries such as $P(Y \mid X=x)$ but through interventional and counterfactual queries such as $P(Y \mid do(X=x))$ and $Y_{X=x'}$. In one formulation, CSE is a “future paradigm in which causal models and causal reasoning systematically inform activities across the software lifecycle”; in another, it is a “human-machine co-design perspective in which machines imitate and augment human reasoning to anticipate scenarios and explain events, amplified by computational power” (Pietrantuono et al., 4 May 2026, Pietrantuono et al., 26 Jun 2026).

1. Emergence of the field and its research profile

The development of CSE has been documented through several reviews that converge on a common diagnosis: software engineering has abundant observational data, but many of its salient questions are interventional or counterfactual. A review of applications of statistical causal inference in software engineering reported that the area is relatively recent and that the research community remains relatively fragmented (Siebert, 2022). A broader systematic literature review of causality and causal inference in software engineering found 45 relevant papers and reported that the majority of causal reasoning is related to testing through root cause localization; it also observed that most causal reasoning is done informally through an exploratory process of forming a Causality Graph, rather than through strict statistical analysis or explicit interventions (Chadbourne et al., 2023).

Within Software Quality Assurance (SQA), the scale of activity is now larger. A systematic review of 86 articles found that fault localization is the activity where causal reasoning is more exploited, especially in the web services and microservices domain, while testing is rapidly gaining popularity. The same review reported that both causal inference and causal discovery are exploited, that Pearl’s graphical formulation of causality is preferred, likely due to its intuitiveness, and that tools to favor application are appearing at a fast pace, most of them after 2021 (Giamattei et al., 2024). This suggests that CSE is best understood not as a single method, but as a convergence of causal inference, causal discovery, causal testing, counterfactual diagnosis, and causal representations of software artifacts.

2. Formal foundations and causal representations

At the formal core of CSE lies the structural causal model (SCM). In the roadmap formulation, an SCM is a triple $M=(U,V,F)$, where $U$ is a set of latent variables, $V=\{V_1,\dots,V_n\}$ is a set of observed variables, and $F=\{f_1,\dots,f_n\}$ assigns each endogenous variable a structural equation of the form

$V_i := f_i(PA_i, U_i).$

Interventions are represented through the do-operator: setting $X:=x$ replaces the structural assignment for $X$, and the resulting target query is $P(Y \mid do(X=x))$0. When a set $P(Y \mid do(X=x))$1 blocks all back-door paths from $P(Y \mid do(X=x))$2 to $P(Y \mid do(X=x))$3, identification proceeds through the adjustment formula

$P(Y \mid do(X=x))$4

These formulations underpin the use of causal DAGs, SCMs, and Causal Bayesian Networks across the CSE literature (Pietrantuono et al., 4 May 2026, Pietrantuono et al., 26 Jun 2026).

Several works make the relation between software artifacts and causal models explicit. One line treats flow-based programming dataflow graphs as complete causal graphs: each data stream becomes a random variable, each processing node implements a structural function, explicit dataflow ensures the absence of hidden common parents, and atomic interventions correspond to replacing a component implementation with a constant-emitting dummy (Paleyes et al., 2023). Another line argues that diagrammatic models based on thinging machines provide a more complete depiction of causality than ordinary causal graphs and can therefore serve as a foundation for causal graphs in requirements-oriented settings (Al-Fedaghi, 2023).

CSE also adopts the potential-outcomes vocabulary when appropriate. In the requirements-engineering tutorial, the principal quantities are the Average Treatment Effect,

$P(Y \mid do(X=x))$5

the Average Treatment Effect on the Treated,

$P(Y \mid do(X=x))$6

and the Controlled Direct Effect,

$P(Y \mid do(X=x))$7

The same tutorial states the standard identification assumptions: ignorability, positivity, consistency, and no interference (Frattini et al., 5 Nov 2025). In configurable software systems, a different but related formalism appears: feature causality is defined at the level of configurations and partial configurations, with sufficiency and counterfactuality/minimality conditions yielding feature causes, and responsibility and blame extending actual causality into a feature-oriented setting (Dubslaff et al., 2022).

3. Workflows, identification strategies, and estimation practice

A recurring methodological backbone is Pearl’s three-step paradigm of modeling, identification, and estimation. One review of statistical causal inference in software engineering organizes the literature precisely around this triplet and shows that most studies formulate a causal DAG, derive an estimand through back-door or related criteria, and then estimate causal effects through matching, weighting, regression, or related methods (Siebert, 2022). In requirements engineering, this basic structure is elaborated into a six-stage process: causal modeling, identification, data collection and cleaning, estimation, sensitivity analysis, and reporting (Frattini et al., 5 Nov 2025).

CSE-specific workflows adapt these general stages to software activities. The Causal Testing Framework defines a modelling scenario $P(Y \mid do(X=x))$8, a causal test case $P(Y \mid do(X=x))$9, and a causal test oracle, then proceeds through specification, test-case definition, data collection, and causal testing through identification, estimation, and oracle checking (Clark et al., 2022). A later roadmap proposes a “causal-first workflow” across development and operations that introduces three lightweight artifacts: a Causal Design Spec, an Intervention Log, and a Living Causal Model, which together support what-if analysis, counterfactual diagnosis, and refutation checks (Pietrantuono et al., 4 May 2026).

The estimator palette used in CSE is broad. In the SQA review, common causal-inference methods include regression adjustment, propensity-score based methods, covariate balancing, instrumental variables, simulations via do-sampling, and ML-based estimators; alternative frameworks include Difference-in-Differences, Fuzzy Cognitive Maps, and Causal Trees (Giamattei et al., 2024). Automotive software evaluation illustrates how these estimators are specialized for deployment constraints: the BOAT framework introduces Bayesian propensity score matching for producing balanced control and treatment groups when the entire user base is unavailable, Bayesian regression discontinuity design for identifying covariate dependent treatment assignments and the local treatment effect, and Bayesian difference-in-differences for treatment effects over time while implicitly controlling unobserved confounding factors (Liu et al., 2022). This diversity indicates that CSE is a workflow family rather than a single estimator class.

4. Application domains and representative studies

Automotive software engineering has become a prominent CSE domain because randomized field experiments may be undesired, impossible, or unethical. The BOAT framework was developed with an industry collaborator and demonstrated on a large fleet of vehicles to support online software evaluation without a fully randomized experiment (Liu et al., 2022). A related proof-of-concept on Bayesian propensity score matching used a larger control fleet of $Y_{X=x'}$0 vehicles, a small treatment fleet of $Y_{X=x'}$1, and 14 observed covariates to generate balanced groups from observational online evaluation and estimate causal treatment effects from software changes, even with limited samples in the treatment group (Liu et al., 2021).

Software testing is another central domain. The Causal Testing Framework introduces causal testing for scientific modelling software and shows that metamorphic testing can be recast as causal effect estimation from existing data. Across case studies on Poisson Line Tessellation, the Luo–Rudy 1991 cardiac action potential model, and Covasim, the framework reused confounded observational data and, in the retrospective Covasim setting, achieved $Y_{X=x'}$2 and Kendall $Y_{X=x'}$3 against a gold-standard statistical metamorphic testing baseline (Clark et al., 2022). An evaluative case study on CARLA extends causal testing with effect modification and instrumental variable methods to handle hidden and interacting variables; it tested three system-level requirements and reported that all four agents exhibited a statistically significant slowdown on CARLA v0.9.11, with IV-based estimates yielding the same PASS/FAIL verdicts as classical adjustment (Foster et al., 23 Apr 2025).

Configurable software systems motivate a distinct notion of causality. “Feature causality” operates at the level of configurations and identifies features and feature interactions that are the reason for functional or non-functional properties. The framework extends responsibility and blame to features, connects feature causes to prime implicants, and provides algorithms to compute feature causes and causal explications. Its evaluation spans community benchmarks and real-world systems, including Minepump, Elevator, CFDP, Apache, SQLite, Linux, WGet, Biosensor Network, aircraft Velocity Control Loop, and compressors such as Curl, h264, x264, Lrzip, and ZipMe (Dubslaff et al., 2022).

Empirical software analytics provides another set of examples where causal and associational analyses diverge materially. A study of Google Code Jam data asked for the causal effect of programming language choice on contest rank and showed that conditioning on code size as an associational covariate opened a collider path, reversing the substantive conclusion: a causal model adjusting for nickname and challenge yielded “C++ best, Python worst,” whereas the associational model suggested “Python best, Java worst” (Furia et al., 2023). In deep learning for software engineering, the DoCode framework introduces a four-step pipeline of modeling causal problems with SCMs, identifying the causal estimand, estimating effects with metrics such as ATE, and refuting effect estimates. Its case studies report that some apparently strong associations in neural code model behavior disappear after adjustment for software confounders, while other interventions—such as masking real AST node types rather than random tokens—retain significant causal effects (Palacio, 21 May 2025).

5. Tooling, computational infrastructure, and maturity

As CSE scales from one-off studies to engineering systems, software architecture becomes a first-class concern. The computational causal inference perspective defines an interdisciplinary field across causal inference, algorithms design, and numerical computing, with the explicit goal of building software that can estimate a wide variety of causal effects on massive datasets in a performant, general, and robust way (Wong, 2020). The architecture it proposes comprises a Data Ingestion layer, a Feature-Matrix Builder, a Causal-Model Registry, an Estimation Engine, and a Counterfactual Query API. It also emphasizes sparse linear algebra, sufficient-statistics compression, vectorized multi-KPI estimation, and reproducibility artifacts such as model versioning, manifests, and provenance capture. In the Netflix case study summarized there, 1000 CATEs with $Y_{X=x'}$4 and $Y_{X=x'}$5 complete in 10 seconds on one machine, while time-dynamic clustered covariances with $Y_{X=x'}$6 and $Y_{X=x'}$7 complete in 1 hour (Wong, 2020).

The current CSE tool ecosystem reflects both rapid growth and uneven maturity. The SQA review lists causal-discovery libraries such as causal-learn, py-cdt, lingam, and Dag-GNN, and causal-inference libraries such as DoWhy, EconML, DeepIV, MatchIt, JFCM, pyAgrum, Bayes-Net toolbox, and IBM SPSS Amos; roughly 19 of 86 papers explicitly report using third-party causal libraries, and adoption has grown rapidly after 2021 (Giamattei et al., 2024). For software-native causal analysis, DoWhy-GCM is described as capable of ingesting a flow-based-programming graph as a causal DAG and performing independence tests, do-calculus queries, truncated factorizations, and d-separation membership tests (Paleyes et al., 2023).

Despite this tooling growth, field maturity remains limited. The SQA review reports that 85 of 86 papers include experiments, but only 11 report deployment or case studies with industry partners, and most solutions remain in the prototype stage as validation research rather than evaluation research (Giamattei et al., 2024). A plausible implication is that the central technical challenge is no longer only whether causal methods can be formulated for software problems, but how to integrate them into CI/CD, observability, experimentation, and decision-support pipelines without losing transparency or tractability.

6. Limitations, controversies, and roadmap

The most persistent limitations in CSE are hidden confounders, graph-learning scalability, incomplete integration of domain knowledge, and limited industrial adoption. The requirements-engineering tutorial emphasizes the standard threats to internal validity—unmeasured confounding, misspecified causal models, and model misspecification—and recommends transparent DAG publication, collection of all variables implied by the DAG, robustness checks across estimation strategies, and formal sensitivity analyses (Frattini et al., 5 Nov 2025). The SQA review likewise identifies latent factors in logs and metrics, high-dimensional graph-learning problems, tension between learned edges and known architecture, and barriers to industrial uptake including integration cost and limited explainability for non-experts (Giamattei et al., 2024).

A sharper controversy concerns the stability of learned causal graphs in software analytics. The “Shaky Structures” study applies PC, FCI, GES, and LiNGAM to 23 datasets across defect prediction, configuration optimization, and process-management decisions and finds that causal structures generated from SE data can be highly variable. Measured by the Jaccard index of shared edges, over half the edges changed under project changes, release changes, 90% subsampling, or small hyperparameter variations; the median mean Jaccard across all datasets, experiments, and generators is approximately $Y_{X=x'}$8, and some specific causal conclusions reverse direction, as in Ant 1.5 where PC yields bug $Y_{X=x'}$9 LOC and Ant 1.7 where PC yields LOC $M=(U,V,F)$0 bug (Hulse et al., 18 May 2025). The resulting recommendation is explicit: learned DAGs in SE should be accompanied by repeated sampling, sensitivity sweeps, consensus graphs, and cross-task or cross-project verification before strong causal claims are reported (Hulse et al., 18 May 2025).

Current roadmap work frames these challenges organizationally as well as technically. One vision introduces Causal Readiness Levels from CRL-0 (“Correlation-only”) through CRL-5 (“Causal Certification”), together with benchmark families for intervention-effect estimation, counterfactual incident analysis, and causal testing, and evaluation metrics including bias, mean squared error, confidence-interval coverage, decision accuracy, and counterfactual accuracy (Pietrantuono et al., 4 May 2026). A related vision paper argues for hybrid human-machine cooperation in which causal models guide reasoning, LLM agents, and design exploration, while future work includes reasoning- and data-driven integration, human-in-the-loop model refinement, industrial benchmarks, and explicit treatment of ethical and trust considerations (Pietrantuono et al., 26 Jun 2026). This indicates that the long-term trajectory of CSE is not merely methodological refinement, but the construction of auditable, uncertainty-aware, counterfactual-capable engineering practice across development and operations.