> 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/selecting-data-view.md). # Selecting your Data View Building a digital twin begins with one choice: which data it learns from. Almost everything else on the build screen is then proposed for you. In RootCause that data is a **Data View** — the analysis-ready table (the "360 table") you assembled in [Build 360 Table](/user-guide/data-views.md). When you select a Data View, the platform reads its structure and fills in a complete build configuration: the twin's type, how it handles time, how it groups the data, which variables to include, and how they relate. You review and adjust that proposal rather than build one from nothing. *** ## Starting a new digital twin From the Digital Twins section, choose **New Digital Twin**. In the builder's **Choose your data** step, the one required choice is the **Data View** — select one and the rest of the configuration autofills.
The builder's first two steps: How do you want to build it with Discover from data selected, and Choose your data with the Data View picker set to Customer Subscription info x Customer Details and a Type selector where Static is marked Recommended and the time-based types are disabled

The builder's opening steps: pick the Data View and the platform marks which twin types the data supports, here Static as Recommended with the time-based types disabled.

The **Name** fills in automatically from the data view's name — here, *Digital Twin - Customer Subscription info × Customer Details*. Leave it to auto-generate or type your own. A **Validate** check confirms the data view is usable for training. *** ## What the platform fills in The proposal is not a fixed form. The platform picks the most specific **twin type** your data supports and shows only the controls that type needs — so the screen you see depends on the data you selected. A simple table produces a short screen; a grouped time series produces a long one. Two examples show the range. ### Example: a static twin A *static* twin treats each row as an independent case — one row per customer, say — with no time dimension. The build screen stays short: the data view, a **Type** of Static, the **Fields** to include, a couple of training options, and the inherited **Advanced Configuration**. No time column and no environments — there is no time axis, and no groups to separate. ### Example: a multi-environment temporal twin A *multi-environment temporal* twin tracks many groups over time. Take an example dataset — a table of sales orders, each tagged with a **product** and a **city**, recorded over time (just one example; your data will differ). The same screen now carries more, because the data has both a time axis and groups to keep apart: it adds a **Time Column** and **Environment Columns** that the static screen never shows. ### What appears, and when Every build screen, whatever the type, includes: * **Name** — auto-generated from the data view; editable. * **Type** — Static, Temporal, Multi-Environment Static, or Multi-Environment Temporal. The platform ticks every type your data supports and selects the most specific one. See [Types of Digital Twins](/more-details/build-digital-twin/twin-types.md). * **Fields** — the variables fed into causal discovery. All are included by default; free-text (string) columns are ignored, because the discovery algorithm cannot use them. * **Training options** — toggles such as accounting for hidden factors and recovering the underlying formula behind a relationship. * **Advanced Configuration** — variable roles, prior knowledge, and ordering constraints, all *inherited from the ontology* you built earlier. Other controls appear only when the type calls for them: * **Time Column** — for temporal types: the field that orders events over time (here, *Order Date*). * **Environment Columns** and **Parallel pieces** — for multi-environment types: the categorical columns that split the data into separate environments (for example, *Product* or *City*), and — under the review step's Advanced settings — how many parallel pieces to split training into. * **Lagged-effect discovery** — for temporal types: an option to find delayed effects across time steps. Either way, the result is a working configuration before you have changed a single setting. *** ## What to do next The proposal is a starting point, not a verdict. Two of the auto-filled choices do most to shape the result: * **Type** and **Environment Columns** decide how the model partitions and learns from your data. They are the settings most worth understanding, and the first ones to revisit if the model fits poorly — see [Tuning for Fit](/more-details/build-digital-twin/tuning-for-fit.md). * Every control on the screen can be changed before you train. [Configuration to Build Digital Twin](/more-details/build-digital-twin/build-configuration.md) walks through each one. When the configuration looks right, you train the twin from the **Review & run** step: **Discover & train** runs discovery and training in one action, or **Train model** trains directly on a graph you drew by hand. *** ## Other Build a Digital Twin pages * [Types of Digital Twins](/more-details/build-digital-twin/twin-types.md) — Static, Temporal, and the two Multi-Environment variants. * [Configuration to Build Digital Twin](/more-details/build-digital-twin/build-configuration.md) — every control on the build screen. * [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.