> For the complete documentation index, see [llms.txt](https://docs.rootcause.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rootcause.ai/more-details/build-digital-twin/build-configuration.md). # Configuration to Build Digital Twin This page is the reference for every control in the **twin builder**. The builder is a four-step wizard — how to build, choose your data, add domain knowledge (or draw the graph), then review and run — and the controls appear once you select a data view (see [Selecting your Data View](/more-details/build-digital-twin/selecting-data-view.md)). Which ones you see depends on the [twin type](/more-details/build-digital-twin/twin-types.md) the data supports. RootCause fills them all in for you; this page explains what each does and when it is worth changing. > **You can change these later.** These are the settings you choose *while creating* a twin. After it is built, the twin's read-only [Config tab](/more-details/digital-twin/configuration.md) documents them, and **Modify model** reopens the builder — each run creates a new version and retrains.
The twin builder's Review & run step with Advanced settings expanded, showing the Training Options toggles — Account for hidden factors and Show the formula — and the Discovery engine choice of CausalACO, SPARC, and SPARC-fast

The Review & run step with Advanced settings expanded: training options and engine choices below the plain-language recap. Temporal and multi-environment twins add controls to the same screen.

*** ## Data and structure ### Data View The dataset the twin learns from. Selecting it triggers everything below. Covered in [Selecting your Data View](/more-details/build-digital-twin/selecting-data-view.md). ### Name A label for the twin, auto-generated from the data view name (for example, *Digital Twin - View of Sales Data*). Edit it or leave it to auto-generate. **Validate** confirms the data view is usable. ### Type Static, Temporal, Multi-Environment Static, or Multi-Environment Temporal. The platform ticks every type the data supports and selects the most specific. See [Types of Digital Twins](/more-details/build-digital-twin/twin-types.md). The remaining controls in this section appear only for the types that need them. ### Time Column *(temporal types)* The field that orders observations in time — here, *Order Date*. Identified automatically from the data view's time field. ### Environment Columns *(multi-environment types)* The categorical columns that split the data into **environments** — the groups the model treats separately while it learns one shared cause-and-effect map across them all. The platform creates **one environment per unique combination** of the selected columns' values. In the sales data example — a table of orders tagged with a **product** and a **city**, recorded over time (just one example; your data will differ) — selecting *Product* and *City* produces 171 environments, while *Product* alone produces 19. **Each environment needs at least 10 rows of overlapping history to be modeled.** This is the cause of the common error: > **"No environment has at least 10 rows."** > > You have selected environment columns that split the data into many tiny partitions, each below the 10-row threshold. Select **fewer or coarser** columns so each environment holds enough history. Fewer environment columns mean fewer, larger environments. Choosing environment columns is also the single biggest lever on model fit — see [Tuning for Fit](/more-details/build-digital-twin/tuning-for-fit.md). ### Parallel pieces *(multi-environment types)* Multi-environment workloads can be split into pieces and trained in parallel across the cluster. The control lives in the review step under **Advanced settings → Speed**: set **Parallel pieces**, or leave it blank ("auto") to use the split the platform recommends — a "\~N recommended" hint shows alongside the field. The recommended value is right for most jobs; raise it only when a large workload needs more parallelism. *** ## Fields The variables fed into causal discovery. Every column from the data view is listed with its data type, and **all are included by default**. Free-text (string) columns are ignored automatically, because the discovery algorithm cannot use them. Exclude a field when it carries no causal meaning — a unique identifier, a metadata column, or a field that duplicates another. Include anything you might want to predict, simulate, or trace a causal path through. *** ## Training Options Each option improves the model but adds training time, which is why they are toggles rather than always on. For most work, leave **Account for hidden factors** and **Show the formula** on; turn them off only for a faster, exploratory pass. * **Account for hidden factors** (confounder modeling) — detects and accounts for hidden variables that are not in your data but could influence the variables that are. This improves the *defensibility* of the causal claims the twin makes. Recommended on. * **Show the formula** (equation discovery) — recovers the actual equations behind each relationship, not just which variables connect. You get an interpretable functional form rather than a black box. Recommended on. * **Delayed effects** (lag discovery; temporal types, experimental) — finds *lagged* causal relationships: effects that show up one or more time steps after their cause. *** ## Algorithm Versions Two engine choices, one per stage. The defaults are correct for most cases — change them only deliberately. * **Causal Discovery** — finds the cause-and-effect structure. The dropdown offers three generations for every twin type: **SPARC-fast** (the default), **SPARC** (adaptive multi-stage discovery), and **CausalACO** (metaheuristic structure learning). * **Digital Twin** — fits the runnable model on top of the discovered structure. **CausalBART** (a causal Bayesian-network simulator) is the default for static and multi-environment static twins; **GAAMT** (temporal causal network simulation) is used for temporal twins. Multi-environment temporal twins offer two variants: **GAAMT** (the default), which trains an independent temporal network for each environment — best when environments differ substantially or have abundant per-environment data — and **Pooled GAAMT + BART**, which trains one shared temporal network across all environments and applies per-environment BART corrections — best when environments share structure or some have limited data. *** ## Advanced Configuration *(inherited from the ontology)* These settings are carried over from the ontology you built earlier, so they usually need no change. You are free to adjust them for this twin version without affecting the ontology itself. ### Derived Columns Columns the system has detected as **calculated from other columns** — for example *Hour = hour(Order Date)*. The twin takes the derivation into account, so causal discovery does not mistake a mathematical identity for a genuine cause. Removing a row here changes only this twin version; your underlying data and saved ontology settings stay the same, and re-syncing from the ontology may bring it back. ### Variable Roles Classify a variable as a **Source** (an exogenous driver or input — say, a macroeconomic indicator) or a **Target** (an outcome you care about — say, sales). This keeps drivers upstream of outcomes when the model draws its causal arrows: a source can only receive incoming edges from other sources, and a target can only send outgoing edges to other targets. ("Incoming edges" are arrows pointing *into* a variable — that is, something causing it.) **From Ontology** and **Suggest with AI** fill the roles for you. ### Prior Knowledge Tell the model what you already know about specific relationships. Both lists are optional and both sharpen results when you have real knowledge to add: * **Known Relationships** — pairs you know are connected (for a temporal twin you can also set a lag). * **Blocked Relationships** — pairs you know are unrelated, so the model never links them. ### Variable Ordering Constrains which variables may precede others, so an effect can never be proposed as the cause of its own cause — *"Sales must come after Order Date, Price Each, and Hour."* Useful when temporal or domain order is known. *** ## Training the twin The run button sits in the **Review & run** step, and its label depends on the method chosen in step 1: * **Discover & train** — runs causal discovery, then trains the complete, runnable model — one action. This is the normal path. * **Train model** — trains directly on a graph you drew by hand, with no discovery step. * **Re-discover & train** / **Retrain model** — the same two actions when modifying an existing twin. A plain-language recap above the button restates your configuration (data and type, variables in play, roles, and prior knowledge), alongside validation checks, so you can confirm it before you start. *** ## Other Build a Digital Twin pages * [Selecting your Data View](/more-details/build-digital-twin/selecting-data-view.md) — choosing the data and reading the auto-filled configuration. * [Types of Digital Twins](/more-details/build-digital-twin/twin-types.md) — Static, Temporal, and the two Multi-Environment variants. * [Tuning for Fit](/more-details/build-digital-twin/tuning-for-fit.md) — adjusting the configuration to improve model fit. See [Digital Twin overview](/more-details/digital-twin.md) for the bigger picture.