Optimization

Optimization is a search question put to the Digital Twin: 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 optimization explores a space. You name the objective and the levers the optimizer may pull; it returns the best combination it can find.

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

The New Simulation screen. Each type opens its own setup form.

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

The objective. The metric the optimizer will push in one direction — Maximize TotalCharges, Minimize Churn, Maximize NPS. The direction matters: maximize and minimize are different searches.

The decision variables. The levers the optimizer 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 minimizes the customer churn rate with three levers as decision variables: Contract, OnlineSecurity, and 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.

Natural Language. Describe the metric in plain English, say the share of customers who churn, and Generate SQL writes the query.

SQL. Test SQL confirms the baseline before the run: here, the current churn rate is 0.241.

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

The completed configuration. The summary mirrors the run back in plain English: Minimize Customer churn rate by adjusting Contract, OnlineSecurity, and TechSupport, with both constraint sections left empty. Validate checks the setup; Run Simulation launches the search.

---

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 optimizer found, whether constraints were satisfied, and how long the search took.

The AI summary states the recommendation in one sentence.

The top of a completed run. The AI summary states the recommendation: a three-lever change cutting churn 87.1% from the 0.24 baseline, with all constraints satisfied, above the three headline stats. It also notes the cost side plainly: the solution requires 3 interventions.

Below that, three sections give the full picture.

• Recommended Solution. A card describing the winning combination in plain English, with the optimized 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 optimized 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.

The rest of the result: the three recommended changes, the baseline-vs-optimized chart (0.24 → 0.03, −87.14%), and the All Solutions table with the baseline as row 0. Note the OnlineSecurity recommendation: the optimizer searches every level present in the data, including a missing/blank level, so inspect recommended values before acting on them. 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.

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

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