Enterprise Digital Twins Need Stakeholder Buy-In Before Technical Sophistication
Enterprise Digital Twins promise data-driven decision support at organizational scale. They model supply chains, financial scenarios, and cross-departmental business strategies. But building one means navigating siloed departments with entrenched workflows, tacit knowledge that lacks explainability, and high-stakes decisions where mistakes have long-horizon, potentially irreversible consequences. Existing approaches involve domain experts during model development. They focus less on the harder problem: getting organizational buy-in before committing to a technical direction.
A team from Polytechnique Montréal and Michelin Canada, led by Kérian Fiter with corresponding author Bentley Oakes, presents a vision paper grounded in an ongoing collaboration with Michelin, a multinational manufacturer. The paper was presented at MODELS 2026 in Málaga. The core idea is simple and counterintuitive: involve stakeholders before evolving the system. Build a working prototype fast using foundation models, let stakeholders touch it and break it, then evolve toward federation and interoperability. The three-stage approach combines foundation models for rapid prototyping, an ontological backbone for federated interoperability, and observability tooling for stakeholder trust.
Why Existing Approaches Fall Short for Enterprise Digital Twins
The paper identifies a specific gap in the digital twin literature. Most DT research assumes a tight feedback loop between the physical system and its digital counterpart, where errors have immediate consequences and iteration is fast. Enterprise Digital Twins operate on a different timescale entirely. A prediction might drive a decision to restructure a supply chain or enter a new market, decisions that play out over days, months, or years. The authors call this a "long-loop DT": a human-in-the-loop affects the real system based on the twin, but at a longer timescale with potentially irreversible consequences.
This long-loop nature changes the engineering requirements. In a tight-loop DT, you can afford to iterate quickly because mistakes are caught early. In a long-loop DT, stakeholders need to understand and trust the twin's insights before they act on them. A misprediction that leads to a bad supply chain decision costs real money and cannot be undone by the next training run. This raises the bar for trustworthiness in ways that standard DT engineering does not address.
The collaboration with Michelin surfaces five specific challenges extracted through informal discussion with company stakeholders. Decision-making support to explore business strategies. What-if simulations of financial scenarios. Easy modeling by non-technical stakeholders. Interoperability across systems of systems. Observability of the solution and the scenarios. These are not primarily technical problems. They are socio-technical problems about organizational adoption, which is why the involving-before-evolving paradigm matters.
Stage One: Prototype Creation for Quick Involvement
The first stage targets the first three challenges: decision support, what-if simulation, and non-technical modeling. The approach is to rapidly capture requirements from subject matter experts in informal textual form, then build a minimum viable product using foundation models before investing in full verification and formalization.
The prototype uses three foundation model technologies. Large Language Models handle language understanding and generation for the user interface. Time-Series Foundation Models, specifically a locally-hosted instance of TimesFM 2.5, generate forecasts from historical time-series data. Monte Carlo simulation integrates uncertainty in the form of ranges and distributions to perform what-if financial simulations.
The concrete prototype is a decision support tool for marketing and finance departments. It takes historical time-series data as input and proposes a spline trajectory based on TSFM predictions, showing 10th and 90th percentile confidence intervals. Users can manually edit spline points and select uncertainty ranges to create their own trajectory predictions. This gives non-technical stakeholders a visual, real-time interface to embed their domain knowledge directly into the simulation. Monte Carlo sampling then propagates uncertainty through downstream expert-developed models, producing distributions over predicted business outcomes.
The key design choice is lifting user interactions from error-prone spreadsheet calculations to automated visual simulations. Business professionals currently rely on tacit knowledge to perform what-if analysis, which lacks explainability and data-based grounding. The prototype makes the reasoning visible: users can see how their input assumptions propagate through the model to produce outcomes. This is not a polished production system. It is a conversation starter that lets stakeholders experience the EDT concept and identify what they need from it.
The prototype was built using agentic LLMs hosted on Michelin's own infrastructure, which addresses data sovereignty from the start. Despite its simplicity, the prototype has been effective in securing buy-in and motivating discussion across marketing and finance departments. It led to refinement and creation of new requirements, such as representing multiple datasets to detect correlations and improving TSFM predictions through fine-tuning.
Stage Two: Federation for Interoperable Evolution
Once stakeholders have validated the prototype, the second stage federates departmental models using an ontological backbone. This targets the interoperability challenge across siloed systems of systems.
The federation approach follows a principle of business and architecture isomorphism: the technical structure mirrors the organizational structure. Each department retains ownership of its data, models, and services while committing to shared semantic contracts that guarantee interoperability. This is not a federated DT in the sense of composing autonomous twins into a single system. It is a DT characterized by coordinated autonomy, where departments operate independently but agree on how they communicate.
Ontologies serve three roles in this federation. Structural wiring ensures that when departments connect their twins, the ontology defines how each component can legally be composed, preventing structurally invalid federations. Typed interfaces ensure that data exchanged between departments carries an ontologically grounded type to reduce ambiguity, so when marketing sends a demand signal to supply chain, both sides agree on what that signal represents. Domain semantics expressed as constraints and rules enable automated consistency checks and inference, such as requiring that supply chain only acts on a demand forecast approved by finance.
The paper adopts the Ontological Modeling Language (OML), a Domain-Specific Language over OWL, to make ontologies accessible to domain experts. OML reduces the friction of developing ontologies in raw OWL or Protégé while preserving semantic rigor. The key insight is how ontologies are used: not merely as taxonomies that resolve terminology clashes, but as vehicles for encoding domain semantics as inference rules within each department's vocabulary. For example, historical data fidelity requirements differ across domains. One market may need ten years of history while another needs six months. Encoding this in ontologies lets the reasoning layer flag degraded outputs when models draw on mismatched fidelity inputs.
Stage Three: Observability for Promoting Trust
The third stage addresses trustworthiness through observability. SMEs rely on experience to make business decisions, and they are wary of decision-support tooling unless they trust its predictions. Trustworthiness here means the ability of stakeholders to inspect, understand, trace, and challenge EDT outputs while preserving data sovereignty and organizational accountability.
The approach uses an explainable formalism based on probability. Monte Carlo simulation produces distributions, not point estimates, which makes uncertainty visible. Sensitivity analysis can show which inputs most affect outcomes. Stakeholders define inputs through curve editing, aligning with their domain understanding of market tendencies and seasonal trends. The prediction module features versioning, ensuring stakeholders understand which tool version and datasets generated a prediction.
Privacy and safety are handled through local deployment. Foundation models run on Michelin's infrastructure, and the TSFM runs in a container on company hardware. No sensitive business data leaves the organization's control. The paper plans to enhance the DTInsight observability tool with lightweight OML modeling capabilities, enabling a continuous "constellation" visualization of the DT alongside a dynamic reporting page that tracks the EDT's evolution as it is being built.
What the Prototype Has Shown So Far
The paper is a vision document, not an evaluation paper, but the Michelin collaboration provides concrete evidence that the approach works at the prototype stage. The initial prototype for marketing and finance has secured stakeholder buy-in across departments. It has surfaced new requirements that the team had not anticipated, such as the need for correlation detection across datasets and TSFM fine-tuning for more precise predictions.
The prototype demonstrated that a simple visual interface, built quickly with foundation models, can do what months of formal requirements gathering often cannot: get stakeholders to engage with the EDT concept and articulate what they actually need. The authors note that this reverses the order of some ontology-first approaches, where formal modeling precedes prototyping. Starting from a validated prototype lets discussions begin from something tangible and gradually converge toward shared formal language.
Limitations and Open Challenges
The paper identifies three open challenges. First, it is unclear whether ontology-backed contracts can handle real semantic heterogeneity at scale, or whether automated consistency checks remain feasible as the federation grows. Second, scenario provenance, labeling, sharing, and comparing trajectory scenarios across departments over time, is important but not yet handled. Third, the long-loop timescale makes it methodologically difficult to evaluate whether EDT-informed decisions produce better organizational outcomes without a longitudinal study across multiple deployments, which is not feasible in this project.
The vision paper also does not address how the prototype scales. A working prototype for two departments is very different from an enterprise-wide system serving dozens of departments with conflicting priorities. The federated approach preserves departmental autonomy, but the ontological contracts that enable interoperability must be maintained as the system grows. The paper acknowledges this but does not provide a path to managing ontological drift across a large organization.
The reliance on foundation models introduces its own risks. TimesFM 2.5 is a powerful forecaster, but foundation models can produce plausible-looking outputs that are wrong. The Monte Carlo simulation helps quantify uncertainty, but the uncertainty ranges depend on the model's calibration, which may not be reliable for all business scenarios. The paper does not discuss how to validate foundation model predictions against domain-specific ground truth in a business context.
What This Means for Digital Twin Engineering
The involving-before-evolving paradigm addresses a real gap in digital twin engineering. Most research focuses on the technical architecture of twins, how to model, simulate, and interconnect them. Less attention is paid to the organizational problem of getting stakeholders to adopt and trust the system. The long-loop nature of enterprise digital twins makes this problem particularly acute: you cannot iterate fast enough to build trust through trial and error.
The three-stage approach is pragmatic. Foundation models let you build a working prototype in days rather than months, which is enough to start a conversation with stakeholders. The ontological backbone provides a path to interoperability without requiring a big-bang integration. Observability makes the system's reasoning visible, which is necessary for trust in high-stakes decisions. Each stage addresses a specific organizational barrier.
The paper also contributes to a broader conversation about the relationship between technical sophistication and organizational adoption. The prototype is deliberately simple, using spline editing and basic time-series forecasting. It works because it meets stakeholders where they are, in spreadsheets and visual dashboards, rather than asking them to learn a new formalism. The formal ontological backbone comes later, after stakeholders have already validated the concept. This is a lesson for anyone building complex systems for organizations: technical elegance matters less than whether people will actually use it.