DesCartes Builder: ML Digital Twins

• DesCartes Builder is an open-source tool that systematically engineers machine-learning-based digital twins by composing multiple learned functions into interconnected, task-specific pipelines.
• It employs a Function+Data Flow (FDF) domain-specific language that distinctly manages data and function flows, ensuring compatibility and error prevention through implicit typing.
• The tool supports a two-stage workflow that first creates a digital twin prototype from high-fidelity simulations and then specializes it using historical sensor data for real-time applications.

DesCartes Builder is an open-source tool for the systematic engineering of machine-learning-based digital twins, especially when those digital twins must be real-time, accurate, and maintainable. It is introduced to address a specific mismatch between conventional machine-learning tooling and digital-twin development: standard ML pipelines usually train a single model for a single task, whereas a useful digital twin often consists of several interacting learned functions whose composition depends on domain requirements and operational tasks. In this formulation, DesCartes Builder is not merely a model-training interface; it is a visual environment for designing, connecting, executing, validating, exporting, and reusing multiple learned components within one digital-twin-oriented pipeline (Conto et al., 25 Aug 2025).

1. Digital-twin scope and lifecycle

DesCartes Builder is framed around a distinction between a physical twin (PT) and a digital twin (DT). The PT is the real-world asset or system being monitored. The DT is the software counterpart that “accurately mirror[s] and co-evolve[s]” with the PT. Within that general notion, the paper further distinguishes a DT prototype from a DT instance. A DT prototype is a general digital model of nominal PT behavior derived from high-fidelity simulations; a DT instance is obtained by specializing that prototype to a specific physical asset by using historical sensor data from the target PT (Conto et al., 25 Aug 2025).

This lifecycle is motivated by the operational role of DTs in settings such as civil engineering, where they are expected to support continuous monitoring, predictive maintenance, and optimization. The paper emphasizes a persistent tension: high-fidelity physics-based models are often the natural starting point for representing the PT, but those models become computationally expensive and potentially numerically unstable as system complexity increases. A practical DT, however, is expected to operate under real-time constraints. The proposed response is a two-stage ML workflow. First, reduced-order models are learned from high-fidelity simulation data to create a real-time DT prototype. Second, that prototype can be specialized into a DT instance using historical sensor data from a target PT. DesCartes Builder makes this process explicit, structured, and reusable rather than ad hoc.

The paper’s main conceptual claim is therefore architectural rather than theorem-like. A DT is treated as a structured composition of learned functions rather than as a single predictor. This is significant because DT construction may require, for example, an encoding function learned through unsupervised learning, a supervised surrogate defined on reduced variables, and exported learned functions that are reused elsewhere in the pipeline. The tool’s role is to make those dependencies visible and operational.

2. Function+Data Flow model

The central software abstraction of DesCartes Builder is the Function+Data Flow (FDF) domain-specific language. FDF uses a higher-order visual data-flow paradigm in which functions representing learned ML models are first-class citizens. In practice, this means that one pipeline component can output a learned function and another component can later consume that function. The paper presents this explicit distinction between data flow and function flow as the mechanism that allows DT-oriented multi-model pipelines to be expressed directly (Conto et al., 25 Aug 2025).

FDF box type	Role	Visual form in the paper
Processor	Reuses learned functions or predefined functions	Light blue rectangle
Coder	Learns an encoding/decoding function with unsupervised ML	Pale green trapezoid
Trainer	Learns a function with supervised ML	Pale violet pentagon

This design makes learned functions into explicit pipeline artifacts. The paper’s startup example illustrates the semantics. A Coder takes input data $X$, learns a reduced representation, and returns a function called reduce. A Processor then applies reduce to $X$, producing $X_{\text{red}}$. A Trainer learns a supervised function predict from $(X_{\text{red}}, Y)$, where $Y$ is the DT simulation target. The exported DT prototype then consists of at least the learned mappings reduce and predict. In symbolic form, the paper describes the implied structure as

$$X_{\text{red}}=\texttt{reduce}(X), \qquad \texttt{predict}: X_{\text{red}} \mapsto Y.$$

The FDF model also supports specification-time checking through implicit typing. The paper gives a warning example in which eps_red is connected where displ_red is expected. Because the reused model function expects an input with the implicit type associated with displ_red, the system detects the mismatch. The pipeline can then be corrected, or typing can be manually overridden if the two reduced variables should be treated as sharing a type. This is presented as a software-engineering mechanism for maintainability and error prevention.

The mathematical content remains intentionally light. The paper mentions reduced-order modeling, PCA, and gradient descent, but it does not formalize loss functions, projection equations, state-estimation updates, or adaptation objectives. This suggests that the paper’s primary contribution lies in workflow representation and execution semantics rather than in a new mathematical formalism for DT estimation or control.

3. Software architecture and execution model

DesCartes Builder is organized as a graphical front end, an execution back end, and an abstract execution engine that mediates between them. The front end is implemented in C++ using Qt and QtNodes. It provides a unified graphical interface for specifying, executing, and validating ML-based DT pipelines. Its interface includes a central canvas for drag-and-drop creation of FDF graphs, a library selector and parameter editor for adding and configuring boxes, a Run button for execution, log and output panels for execution traces, and a chart viewer for validation plots and metrics. Function connections are shown in red and data connections in black, making the separation between the two flows visually explicit (Conto et al., 25 Aug 2025).

Execution proceeds by generating back-end code from the front-end FDF graph and user-specified parameters. The back end is implemented in Python as a Kedro plugin. It has two stated responsibilities. The first is pipeline orchestration: loading input data, determining execution order and dependencies in the FDF graph, executing the pipeline according to FDF semantics, and saving results. The second is library definition: each front-end box corresponds to a function in a library of predefined functions and learning algorithms. The architecture is therefore layered. The UI handles model composition and user interaction, the abstract execution engine decouples UI from computation, and the back end performs the actual training, transformation, evaluation, and artifact generation.

This separation is tied directly to the paper’s maintainability claims. In the described implementation, reusable learned-function artifacts are not hidden inside monolithic code stages. Instead, they are explicit pipeline outputs that can be routed to compatible Processors or exported for deployment. The tool is therefore positioned as infrastructure for structured DT synthesis rather than as a thin wrapper around isolated ML training routines.

4. Workflow, supported operations, and DT engineering phases

The workflow supported by DesCartes Builder begins with data collection or generation. For DT prototypes, the primary source is high-fidelity simulation data representing nominal PT behavior. The paper repeatedly states that sensor data are then used later to specialize the prototype into a DT instance. Within the prototype-building phase, the workflow can be reconstructed as: data acquisition, unsupervised learning of reduced-order components, application of learned transformations to obtain reduced variables, supervised learning of a surrogate on those reduced variables, validation, and export of the learned functions that constitute the deployable DT prototype (Conto et al., 25 Aug 2025).

The built-in library is described as a set of parameterizable core operations and ML algorithms tailored for DT design, but the paper does not provide a full catalog. Concretely demonstrated operations include standardization, PCA, supervised neural-network training by gradient descent, predefined Processor functions such as scoring, and export of learned functions. This confirms support for preprocessing and dimensionality reduction, supervised surrogate learning, evaluation, and artifact export. The paper also emphasizes extensibility: because the system is open-source and each front-end box maps to a back-end function, additional algorithms and operations can be integrated. A plausible implication is that the FDF abstraction is intended to support a growing DT-oriented ecosystem of reusable components, although the paper does not enumerate plugin APIs or a complete algorithmic taxonomy.

The tool supports DT development in two phases aligned with the paper’s DT lifecycle argument. In the first phase, a DT prototype is built from high-fidelity simulations of nominal PT behavior. In the second phase, that prototype can be specialized into a DT instance using historical sensor data from a particular PT, for example to account for manufacturing defects or asset-specific deviations. The paper strongly motivates this second phase, but the practical demonstration focuses only on the first phase.

Validation support is present but methodologically limited in the paper’s presentation. Training and validation are performed “as needed,” outputs and plots are displayed in the UI, and explicit scoring processors can be inserted into the graph. However, the paper does not describe automated train/validation/test splitting, cross-validation, or hyperparameter search. It explicitly notes that the case-study evaluation is done on the training set and that more robust evaluation procedures may be necessary in practice.

5. Civil-engineering case study

The paper’s worked example concerns structural health monitoring through prediction of the plastic strain of a structure. The practical motivation is that plastic strain cannot currently be measured non-destructively, whereas deformation can be estimated, for example from high-resolution photographs. The goal is therefore to construct a DT prototype that predicts plastic strain from deformation information. The underlying PT is modeled by a finite element model, and a collaborator provided high-fidelity simulations estimating plastic strain eps and deformation displ under varying material parameters such as impact strength and thickness (Conto et al., 25 Aug 2025).

The computational bottleneck is explicit: each high-fidelity FEM simulation takes around one hour. Because that is incompatible with online DT use, the authors apply a design of experiments strategy to sample combinations of material parameters that cover the meaningful behavioral space of the material. The resulting deformation and strain meshes are initially high-dimensional, with more than 1000 dimensions each.

The case-study pipeline has three principal stages. First, dimensionality reduction is performed by two Coder boxes, std_PCA_displ and std_PCA_eps, which apply standardization followed by PCA to deformation and plastic strain respectively. The dimensionality is reduced from more than 1000 dimensions to approximately 10 dimensions. The learned reduction functions are red_displ and red_eps, and Processors reduce_displ and reduce_eps apply them to produce displ_red and eps_red. Second, a Trainer box learns a neural network by gradient descent to predict eps_red from displ_red; the learned supervised function is named model. Third, a score Processor compares predicted reduced strain values eps_red_p against ground-truth reduced strain eps_red. The paper summarizes the workflow as

$$\texttt{displ\_red} = \texttt{red\_displ}(\texttt{displ}),$$

$$\texttt{eps\_red} = \texttt{red\_eps}(\texttt{eps}),$$

$$\texttt{model}: \texttt{displ\_red} \mapsto \texttt{eps\_red},$$

$$\texttt{eps\_red\_p} = \texttt{model}(\texttt{displ\_red}).$$

The reported empirical results are qualitative. The chart viewer shows an actual-vs-predicted plot in which points lie close to the ideal $X$0 line, and the paper interprets this as indicating high predictive accuracy and strong agreement between eps_red and eps_red_p. No numerical values such as RMSE, MAE, $X$1, latency, memory footprint, or throughput are reported, and no explicit baseline model comparison is given. The implicit baseline is the original FEM simulation workflow, whose runtime of about one hour per simulation makes direct real-time use impractical.

The paper also notes a boundary on what is demonstrated. Although the architecture anticipates inverse decoding and a figure shows export of an out_inv_eps function, no formal reconstruction equation from reduced strain back to the full-dimensional field is provided in the text. Likewise, prototype specialization into DT instances is argued for conceptually but is not demonstrated experimentally in this use case.

6. Positioning, reproducibility, and limitations

DesCartes Builder is positioned against three categories of existing tools. Commercial physics-based DT tools such as Ansys Twin Builder and Siemens Simcenter Amesim can support ROM generation, but the paper characterizes them as relying on proprietary, predefined workflows with limited user control. General ML workflow tools such as Kedro and MLflow support customizable workflows and ML training, but are described as mostly textual, code-centric, and oriented toward a single ML model not explicitly represented in the pipeline. DT/PT integration platforms such as Azure Digital Twins and GreyCat emphasize data definition and online interaction, but the paper states that they do not include built-in support for ML training and instead focus on online inference. DesCartes Builder is therefore presented as occupying the specific niche formed by a graphical modeling UI, customizable workflow, ML training support, a DT-oriented library, open-source availability, and usability for domain experts with minimal programming expertise (Conto et al., 25 Aug 2025).

Implementation and reproducibility details are part of that positioning. The front end is implemented in C++ using Qt and QtNodes, the back end in Python as a Kedro plugin, and the tool is released as open source. The paper states that documentation, screenshots, a Docker container, and a short demonstration video are available online, and that GitHub links are provided for both front end and back end. This infrastructural release is significant because the contribution is partly a software environment rather than only an algorithmic method.

The limitations stated or implied in the paper are substantial. The experimental evaluation is a demonstration on a single use case rather than an extensive benchmark study. The case-study evaluation is carried out on the training set, and more robust evaluation procedures are explicitly acknowledged as necessary in practice. The paper strongly motivates DT instance specialization using historical sensor data but does not present a detailed specialization experiment. It also does not provide a formal mathematical treatment of ROM construction, data assimilation, or adaptation. Finally, it reports no hard measurements of real-time latency, scalability, memory cost, or robustness under distribution shift.

These limits define the scope of the paper’s claims. DesCartes Builder is presented as a concrete step toward moving ML-based digital-twin engineering beyond handcrafted workflows and toward explicit pipeline design. This suggests a broader research program around stronger evaluation protocols, richer libraries of DT-specific operations, and empirically validated specialization workflows, but such directions remain inferred rather than formally stated commitments.