🤖 AI

Causal Software Engineering: A Vision and Roadmap

This paper proposes "Causal Software Engineering" as a new paradigm that moves beyond correlational AI to systematically apply causal models and reasoning for high-stakes decision-making, offering a roadmap for tools, workflows, and benchmarks to answer critical "what-if" questions across the software lifecycle.

Original authors: Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

Published 2026-05-06

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a massive, high-tech spaceship. Every day, you have to make critical decisions: Should I change the engine settings? Should I reroute the ship through a new star system? If I slow down the crew's work pace, will we arrive faster or slower?

Right now, most software engineers (the captains of the digital world) rely on a map that only shows correlations. It's like looking at a weather report that says, "Every time it rains, people carry umbrellas." The map tells you that rain and umbrellas happen together. But it doesn't tell you what would happen if you stopped the rain, or if you forced everyone to carry umbrellas on a sunny day.

This paper, "Causal Software Engineering," proposes a new way of navigating. It suggests we stop just watching what happens together and start understanding cause and effect.

Here is the vision broken down into simple concepts:

1. The Problem: The "Coincidence" Trap

The authors give a story about a software team that fixed a slow computer program. They changed one setting (let's call it the "Retry Button"), and suddenly, the program got faster. The team celebrated, thinking the button was the hero.

But here's the catch: At the exact same time, the computer's automatic system added more workers (servers) and the traffic from users shifted to a different location. The program got faster because of all those things happening at once, not just the button.

Because the team only looked at what happened together (correlation), they thought the button was the magic cure. Later, when they tried to use that same button on a different system without the extra workers, the program crashed. They had mistaken a coincidence for a cause.

2. The Solution: The "What-If" Machine

The paper proposes Causal Software Engineering (CSE). Instead of just asking, "What usually happens with X?", CSE asks, "What will happen if we do X?"

Think of it like a flight simulator for software decisions.

Old Way (Correlation): "Every time we fly through a storm, the plane shakes. So, if we fly through a storm, we should expect shaking."
New Way (Causality): "If we change the engine thrust (the intervention), how will the shaking change, even if the storm is still there? And if we had changed the thrust yesterday, would we have avoided the crash?"

3. The Three New Tools

To make this work, the authors suggest three new tools that engineers would use, like a pilot's checklist:

The "Causal Design Spec" (The Blueprint): Before making a change, engineers write down a simple map. They list:
- What we are changing (the intervention).
- What we want to happen (the goal).
- What else might mess things up (the "confounders," like traffic shifts or other updates).
- Analogy: It's like a chef writing a recipe that explicitly says, "If I add salt, I must also check if the oven temperature changed, or I can't be sure the salt made the soup taste better."
The "Intervention Log" (The Black Box): Every time a change is made, the system records not just what changed, but what else was happening at that exact moment.
- Analogy: Instead of just saying "The engine was fixed," the log says, "The engine was fixed, but at the same time, the fuel pressure dropped and the wind speed increased." This helps separate the real cause from the noise.
The "Living Model" (The Crystal Ball): This is a smart system that uses the blueprints and logs to predict the future. It doesn't just guess; it calculates the "cause" while ignoring the "noise."
- Analogy: It's like a GPS that doesn't just show you where traffic is, but tells you, "If you take this detour, you will save 10 minutes, even if the main road is currently clear."

4. The Roadmap: A Four-Step Climb

The authors don't expect this to happen overnight. They propose a roadmap with four stages, like climbing a mountain:

Level 1: Seeing Clearly (Causal Observability): We need to build better sensors that don't just record data, but understand the structure of how things connect. We need to know which wires are actually connected to the engine, not just which ones are vibrating.
Level 2: Safe Experimenting (Intervenability-by-Design): We need to make changes in small, safe steps (like testing a new engine on just one wing of the plane) so we can be sure what caused the result.
Level 3: Time Travel (Counterfactual Assurance): We need tools that can answer, "If we had done things differently yesterday, would the crash have been avoided?" This helps us learn from mistakes without having to crash the plane again.
Level 4: The Trustworthy Co-Pilot (Causal Copilots): Finally, we get AI assistants that don't just guess. They are "governed" by the rules of cause and effect. They won't tell you to press a button unless they are sure it will actually fix the problem, and they will admit when they don't have enough data to be sure.

5. How Do We Know It Works?

The paper suggests we need to test these new tools with specific "exams":

The "Did it work?" Test: Give the computer a known change and see if it correctly identifies the result.
The "What If?" Test: Give the computer a past disaster and ask, "Would this have been avoided if we did X?" See if its answer matches the real story.
The "Stress Test": Try to trick the system with fake data to see if it admits, "I can't be sure," rather than making a confident but wrong guess.

The Bottom Line

The paper argues that software engineering is moving from guessing based on patterns to deciding based on causes. By treating every software update as a deliberate experiment and recording the "why" behind every result, we can build systems that are safer, more reliable, and easier to fix when things go wrong. It's about moving from "It usually rains when the sky is gray" to "If we turn on the sprinklers, the grass will get wet, even if the sky is gray."

Technical Summary: Causal Software Engineering: A Vision and Roadmap

Problem Statement

Modern software engineering (SE) relies heavily on AI-driven tools (anomaly detection, AIOps, LLM-based agents) to manage high-stakes decisions under uncertainty. However, current approaches predominantly rely on correlational models that identify patterns and co-occurrences in historical data (e.g., "when metric $Y$ is high, event $E$ often appears"). These models struggle to answer interventional questions ("What happens if we change a timeout?") or counterfactual questions ("Would an outage have been avoided under a different release plan?").

The core problem is that correlational signals often lead to spurious conclusions when hidden confounders (e.g., auto-scaling events, traffic shifts) co-vary with the intervention. Consequently, engineers may misidentify the causal drivers of system behavior, leading to ineffective or harmful remediation strategies. The paper argues that SE needs to move from "post hoc correlation hunting" to intervention-aware decision-making grounded in explicit causal assumptions.

Methodology and Proposed Paradigm

The authors propose Causal Software Engineering (CSE) as a new paradigm that integrates causal models and reasoning into standard SE workflows. CSE does not replace existing practices but augments them with three core components:

Explicit Assumptions: Making causal structures (e.g., forbidden or required links between variables) and confounders explicit and reviewable.
Uncertainty-Aware Effect Estimates: Providing causal effect estimates with quantified uncertainty bounds rather than point predictions.
Counterfactual Diagnosis: Enabling reasoning about what would have happened under different conditions.

The CSE Workflow

The methodology introduces a "causal-first" workflow spanning the software lifecycle, supported by three lightweight artifacts:

Causal Design Specs: Versioned documents attached to requirements and Architecture Decision Records (ADRs) that define key variables, outcomes, candidate confounders, and admissible interventions.
Intervention Logs: Structured records of changes (deployments, feature toggles) that capture the intended intervention ( $X$ ), concurrent confounders ( $Z$ ), and observed outcomes, linking CI/CD actions to operational reality.
Living Causal Models: Runtime models that instantiate the design specs with live telemetry and experimental data to answer "what-if" queries and perform counterfactual diagnosis.

The framework utilizes the do-operator ($do(X=x)$) to distinguish between observing an event and intervening upon it, allowing for the estimation of confounder-free causal effects $P(Y|do(X=x))$.

Key Contributions

The paper outlines a structured vision and roadmap for adopting CSE, organized into four co-evolving routes and a staged maturity model:

1. Four Routes to Causal Readiness

The authors define progress through four routes, each moving from current "Achievements" to "Challenges" and finally to "Dreams":

Route 1: Causal Observability (CRL-1): Moving from retrospective root-cause analysis to causal observability. Challenges include building confounder-aware models from monitoring data and ensuring causal graphs remain stable under system evolution.
Route 2: Intervenability-by-Design (CRL-2): Transforming existing delivery mechanisms (CI/CD, feature flags, canaries) into causal instrumentation. Challenges involve designing safe experiments (canary/A-B tests) that ensure identifiability and propagating uncertainty into go/no-go decisions.
Route 3: Counterfactual Assurance (CRL-3): Scaling counterfactual reasoning from local debugging to system-wide assurance. Challenges include performing counterfactual Root Cause Analysis (RCA) at scale and standardizing refutation checks (e.g., placebo tests).
Route 4: Governance & Alignment (CRL-4/5): Integrating causal reasoning into safety cases and compliance. Challenges include creating auditable causal claims for regulators and developing "causal copilots" (LLM agents constrained by causal consistency).

2. Causal Readiness Levels (CRLs)

The paper proposes a maturity model (CRL-0 to CRL-5) to measure organizational and tooling progress, ranging from correlation-based systems (CRL-0) to fully certified causal copilots and causal certification (CRL-5).

3. Evaluation and Benchmark Agenda

To measure progress, the authors propose three families of benchmarks:

Intervention-effect benchmarks: Datasets with known changes and ground-truth impacts to test effect estimation and uncertainty calibration.
Counterfactual incident benchmarks: Datasets of incidents with versioned traces to evaluate counterfactual RCA capabilities.
Causal testing benchmarks: Scenarios (e.g., simulators, fault injection) to evaluate whether test generation can identify causal factors rather than just correlations.

The paper emphasizes that results must report effect estimates with uncertainty, sensitivity analyses, and failure modes when assumptions break.

Results and Claims

As a vision and roadmap paper, the authors do not present empirical experimental results or a specific implemented tool. Instead, the "results" are the conceptual framework and the roadmap itself. The paper claims:

Feasibility: CSE is achievable by augmenting existing SE artifacts (specs, logs, models) rather than requiring a complete overhaul of the engineering stack.
Necessity: Current AI-driven tools are insufficient for high-stakes decisions because they lack causal reasoning; CSE provides the necessary structure to answer "what if" and "what would have happened" questions.
Actionability: The proposed roadmap (Routes 1–4) provides a concrete path for researchers and practitioners to transition from correlation-based to causality-based engineering.

Significance

The paper positions CSE as a critical evolution for software engineering in an era of complex, adaptive systems. Its significance lies in:

Shifting the Paradigm: Moving the field from pattern recognition to causal reasoning, addressing the fundamental limitation of correlational AI in dynamic environments.
Operationalizing Causality: Providing a practical, artifact-based approach (specs, logs, living models) that fits into existing pipelines, making causal reasoning accessible to practicing engineers.
Enabling Trust: Offering a path toward "evidence-backed assurance" where decisions regarding safety, fairness, and reliability are grounded in auditable causal claims rather than opaque correlations.
Catalyzing Community Effort: Calling for shared datasets, common evaluation practices, and SE-specific causal tooling to turn causal reasoning into a routine engineering practice.

The authors conclude that CSE will enable the next generation of trustworthy assistants, counterfactual testing, and evidence-backed assurance, ultimately transforming how software systems are designed, operated, and governed.