The Simulatable Enterprise: Test the Decision Before Making the Commitment

Enterprise digital twins: connected does not yet mean simulatable

Connecting SAP, CRM, product services and manufacturing systems makes information accessible. It does not establish how changing one variable will affect the business. A map of customers, contracts and products describes relationships. To test a pricing intervention, the model also needs assumptions about conversion, retention, cost and capacity—and evidence for using those assumptions in the proposed market.

The distinction can be made without arguing over product labels:

Digital-twin definitions differ across disciplines. ISO 23247-1:2021 establishes a manufacturing framework; it does not standardize a universal model of a company. The National Academies’ 2024 study emphasizes dynamic updating, predictive capability and feedback between the representation and its real referent. A dashboard or document graph alone does not supply those properties. Feedback can include human decisions; it need not grant software autonomous control.

A digital thread concerns traceability across lifecycle information. A digital shadow commonly describes an observed-data connection without the full reciprocal relationship associated with a twin. These distinctions help specify an architecture, but a terminology upgrade does not improve its validity.

A company does not need a comprehensive digital twin before using AI—or before running a useful simulation. A bounded model of one order process, component or commercial investment may be enough. Conversely, adding a graph, live feed or 3D scene does not turn an inadequate model into a trustworthy simulator.

The architecture separates facts, assumptions, results and actions

The enterprise AI architecture Perspective explains the foundations: identifiers, authoritative sources, code dependencies, retrieval and bounded operations. The additional architecture here begins where a representation acquires explicit behavior and is used to compare interventions.

Start with a versioned observation boundary. Record the customer, product, part or contract identifiers; source versions; effective dates; event times; extraction times; and relevant permissions. Live data and historical evidence have different uses. A historical event log may inform duration estimates, while an approved configuration or current order book determines whether a proposed action is still feasible.

APIs provide selected reads or authorized operations. Events and change-data capture update derived representations. They need ordering, duplicate handling and reconciliation. An event arriving late must not silently overwrite a newer effective state. A missed event requires a recovery path. Kafka’s transaction documentation explicitly distinguishes its guarantees from cooperation required at external destinations; an integration architecture cannot assume exactly-once business consequences everywhere.

Where SAP and CRM disagree, retain the disagreement until an accountable owner resolves the relevant fact. Finance may own booked revenue, CRM an opportunity stage, and product systems an entitlement. A source-of-truth map is defined per fact, not by declaring one application universally authoritative. Temporal joins must specify whether they mean “known then” or “effective then.” Mixing those meanings can make a backtest accidentally use future information.

The semantic layer can remain distributed. Relational mappings may suffice; a graph becomes useful when traversal and evolving relationships justify it. Legacy-code dependencies help locate rules and change impacts. They do not reveal customer price elasticity. Provenance must follow derived values into the executable model, including manual assumptions and unresolved omissions.

The simulation environment receives a frozen input package. Its runs identify model version, configuration, solver, random seed where relevant and scenario intervention. AI can propose inputs or request approved runs through ordinary interfaces or MCP tools. The protocol exposes operations; it does not replace integration, validate the model or confer business authority.

Keep the scenario sandbox separate from production-write credentials. A proposed intervention becomes an action only through an authorized business operation, with current-state checks and an accountable approver. Model outputs return as evidence for a decision, not as commands the company must obey. Real outcomes then feed model review and calibration.

The Simulation Validity Contract makes trust conditional

Before using a model to justify a material commitment, I would require a Simulation Validity Contract: a proposed management instrument stating what decision the simulation may support, under which conditions, and what withdraws that permission. It is not an established standard, a certificate or a substitute for engineering judgment.

The contract joins twelve fields into one decision record:

The contract must change the decision. A component model may support comparing two designs within a tested load range, but not approving a new material under an untested temperature regime. A SaaS model may support designing a market-entry experiment, but not asserting a precise probability of commercial success. The permitted use can be exploratory analysis, a bounded pilot or a specified commitment; uncertainty determines which is justified.

Make expiry event-driven as well as time-driven. A changed bill of materials, new pricing policy, missing event stream, different customer segment or persistent residual pattern may invalidate the relevant use immediately. Re-running an unchanged simulator is not renewal of its evidence.

This contract makes disagreement productive. Engineering can challenge the mechanism. Finance can challenge the cash assumptions. Operations can challenge capacity. The executive can ask which unknown would actually change the investment decision. Unresolved uncertainty is then attached to an action boundary rather than buried beneath a polished scenario presentation.

Six stages with deliverables and stop gates

Causality is the boundary between a scenario and a claim

Historical data shows what happened under historical conditions. It does not directly reveal what the same business would have done under a different price, service policy or market entry. Selection, confounding and changed incentives matter. Successful customers may receive better service because they are already valuable; that does not establish the effect of offering identical service to every prospect.

Separate four questions. A forecast estimates what may happen if relevant conditions persist. A simulation computes what follows from specified mechanisms and inputs. A counterfactual asks what would happen under an alternative intervention and needs appropriate causal assumptions. Optimization chooses the best feasible action under an encoded objective. An optimizer cannot repair a false demand response.

The discipline described in Hernán and Robins’ causal-inference text is relevant beyond its original application settings: specify the intervention and the conditions under which observed evidence can support it. In an enterprise, that may require a randomized pilot, a defensible quasi-experiment, engineering mechanisms or an explicit acknowledgment that a scenario is only exploratory.

This is particularly important for organizations. Lyytinen and colleagues identify agency, conflict and emergence as challenges for full organizational twins. People react to the model, the target and one another. Competitors respond. A pricing experiment can change who becomes a customer. The enterprise is not simply a machine with perfectly observed parameters.

AI-generated customer agents do not remove that uncertainty. Human-like language is not observed purchasing behavior. Research cautioning against LLMs as human surrogates reinforces the need to distinguish plausible responses from evidence about a target population. Such agents may help generate hypotheses; they cannot certify willingness to pay in an unobserved market.

The ACL 2026 ShopCART study makes the distinction measurable. Its dataset contains 31,865 shopping sessions and 230,965 actions. DeepSeek-R1 scored 11.86% and reasoning-tuned Qwen2.5-7B 17.26% in session-averaged exact next-action accuracy: correct predictions divided by eligible predictions within each held-out session, then averaged across sessions. Dataset totals are not the evaluation denominator. Models received simplified HTML and recorded history, without shoppers’ visual cues. This tests action prediction for the studied shopping tasks and models, not every business or future model. It does not validate new-market conversion assumptions.

The practical consequence is not paralysis. It is a smaller claim and a better next action. Simulate operational constraints where mechanisms are credible. Stress-test commercial assumptions where evidence is weak. Use a real experiment to learn the response that decides the investment.

Choose tools by the mechanism they must represent

The methods are complementary, not interchangeable. A useful shortlist begins with the question and the evidence available to support its mechanisms.

Licensing is part of architecture. SimPy uses MIT, Mesa Apache-2.0 and PySD MIT licensing. PM4Py’s maintained distribution uses AGPL-3.0 with an alternative commercial offer. Commercial simulation editions and solver licenses differ; an educational or evaluation entitlement is not a general production license. OpenModelica has its own licensing alternatives and component considerations. Select the actual edition and deployment model, not just a product name.

Process mining can reveal observed flows, conformance and bottlenecks. It does not supply intervention validity by itself. Camargo, Dumas and González-Rojas show why sequence fit, temporal accuracy and editable what-if behavior are different objectives. More predictive flexibility can make intervention assumptions harder to inspect.

The September 2026 WEFTSIM study reports automated DES construction from manufacturing event data, scenario comparisons and validation against historical behavior. Discovered sequences, fitted duration distributions, executable what-if logic and tested intervention effects remain separate evidence requirements. Historical resemblance supports reproducing the observed regime; a novel routing or staffing policy still needs justified response mechanisms and operational verification.

AI assistance is most credible when intermediate artifacts remain inspectable. The 2026 Sketch2DES preprint tests a bounded workflow from diagrams through schema-validated representations to deterministic simulation construction. That is a useful direction, with restricted scope—not evidence that an agent can build a valid model of any enterprise. Ordinary code and durable jobs are often sufficient; orchestration tools can help with resumable runs and human intervention without becoming a source of scientific validity.

Two minimum paths keep the stack practical. Industrial: PLM/MES/ERP → reconciled asset and configuration semantics → validated engineering/process model → optional AI acceleration → engineering approval. Software business: CRM/finance/product → consistent cohort and operating definitions → bounded demand/capacity/economic model → scenario analysis → reversible market experiment. Start with versioned extracts and ordinary code where sufficient. Live synchronization, graphs and surrogate training add cost only worth paying when the decision needs them.

Industrial example: a cheaper part can make the product more expensive

Consider a hypothetical manufacturer evaluating a redesigned mechanical component. The question is whether lower material cost survives structural, manufacturing and supply constraints. This is not a reported customer case, and no finite-element or physical test is claimed here.

The model boundary begins with a specific part revision, assembly configuration and intended operating envelope. CAD owns the geometry; PLM the released revision and approved configuration; the materials database the relevant properties and their provenance; MES the observed process behavior; ERP the costs and orders; quality records the measured deviations. Supplier assumptions need their own date and validity. A model built from the latest geometry and an older material specification is not a valid configuration simply because both files loaded successfully.

For that exchange, the Asset Administration Shell specifications provide asset representation and submodels; the OPC UA companion specification maps an AAS metamodel into a server address space. Its published v1.00 references AAS 2.0.1; it is not an automatic mapping for every newer IDTA model. Pin the versions and test the mapping. A concrete input package could bind a part’s asset identifier to the PLM revision, material dataset and MES observations, with units and timestamps, before passing a selected configuration to a solver or compatible FMU. AAS organizes the information; it does not calculate physical behavior.

Separate three analyses. An engineering model assesses behavior under defined loads, temperatures, contact assumptions and tolerances. A manufacturing model examines routing, cycle-time variability, yield, queues and capacity. A financial model compares material, conversion, tooling, qualification, scrap and supply effects over a stated volume. Passing one is not passing the others.

For engineering, a suitable CAE or finite-element workflow requires defensible boundary conditions, material behavior, mesh or numerical convergence checks and comparison with relevant physical measurements. A visually convincing stress plot does not establish fatigue life. If the proposal changes the material or load regime beyond the validated domain, appropriate coupon, component and assembly tests remain necessary. The responsible engineer determines applicable requirements and acceptance evidence.

For repeated design screening, consider a surrogate only if enough solver or measured examples justify its training cost. PhysicsNeMo provides physics-informed networks, neural operators and graph-based architectures; NVIDIA’s AI-Aided Engineering research investigates learned physical fields and inverse design. For this hypothetical component, use a surrogate to screen candidates within tested geometry, material and load ranges. Check held-out configurations, decision-critical errors and uncertainty calibration against an accepted solver and measurements. New material or untested loads trigger solver review and physical evidence. Fast inference does not eliminate training cost, domain shift or engineering approval.

Manufacturing can then reject an apparently superior design: a narrower tolerance may raise scrap, a new machining step may overload the bottleneck, or a supplier change may create an unacceptable lead-time dependency. Use discrete-event analysis where variability and resource contention materially affect delivery. Keep unit economics attached to good parts, not merely to parts entering the process.

Here is a deliberately simple, illustrative calculation: 10,000 good parts annually; material cost falls from €12.00 to €10.80; extra conversion cost is €0.30 per good part; qualification and tooling cost €24,000. Conditional annual saving is 10,000 × (€12.00 − €10.80 − €0.30) = €9,000. Simple payback is €24,000 / €9,000 ≈ 2.67 years, before discounting, additional validation, scrap changes or supply disruption. None of those assumed amounts is an observed company result.

The saving authorizes no safety conclusion. The validity contract might permit only a controlled engineering trial until physical evidence, supplier capability and capacity checks pass. If an adverse yield assumption removes the economic benefit, that measurement becomes a priority before tooling is committed. AI can help reconcile specifications, generate candidate scenarios and explain results. It cannot invent material properties or sign off structural safety.

Real implementations illustrate the boundary. A NIST CNC-machine study connects a Pocket NC machine through MTConnect and MQTT with its digital representation and co-simulation tooling. It demonstrates a concrete integration path; it does not establish a universally predictive factory model. Siemens’ Wipro PARI case describes virtual commissioning with Process Simulate, SIMIT and hardware-in-the-loop controls. Its transferable lesson is testing configured behavior before commissioning. Reported benefits remain vendor-reported, not a general return assumption for this component decision.

Market-entry example: a positive upside is not an investment case

Now consider an established B2B SaaS company entering another European market. This example uses synthetic assumptions, not WiredMinds data or an observed demand forecast. It has a 24-month horizon, one customer cohort stock and explicit acquisition, retention, cost and capacity rules.

Let retained customers equal last month’s customers multiplied by one minus monthly churn. New customers arrive only after the assumed initial sales lag and are limited by remaining support capacity. Active customers determine monthly revenue; revenue multiplied by gross-margin rate gives gross contribution. Subtract acquisition spend, local fixed costs and initial localization. Accumulate monthly net amounts to expose peak funding need rather than looking only at the final total.

For this illustration, capacity is 400 support hours monthly at 0.6 hours per active customer; local fixed cost is €20,000 monthly; initial localization costs €120,000. Gross-margin inputs already include the modeled direct hosting and support cost, so that cost is not subtracted again. CAC excludes the local fixed cost. Customers pay monthly without collection delays. Tax, FX, working-capital timing and terminal value are omitted and would need explicit treatment in a real funding decision.

These are three runs of the same monthly model, not three unrelated revenue spreadsheets. Rounded outputs are:

No scenario probabilities are assigned. The positive upside is not an expected return. The base case still needs roughly €411k of cumulative funding before its position improves, and has not repaid the modeled commitment by month 24. That is a materially different decision from approving a market because its eventual monthly margin looks attractive.

Sensitivity changes the next action. Reducing base acquisition by 20% produces approximately −€166k net over the horizon. Raising CAC by 30% produces about −€284k; reducing price by 10%, holding conversion and churn fixed, gives about −€187k. That last condition is deliberately restrictive: a real price change may alter both conversion and customer mix. The model must not treat the isolated calculation as the causal effect of a discount.

Halving support capacity caps the base customer stock near 333 instead of 346. The simplified calculation can become less negative because it avoids some acquisition spend. That is not proof that worse service capacity creates value. It exposes the encoded objective and the omitted behavior: real waiting, onboarding delays or poor service may change retention and referrals. Those feedback rules need operational evidence and structural sensitivity, not convenient parameter tuning.

Internal CRM and product history can inform cohort definitions, pipeline timing, support demand and existing-market retention. New-market conversion, competitive reaction, willingness to pay and localization quality need external evidence and a bounded real-world test. A competitor price change can invalidate the initial scenario domain. Synthetic customer agents cannot close that evidence gap.

An executive response could be to release at most €40k of the illustrative €120k localization allowance for a bounded validation phase, while holding the larger launch commitment. Define what must be learned about paid conversion, acquisition cost, support load and early retention, along with a loss limit and stop date. That allocation is a proposed decision, not an additional cost already included twice in the table. The value of the model is that it identifies which uncertainty deserves real evidence before more capital is exposed.

Filled contract: the next market-entry commitment. Compare holding entry, funding a bounded pilot and funding the launch. The model covers the stated 24-month customer/capacity/cash mechanism; conversion, competitor response and new-market retention remain assumptions. Existing-market cohorts inform it but do not validate demand elsewhere.

Permit at most €40k of the €120k localization allowance for evidence gathering; permit neither a success probability nor full-launch approval. Illustrative gates for another evidence tranche are observed CAC no higher than the assumed €1,800 and support need no higher than 0.6 hours/customer/month, alongside an updated retention assessment. These gates do not establish viability: the base still lacks payback within 24 months. Before a larger commitment, Finance must accept updated downside and peak funding. A competitor price change, channel shift or breached pilot limit withdraws the model’s permitted use until reassessed. The contract changes today’s action from “fund the upside” to “buy the evidence that could change the decision.”

Averages can conceal the operating problem

A small reproducible calculation makes the difference between a static plan and dynamic behavior visible. All inputs and outputs below are synthetic. The private demonstration uses standard Python, fixed random seeds and a first-come, first-served single-server queue; it uses no company records and no LLM-generated customer behavior.

Assume eight arrivals per hour and capacity for ten services per hour. With perfectly regular arrivals and constant six-minute service, there is no waiting. With independent exponential interarrival and service times, the same average load produces a very different queue. The stationary M/M/1 equations give 24 minutes mean waiting and 29.4% of arrivals waiting more than 30 minutes. Utilization of 80% is not a service-level guarantee.

The demonstration ran 24 replications per stochastic configuration, each with 5,000 warm-up arrivals and 50,000 measured arrivals. Simulated mean waiting was 24.01 minutes for the base queue. Increasing service capacity to twelve per hour gave 10.03 minutes, against an analytical ten minutes. Both policies can serve the same long-run arrival rate; the decision concerns delay and its consequences, not simply average throughput.

The approximate 95% Monte Carlo intervals across replication means were 23.47–24.54 and 9.89–10.16 minutes. These intervals describe numerical sampling variation under the assumed model. They are not confidence intervals for a real company’s waiting time, and do not cover missing mechanisms or uncertain parameters.

Make the economics equally explicit. If each wait exceeding 30 minutes creates €15 of incremental cost and extra capacity costs €12 per hour, the analytical reduction in modeled penalties less capacity cost is about €12.49 per hour, or €24,979 over 2,000 operating hours, before model development and maintenance. This is conditional arithmetic, not realized saving or EBITDA. If that penalty is fictional or already counted elsewhere, the financial conclusion fails.

The counterexample matters too. Reducing the service rate from ten to nine raises analytical mean waiting to 53.33 minutes. A model fitted under the original regime may remain numerically correct and become operationally misleading. More Monte Carlo runs cannot repair that domain change. The calculation is useful because its mechanism is transparent and can be checked—not because a synthetic experiment proves an enterprise intervention.

Calibration earns a domain, not permanent trust

Verification asks whether the implementation represents the specified model correctly. Calibration estimates parameters. Validation examines whether the model is adequate for its intended use. Those activities interact, but they are not substitutes. NIST’s credibility research puts verification, validation and uncertainty quantification within the lifecycle rather than at a final presentation gate.

NIST’s October 2026 report makes the investment implication explicit: scale credibility work to model influence and decision consequence. Screening a reversible option and authorizing a safety-critical change should not require the same evidence budget.

Use time-separated holdouts where temporal behavior matters. Compare with a simple baseline. Examine queue distributions and constraint violations, not only average throughput. In the industrial example, compare the relevant physical response with tests in the proposed operating envelope. In the SaaS example, keep new-market assumptions distinct from parameters measured in the existing market. A good fit to existing customers is not validation for a different acquisition channel.

Separate observation error, parameter uncertainty, stochastic variability and model discrepancy. A narrow interval for fitted parameters can coexist with an inadequate mechanism. Brynjarsdóttir and O’Hagan’s work on model discrepancy is a useful warning against confusing calibration with knowledge of reality.

Some practical measures have clear denominators. Source eligibility is decision-critical inputs satisfying their identity, version and freshness rules divided by the inputs requiring those rules; an unresolved critical input can block use even when aggregate coverage is high. Holdout error should compare the selected outcome with observations on a stated period and baseline. Interval coverage is held-out observations inside the stated prediction interval divided by eligible observations, with uncertainty and sample size reported. It is meaningful only where the outcome and interval have that interpretation.

For reproducibility, require identical input, model and solver versions to reproduce the reported result within declared stochastic or numerical tolerance. For decision robustness, count tested plausible assumptions that change the action; do not reinterpret that fraction as a probability without a defensible sampling model. For model maintenance, monitor drift, missing events, revised definitions and time alignment. The responsible owner must be able to withdraw a use, not merely refresh a dashboard.

The economics belong to the decision, not the platform

Simulation can avoid a poor commitment, expose constrained capacity, reduce rework, accelerate design iteration or make a reversible experiment more informative. Those are potential benefits. Realized financial value appears only when the company changes an outcome and can distinguish the effect from its baseline and other changes.

The cost boundary includes integration, identifier reconciliation, data pipelines, model construction, domain specialists, licensing, compute, calibration, validation, monitoring and the management process that consumes the result. A cheap model call can sit inside an expensive decision system. A visually sophisticated twin can cost more than the errors it helps avoid.

Before building, ask what uncertainty is decision-relevant and how much avoidable exposure exists. If maximum avoidable loss is modest, an elaborate platform may be irrational even if technically impressive. With defensible probabilities, expected value of information can inform the spending limit. Without them, use explicit downside bounds and staged evidence budgets rather than inventing an expected-value calculation.

Measure decision lead time from a complete decision brief to an approved action, including model preparation and review. Measure model operating cost per accepted decision, not per generated scenario. Track implemented outcomes against the decision’s baseline, including failure, maintenance and transition costs. For engineering, monitor qualification effort and avoided rework only where a credible comparison exists. For market entry, monitor actual cohort contribution, cash exposure and observed retention rather than celebrating a simulated upside.

These measures connect to the Technology Value Economics Model: cheaper analysis is valuable when it changes company economics, risk or options. More scenarios are not automatically better decisions.

Build one decision capability before expanding the architecture

An illustrative sequence begins with a consequential, repeated decision and an accountable business owner. In the first 30 days, define its alternatives, loss boundary, existing decision cost and evidence gaps. Compare buying information or running a small experiment with building a model. Do not select a technology platform before knowing what decision it must improve.

By around 60 days, a suitable project might reconcile the minimum identifiers and source observations, establish the model boundary and document assumptions. Around 90 days, it might have an executable bounded model, independent checks and a backtest showing where use is unsupported. By 180 days, a team might evaluate scenarios with specialists and run reversible real interventions. These are planning illustrations, not promised implementation times; physical qualification or poor source data can require a different sequence.

The team needs integration and architecture capability, domain expertise, data engineering, modeling, security, Finance and decision authority. AI/model engineering is useful when its contribution earns the additional complexity. The modeling owner and the business outcome owner should be explicit; neither responsibility disappears into a vendor platform.

Buy where a mature solver or domain product fits the problem and its deployment terms. Build the decision-specific mappings, assumptions, validation fixtures and operating contract the vendor cannot supply for the company. Keep model and data portability in the procurement decision, including export rights, solver dependency and the effort needed to reproduce historical runs after an upgrade.

Expand only after observing decision usefulness and lifecycle cost. Another process may need a different model family, data boundary and evidence package. Reuse identity, lineage, run control and authorization where useful; do not assume a successful component twin validates an entire factory, or that one reliable service queue validates a market-entry forecast.

When not to simulate

Do not simulate merely because connected data is available. Straightforward arithmetic may settle the decision. A cheap, safe real experiment may provide better evidence. An unrepeatable strategic choice with unknowable reactions may be better served by explicit scenarios and resilient commitments than a falsely precise prediction.

Stop when critical mechanisms cannot be tested or bounded, data preparation exceeds the affordable decision value, the proposed use lies outside the validity domain, or leadership cannot change its action regardless of the result. A model that cannot affect a decision is an expensive explanation of a commitment already made.

Reject the project when it is being used to avoid ownership. An AI-generated scenario is not a substitute for a product judgment, an engineering approval or a board’s investment decision. Simulation should expose assumptions and consequences, not outsource accountability.