On Integrating Resilience and Human Oversight into LLM-Assisted Modeling Workflows for Digital Twins
Organizations: Indian Institute of Technology Goa Goa, India
Abstract
LLM-assisted modeling holds the potential to rapidly build executable Digital Twins of complex systems from only coarse descriptions and sensor data. However, resilience to LLM hallucination, human oversight, and real-time model adaptability remain challenging and often mutually conflicting requirements. We present three critical design principles for integrating resilience and oversight into such workflows, derived from insights gained through our work on FactoryFlow - an open-source LLM-assisted framework for building simulation-based Digital Twins of manufacturing systems. First, orthogonalize structural modeling and parameter fitting. Structural descriptions (components, interconnections) are LLM-translated from coarse natural language to an intermediate representation (IR) with human visualization and validation, which is algorithmically converted to the final model. Parameter inference, in contrast, operates continuously on sensor data streams with expert-tunable controls. Second, restrict the model IR to interconnections of parameterized, pre-validated library components rather than monolithic simulation code, enabling interpretability and error-resilience. Third, and most important, is to use a density-preserving IR. When IR descriptions expand dramatically from compact inputs hallucination errors accumulate proportionally. We present the case for Python as a density-preserving IR : loops express regularity compactly, classes capture hierarchy and composition, and the result remains highly readable while exploiting LLMs strong code generation capabilities. A key contribution is detailed characterization of LLM-induced errors across model descriptions of varying detail and complexity, revealing how IR choice critically impacts error rates. These insights provide actionable guidance for building resilient and transparent LLM-assisted simulation automation workflows.
Figures & tables
| ID | Category | Description & Example |
| T1 | Naming errors | Inconsistent identifiers, off-by-one indexing, or violated naming conventions. Example: Grid systems use 0-based indexing when description specifies 1-based (S21, S24); buffers renamed to generic identifiers from few-shot examples ( edge[0] , src_edge[0] ); naming errors increase with description detail rather than decrease. |
| T2 | Parameter errors | Incorrect parameter values, misapplied defaults, or ambiguous conflict resolution. Example: S13 prioritized stage-specific values over generic statements; routing policies defaulted to ROUND_ROBIN when unspecified (S30, S31-S35). |
| T3 | Node hallucination | Addition or omission of nodes (machines, buffers, sources, sinks). Example: S3 hallucinated an extra machine to satisfy perceived edge constraints; S35 hallucinated 10 nodes not in description. |
| T4 | Edge hallucination | Addition or omission of edges (connections between components). Example: S18 inferred two feedback connections instead of one based on ambiguous phrasing; S35 hallucinated 7 edges. |
| T5 | Parameter hallucination | Generation of parameter specifications not present in description or incorrect parameter structures. Example: S23, S25 hallucinated routing behavior as explicit lists instead of supported policy types; S35 hallucinated many parameter values not specified. |
| T6 | Hierarchy mismatch | Incorrect hierarchical structure, flattening of nested subsystems, or misplaced component scope. Example: S13, S15, S18, S24, S31 collapsed explicitly described subsystems into flat topologies; S26 reinterpreted hierarchical system as single serial flow; S24 assumed single global source/sink instead of per-row hierarchy. |
Appendix figures & tables6 assets
Supplementary material from the paper’s appendix.
Appendix
Digital Twins
Digital twins are virtual models synchronized with real systems to support monitoring, prediction, simulation, and decision-making.
See all 253 papers