For the complete documentation index, see llms.txt. This page is also available as Markdown.

Intervention

Intervention asks the Digital Twin 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 5: Build Digital Twin.


Starting a simulation

Open a Digital Twin from the Digital Twins list, open the Simulate tab, then click 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?

The empty Intervention setup form, with Section 1 What will you change showing an unset variable picker and Section 2 Define success metrics starting below
The empty setup form. Sections build the experiment top to bottom.

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 move every month-to-month customer onto a two-year contractContract set to Two year. The change type controls how the change is applied; Target value (shown) sets a single value uniformly across the population.

Section 1 of the Intervention form with Contract selected, Target value as the change type, and Two year as the new value
Choosing the variable, the change type, and the new value.

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 color 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 three tabs stay in sync up to a point: once the SQL has been edited by hand, the Builder locks and offers Reset Builder to start fresh.

The Define success metrics section with metric name churn_rate_after_intervention, unit ratio, direction Lower is better, and the SQL tab open on a CASE-based churn query, with Test SQL reporting Test passed Result: 0.241; a second metric, overall_churn_rate, starts below
A metric on the SQL tab. The query must return a single value column; click Test SQL to run it against the underlying data; here it passes with a baseline churn rate of 0.241. A second metric, overall_churn_rate, is stacked below.

In the Builder, 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. + Add metric stacks further metrics; every one is reported separately in the result.


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.

The foot of the Intervention form: an empty Segment definitions section, the version picker set to 1.0.0, and the Configuration Summary reading What if we change Contract to Two year, only when Contract equals Month-to-month, to measure impact on churn_rate_after_intervention and overall_churn_rate, both with Aim: Lower, above the Validate and Run Simulation buttons
A completed configuration. The summary mirrors the experiment back in plain English: the change (Contract to Two year, applied only when Contract equals Month-to-month) and the two churn-rate metrics it will be judged on, both aiming lower. Validate checks the setup; Run Simulation launches it.

Reading the result

Clicking Run Simulation opens the result page. A progress bar reports the current stage while the simulation runs.

The Intervention result page mid-run, with the Configuration Summary at the top and a Simulation Running section showing an Initialising progress bar
A run in progress. Static interventions usually complete in seconds.

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.

A completed Intervention run: the AI Summary reports overall_churn_rate falling by 0.1894, from 0.2427 to 0.0533, when month-to-month customers move to a two-year contract, above the Intervention Impact chart and metric table showing the −78.05% change flagged statistically significant
The top of a completed run. The AI summary states the headline effect: churn falls from 0.24 to 0.05, a −78.05% change flagged statistically significant, above the Intervention Impact chart and per-metric table.

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 path it took through the graph and how its distribution shifted.

  • 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.

The Segment Comparison section of the Intervention result: a per-segment bar chart and table of churn before and after the change across six segments, with the fiber-optic segment falling from 0.40 to 0.11 and another from 0.27 to 0.04, while a segment that already had tech support barely moves
Segment Comparison in the result. The fiber-optic internet segment drops from 0.40 to 0.11 while segments that barely churned barely move: the effect is real but concentrated where the change bites. Every section exports as PDF.

Past simulations

Past runs appear in the Simulate tab's run list inside the twin, and View all simulations on the twin's Home 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 maximizes or minimizes a target.

  • Best Action — find the minimum change needed to reach a target outcome.

  • Explanation — understand the drivers and impacts behind an outcome.

  • Root Cause Analysis — diagnose the cause of a specific abnormal value.

  • Anomaly Scan & Diagnosis — scan every variable for anomalies and diagnose each one.

See Step 6: Run Simulations — general overview.

Last updated