A factory twin shows a pump running hot. Its prediction service expects a bearing failure within eight hours, and the interface offers to reduce the pump speed. One button now separates a useful model from a control system.
That button changes the product. A twin that displays state can be wrong without moving machinery. Recommendations from the twin can influence an operator. Direct commands can change production, safety, warranty exposure, and accountability in seconds.
Every digital-twin product therefore needs an authority boundary: an explicit line that states which decisions the twin may make, which actions require approval, and which actions remain outside the product.
Synchronization is a product promise
The Digital Twin Consortium defines a twin around a virtual representation and synchronized interaction at a specified frequency and fidelity. Those two qualifiers matter. A model updated every minute is not current enough for every decision, and a high-fidelity geometry model may still have poor operational data.
The interface should expose three facts beside any consequential recommendation: when the underlying state was observed, what sources contributed to it, and which values were estimated. A green pump icon built from a ten-minute-old sensor reading is not current state. It is a historical claim wearing a current-state color.
Freshness also varies by property. Valve position may arrive every second while maintenance status changes once a day. The product should calculate decision readiness from the inputs a decision actually needs, not from the newest timestamp anywhere in the graph.
Use an authority ladder
Cloud platforms make twins flexible. Azure Digital Twins can combine device and business-system data, process events, query a live graph, and route information into custom applications. AWS IoT TwinMaker joins models, time-series data, alarms, video, and visual scenes. The platforms provide building blocks. They do not choose the safe operating authority for a particular product.
Make that authority visible as a ladder:
- Observe. Display measured and derived state.
- Simulate. Estimate future state without affecting the physical system.
- Recommend. Propose an action and show its expected consequence.
- Approve. Prepare a command for an authorized person to confirm.
- Act. Issue a bounded command automatically.
Features should climb one rung at a time. Better prediction accuracy does not automatically justify direct control. The evidence needed to recommend a speed reduction is weaker than the evidence needed to send it.
This ladder should apply per action, not per twin. A building twin might adjust lighting automatically, request approval before changing ventilation, and leave fire-suppression equipment outside its authority. One product can carry several authority boundaries at once.
Put a control envelope around action
Direct action needs more than a permission bit. Define a control envelope for every command: allowed assets, parameter range, operating conditions, duration, rate limit, and automatic reversal condition.
Consider a cooling system. The twin may lower a setpoint by two degrees only when occupancy is known, the compressor is healthy, energy price is above a threshold, and the previous change has completed. If any required input is stale or contradictory, the action falls back to recommendation.
The fallback is part of the product behavior. A degraded twin should lose authority predictably instead of continuing with weaker evidence. Read-only mode, approval mode, and local manual control need clear transitions.
AWS warns that TwinMaker data should be evaluated for accuracy and should not replace human monitoring for safety assessment of physical systems. That limitation is useful product guidance even outside hazardous environments. Visualization, inference, and control carry different consequences.
Keep the action receipt
Every proposed or executed action should leave a receipt containing the state snapshot, model or rule version, recommendation, approver, command, device acknowledgment, and observed result. The receipt connects a decision in the twin to a change in the real system.
It also makes authority reviewable. Teams can see which recommendations operators reject, which approved commands fail, and where automatic actions leave the expected control envelope. Without that record, the twin may improve its predictions while the operational product stays opaque.
This extends the principle that physical AI needs an escalation contract. Escalation decides when software hands a situation to a person. The authority boundary decides how far the software may go before that handoff.
A digital twin earns more authority through evidence, not visual realism. Start by making state legible. Add predictions with their assumptions. Then promote individual actions only when their limits, fallback, and receipt are ready.
Comments
Comments are powered by GitHub Discussions through Giscus.