Intervention
The Intervention tool uses a Digital Twin — RootCause's runnable causal model of your business — to answer a counterfactual question: what would happen to a target metric if we changed a variable?
Unlike a prediction, which estimates an outcome given known inputs, an intervention reaches into the causal graph and forces a variable to a new value. Every downstream variable adjusts according to its causal mechanism, and the change in the target metric is reported with a confidence interval.
For the workflow that produces a Digital Twin in the first place, see Step 6: Run Simulations.
Starting a simulation
Open a Digital Twin from the Digital Twin Management page. The right-hand panel shows the Overview by default; click Simulations, then + New Simulation. This opens the type picker — choose Intervention.
The setup form has three sections plus a configuration summary at the foot. Each section answers part of the question being asked: what changes, how do we measure the effect, and across which subgroups?
Target and intervention
Two ideas drive every intervention simulation.
The target. The metric whose movement you care about — reducing churn, increasing average revenue per user, cutting handling time.
The intervention. The lever you want to test against the target — what if every customer got online backup as part of their package, or month-to-month contracts came at a discount, or onboarding emails went out within an hour of signup?
The form takes them in the opposite order: Step 1 sets the intervention, Step 2 sets the metric. Fix the target in mind first — the intervention is only meaningful as a way to move it.
Step 1: What will you change?
In the example, the change being tested is set OnlineBackup to Yes for every customer. The change type controls how the change is applied; Target value (shown) sets a single value uniformly across the population.
For categorical variables, the New value dropdown lists every level the variable can take. For numeric variables, you enter a value directly.
Once a variable is picked, a Downstream causal paths from "X" row appears below. Expand it to see which downstream variables the change will propagate to according to the causal graph — useful for confirming what is in scope before you run.
+ Add condition restricts the intervention to records matching a filter. Without conditions, the change applies to the entire population. + Add intervention layers a second change on top of the first to test a combined scenario.
Step 2: Define success metrics
A metric is the number whose movement you want to read. At least one is required.
Each metric has a name, a unit (# Count, $, %, …), and a direction — Higher is better or Lower is better. The direction drives the colour of the up and down arrows on the results page.
The query that computes the metric can be built three ways:
Natural Language — describe the metric in plain English; the system writes the SQL.
Builder — pick an aggregation and a column, optionally add filters. The simplest path for standard metrics.
SQL — write the query by hand.
The example below builds the average of MonthlyCharges across the simulated population.
Tick Return 0 instead of NULL when no rows match if the metric should fail gracefully when filters exclude every record. Without it, an empty result returns NULL and the metric is undefined for that run.
Step 3: Segment definitions
Segments split the result into subgroups so you can compare the effect across them. Each segment is a named filter — for example, Customers with a Partner (Partner equals Yes) and Customers without a Partner (Partner equals No).
If no segments are defined, the simulation reports a single overall effect. Segments are optional but the effect of an intervention is rarely uniform across a population, so at least one segmentation is usually worth running.
Configuration Summary
The card at the foot of the form mirrors back the experiment in plain English, with the version of the twin the simulation will run against.
Reading the result
Clicking Run Simulation opens the result page. A progress bar reports the current stage while the simulation runs.
A completed run carries a green Completed pill, a duration, and Export PDF and Edit Config controls. The page leads with an AI summary that states the headline effect in plain English.
Below that, four sections give the full picture.
Intervention Impact. A paired bar chart and a metric table reporting Baseline vs After, the absolute change, the percentage change, and whether the difference is statistically significant.
Uncertainty. The central readout: average effect with its 95% confidence band, the confidence level used, and the significance verdict. A very small p-value indicates the effect is unlikely to be due to chance.
Why did the metric move? A causal-path explanation. For each downstream variable that contributed, the page shows the path through the graph and how the distribution shifted. In the example, setting OnlineBackup to Yes propagates through StreamingTV — its
No internet serviceshare drops by 0.23 — and on to MonthlyCharges. This is the answer to why that a DAG can give and an LLM cannot.Segment Comparison. Bar chart and table reporting before, after, change, and percentage change for each segment. Useful for spotting heterogeneous effects — segments often move in the same direction with different magnitudes.
Past simulations
Past runs appear in the Simulations panel inside the twin, and View All opens the full history. The workflow is the same as for any other simulation type — see Prediction › Past simulations.
Other Simulation Types
Prediction — predict an outcome for a specific input.
Optimization — find the input combination that maximises or minimises a target.
Best Action — find the minimum change needed to reach a target outcome.
Explanation — understand the drivers and impacts behind an outcome.
See Step 6: Run Simulations — general overview.
Last updated