Before You Build a Digital Twin: Four Boundaries a Manufacturing Decision Needs

The problem: a broad concept with no agreed boundary

NIST describes a digital twin as a digital representation of a physical element, created by using IoT and sensor data. It monitors physical operations, controls the physical element, tests what-if scenarios, predicts the future behavior of the physical element, and supports decision-making. That range is exactly what makes scoping difficult. NIST also notes challenges, especially among small and medium-sized enterprises, because definitions vary, terminology is inconsistent, and there are no standardized procedures for creating digital twin applications.

One definition helps narrow the field. A manufacturing implementation paper adopts ISO's definition: a fit-for-purpose digital representation of an observable manufacturing element, synchronized with that element. Two ideas in that sentence do the work. "Fit-for-purpose" ties the twin to a decision. "Synchronization" means the twin only counts if it stays connected to the physical thing it represents. A model built once from last quarter's data and never updated is a simulation, not a twin in this sense.

For a business leader, skipping this scoping raises questions worth testing in your own environment. Which operating records would need reconciliation for your proposed digital twin, which production or fulfillment processes would rely on its available data, and who would decide what to do if the twin and the plant records disagree? Those are risks to test, not findings from the sources here.

Constraints: where the facts originate and who owns them

NIST's standards work lays out a layered structure that helps locate ownership. The ISO 23247 standard describes a framework composed of four domains represented by four application layers. The lowest layer holds the manufacturing elements the twin represents, such as devices, machines, materials, personnel, and products. Above it sits a layer that collects data from the manufacturing elements and includes control interfaces. A third layer models and synchronizes the elements so the twin can offer services such as monitoring, simulation, analysis, and prediction. At the top is a user domain of people, devices, or other systems that use those services.

That structure is a useful ownership checklist, because each layer raises a different question for your operation:

• Source of the facts. Which sensors, machine data, or inspection results feed the twin, and who maintains them?
• Crossing the boundary. How does data move from the shop floor to the model? One NIST case study used the MTConnect standard and MQTT messaging to support integration of digital twin components.
• Consumption. Which person or system acts on what the twin produces?

Systems of record matter here. A twin should be designed to read from, and write back to, a record with a named owner, rather than quietly becoming a competing version of the truth. Controls engineering and equipment commissioning sit outside the information-systems scope discussed here.

One more constraint is cost. NIST researchers observe that digital twin implementations are often costly because they may require solution providers to develop and maintain the twin for the client. Budget for ongoing support, not only the build.

Approaches: match the pattern to the decision

NIST's three worked use cases show that "digital twin" covers quite different jobs. A machine health twin uses process and equipment data to monitor, troubleshoot, diagnose, and predict faults and failures. The same document also explores a scheduling and routing twin and a virtual commissioning twin. The risk is treating these as one product.

A useful way to sort your own situation is by what the twin is allowed to do:

1. Descriptive or monitoring. Show current state so people can see what is happening.
2. Simulation. Test what-if scenarios before committing. NIST researchers note that developing a twin for a manufacturing system is often carried out using simulation tools, and that these tools usually lack the interfaces needed to receive data directly from the physical system. Connecting the model to live data is therefore a distinct piece of work to plan for.
3. Prediction and optimization. Recommend an action, such as adjusting a schedule when machine conditions change.
4. Control. Send commands back to equipment. A machine health twin can deliver control commands to control the equipment. This is the highest-consequence tier, and it warrants the strictest authority and validation rules. Our recommendation is that decision authority at this tier rest with the people accountable for the equipment, not with a data or software team.

Then compare each tier against simpler options. Extending an existing system, building a targeted integration, adding a report or permissioned portal, or making no platform change at all may answer the decision at lower cost. A twin earns its place when the decision depends on a model that needs both live state and the ability to test alternatives. The sources here do not rank these approaches against each other, so that comparison has to be made against your own data, volumes, and risk.

Tradeoffs: what each choice costs you

The retained evidence points to several tradeoffs worth naming before a commitment.

Integration versus modeling effort. NIST work on additive manufacturing notes that implementing a twin involves integrating multiple systems across different platforms, which creates interoperability issues. Plan integration capacity alongside the modeling effort, because the two compete for the same people.

Accuracy versus computation. The same paper describes using surrogate models, which are inexpensive but less accurate, to reduce computational effort. A faster model that is less accurate may suit monitoring and be wrong for a control decision, so match the model's fidelity to what the decision can tolerate.

Data quality and gaps. NIST's supply chain traceability guidance offers a transferable principle. A sensor that goes offline can be recorded as an explicit unknown rather than having the missing data interpolated, which lets the reviewer apply their own risk thresholds. A twin that silently fills gaps can look authoritative while being wrong.

Disclosure and permissions. The same guidance describes bounded disclosures, sharing only the specific data necessary to satisfy a requirement rather than the underlying intellectual property. If a twin ever spans a supplier or customer boundary, decide in advance what crosses it.

Evidence of maturity. NIST researchers observe that practical implementations of digital twins have not caught up with the increasing literature. Treat vendor claims of broad, proven results with caution until you see an implementation like yours.

Next steps: define four boundaries first

Before funding a build, write down these four items in plain language and have the accountable people sign off.

• Model boundary. Which physical asset or process is represented, and what decision is the model fit for?
• State and event boundary. What state is held, which events update it, and how current must it be?
• Ownership boundary. Which system of record owns each fact, who stewards it, and who is accountable when the twin and reality disagree?
• Validation boundary. How will you show the model is right, notice when it drifts, and state its uncertainty? Who has authority to act on its output, and who must approve before it affects production?

If you cannot name an owner and a validation method for a boundary, treat that as a finding to resolve before building, not a formality to defer.

For the executive reader: a short test

Use these questions in your next planning conversation:

• What specific decision gets better, and what does that decision cost today when it goes wrong?
• Could a report, a targeted integration, or a simulation run on exported data answer it?
• Which record owns the underlying facts, and who is accountable for their quality?
• If the twin recommends an action, who may approve it, and what happens when the data is missing?
• What is the ongoing support cost, and who carries it?

A clear answer to the first two questions can help decide whether a twin is warranted at all. If the answers point to a real gap between what your current systems provide and what the decision needs, a structured assessment of data, integration, and ownership is the sensible next move before choosing any platform.