Optimization
The Optimization tool uses a Digital Twin — RootCause's runnable causal model of your business — to answer a search question: across many combinations of input variables, which combination moves a target metric the most in the desired direction?
Unlike a prediction, which estimates the outcome of one specified input, or an intervention, which forces one or two variables and reports the downstream effect, an optimisation explores a space. You name the objective and the levers the optimiser may pull; it returns the best combination it can find.
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 Optimization.
The setup form has four numbered sections plus a configuration summary at the foot. Only the first two — the objective and at least one decision variable — are required; constraints are optional and can be skipped on a first pass.
Objective and decision variables
Two ideas drive every optimisation.
The objective. The metric the optimiser will push in one direction — Maximize TotalCharges, Minimize Churn, Maximize NPS. The direction matters: maximise and minimise are different searches.
The decision variables. The levers the optimiser may pull on the way to the objective. A handful of well-chosen levers produces a recommendation a business can act on; selecting every variable invites combinations no operator would ever apply.
The example below maximises average TotalCharges by adjusting seven service-related variables (InternetService, OnlineBackup, OnlineSecurity, PhoneService, StreamingMovies, StreamingTV, TechSupport).
Step 1: Optimization objectives
An objective has a name, a direction (Maximize or Minimize), an importance weight, and a SQL expression for the metric.
The metric can be specified three ways, matching the metric builder used elsewhere in the product: Natural Language describes it in plain English and lets the system generate the SQL; Builder offers aggregation and column pickers for standard metrics; SQL writes the query by hand.
The result of Test SQL is the baseline against which all improvements are measured. + Add objective stacks a second objective, in which case the importance weights determine the trade-off.
Step 2: Decision variables
A scrollable list of every variable in the twin, with a checkbox against each one. Tick the levers the optimiser is allowed to change; selections appear as chips below the list so the chosen set is visible at a glance.
Anything left unchecked is held at its current distribution. That is useful for pinning demographics or contract terms while letting the optimiser play with product offerings.
Step 3 (optional): Constraints
Two kinds of constraint narrow the search space.
Variable constraints bound an individual decision variable — PhoneService can only be set to Yes, or MonthlyCharges must stay between 30 and 100. Auto Generate Constraints asks the model to suggest sensible bounds based on the variables you picked; the suggestions can be edited manually before the run.
Metric constraints set rules the optimiser must respect even at the cost of a weaker objective — average Churn must stay below 0.1, Electronic check share of PaymentMethod must not rise. They are how you encode trade-offs the objective alone cannot express.
Both sections are optional. The example below uses neither — the optimiser is free to explore the unconstrained search space.
Configuration Summary
The card at the foot of the form mirrors back the run in plain English, with the version of the twin the simulation will run against.
Reading the result
A completed run carries a green Completed pill, a duration, and Export PDF and Edit Config controls. The page leads with three headline numbers: how many solutions the optimiser found, whether constraints were satisfied, and how long the search took.
The AI summary states the recommendation in one sentence.
Below that, three sections give the full picture.
Recommended Solution. A card describing the winning combination in plain English, with the optimised metric, the baseline, and the percentage uplift. The Recommended Changes row lists each variable that has to move and the value it has to move to. A Global strategy badge confirms the change applies to the entire population.
Baseline vs Optimized. A paired bar chart for each objective, with baseline and optimised values side by side. The percentage label on the right is the absolute uplift.
All Solutions. A table of every candidate the search produced, ranked by objective improvement. The baseline appears as row 0 for reference; ticks in the Status column flag solutions that satisfied every constraint. Useful for comparing runner-up strategies — a slightly worse-scoring solution sometimes involves fewer or cheaper changes.
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.
Intervention — change a single variable and observe propagation.
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