A Digital Twin Is Only as Good as the Decision It Changes.
Designing industrial digital twins around decisions, workflow, and evidence.
“The best digital twin is not the most complete representation of the asset. It is the smallest, reliable representation that improves a valuable operational decision.”
Industrial organisations are often asked how much of a plant they want to replicate in a digital twin. It is usually the wrong first question. A technically detailed representation can reproduce the asset, visualise its condition and run sophisticated calculations without changing a single operating outcome.
The better starting point is the decision. Is the digital twin intended to inform decisions in a mature operation or provide optimisation insights for a new build? What must a design engineer, process technician, or operator understand earlier? What are the trade-off decisions and intervention options available? How much time is available to act? What evidence would justify transferring part (or all) of that decision to software and systems?
The answers to these questions determines the type of digital twin and defines how it is designed. In some instances, a digital twin is valuable during the design phase to inform and validate the physical and process design.
In established operations, the use case for digital twins shifts to simulating and informing process optimisation decisions and practices. Physics, machine learning, and operator experience are not competing answers here. They become different sources of knowledge connected through an operating workflow. Fidelity follows the decision, rather than becoming an objective in its own right.
A Model of the Process is Not the Process.
Physics-based models give industrial teams mechanisms, relationships, and boundaries. Grounded in theory, they can explain why an outcome should occur and help test whether a model remains physically plausible. Yet real plants seldom operate under ideal (or simple) physics-based assumptions, and building accurate models of real operations requires models of rapidly increasing complexity that are impractical to scale.
Even modelling an apparently simple process such as material flowing through a pipe requires decisions, approximations, and assumptions about composition, viscosity, shear history, corrosion, valves, pumps and changing equipment condition. More complex mechanisms, such as the properties of needle-coke electrodes made from variable feedstocks are likely to not even have agreed on equations that can model them 2026 Intelli Dynamics. These examples illustrate model boundaries. They are not evidence that physics-based modelling is ineffective. The governing equations can be correct for specific conditions and still be insufficient for the operational decision due to variation inherent in the process.
Aluminium reduction cells present the same challenge. Thermal balance, magnetic stability, electrical behaviour, bath chemistry, feed practices, cell condition, maintenance history, and operator intervention are all highly interdependent over time. Physics provides essential structure.
Operating data shows how those relationships appear in a specific pot, under current conditions at a particular point in time.
Machine learning (ML) attempts to create a model of reality from the opposite end; rather than being grounded in theory, it forms its representation from real-world data. This allows a level of fidelity that is hard to match with physics-based models as the specifics of an operation as well as operational variabilities are embedded in the data it produces, while theoretical models tend to produce a more generic view of a type of operations. However, ML has its own limitations: ML can learn complex relationships from plant history, but the data reflects the way the operation has been run, which means it could lose accuracy or fail when feedstocks, equipment, practices or operating regimes move beyond the conditions represented in training data. More importantly, these inferred relationships reproduce historical behaviour but do not identify causation. This is a major concern when attempting to move into the prescriptive space as an understanding of causation is critical to action recommendation.
In complex operations, the combination of these dimensions of daily reality matters when a system moves from prediction to prescription, and towards further control automation. A variable associated with an outcome is not necessarily a lever that will change it. Prescriptive advice requires engineering interpretation, operational trials and, where appropriate, physics-based constraints before a relationship can support an intervention. There is no one-size-fits-all approach, so careful consideration of the decisions the digital twin is meant to enable should guide the modelling approach.
Four Sources of Operational Knowledge.
A useful digital twin connects four distinct contributions. Treating one as a substitute for the others in turn weakens the system.
The digital twin is therefore not simply a physics model, a machine-learning model, or a database with a visual interface. It is the architecture through which these forms of knowledge are brought together around an asset, an outcome, and a decision.
Start with the Decision Boundary.
Before selecting a modelling approach, the project should define the boundary of the decision. Six questions expose whether a proposed twin has a credible route to value:
What operational outcome needs to change?
Which decisions materially influence that outcome?
How early must insight arrive for an intervention to remain possible?
What actions are available within that response window?
What are the consequences of a missed event, a false signal or unnecessary intervention?
Who or what is authorised to make the decision?
These questions also clarify the case for change. A technically possible solution may still be a poor investment if the event is immaterial, the response is unavailable, the data is unreliable or the workflow cannot absorb the output. No value is gained if decisions are not made with the output. In other cases, a modest predictive capability with diligent decisions and actions can create substantial value because it widens the response window around safety-critical or costly events.
Build the Minimum Viable Digital Twin.
We propose the minimum viable digital twin as a practical design principle: the smallest representation of an asset that can be tested against a valuable operational decision. It contains enough physical structure, operating history and current context to support that decision reliably. More detail earns its place only when it improves performance, confidence, or action.
This is different from building a comprehensive representation and searching for use cases later. The initial twin should include the variables relevant to the failure mode or performance outcome, enough history to represent changing condition, the required model inputs and outputs, and a pathway for investigation and response. Identification, triage, and prioritisation of the critical parameters are facilitated and accelerated by using machine learning, but it is always critically reviewed, contextualised and validated by process experts. The scope of the initial twin can, and should, expand and evolve as value is validated and new decisions are brought into the system.
The pilot should test more than model accuracy. It should establish whether the signal arrives early enough, whether engineers/operators can interpret it, whether a practical response exists, whether that response changes the outcome and whether the benefit justifies scaling. For rare events, a high accuracy score can conceal poor detection or an unacceptable number of false alarms. The evaluation must reflect the operating decision.
If these factors are met, the last hurdle that the pilot needs to overcome is proving that the system can be operationalised and that there is sufficient operational discipline to act on the findings. The operational change management aspects can be as challenging as the technical modelling aspects.
Validation should progress from retrospective testing to prospective shadow operation and then to a controlled operational pilot. Each stage asks a different question: whether the model can reproduce history, whether it performs on unseen live conditions, and whether people can (and are willing to) use it to improve an outcome.
The Workflow is Part of the Twin.
Many digital initiatives concentrate on the model and treat workflow as change management added near deployment. In operating environments, the workflow is part of the technical design.
The twin must connect the interfaces where decisions often slow down or fail: operations and maintenance, process and laboratory data, production targets, and asset health, model output and engineering judgement, recommended action and decision authority. These interfaces are where information acquires meaning and where value either moves into the operation or stops.
A prediction without an operating pathway is unfinished engineering. A useful system shows where attention is required, provides enough context to investigate the signal, identifies the available response, records the decision, and retains the outcome for learning. Process and systems innovation is therefore as important as model innovation.
This is also what makes Industry 5.0 relevant. Human-centric industrial technology is not achieved by leaving a person somewhere in the loop. It requires deliberate design of how human expertise and machine capability divide work, exchange information and learn together. This emphasis on human agency and learning is consistent with the European Commission's Industry 5.0 framing and the analysis of Saltevo, Kutvonen and Torkkeli (2025).
Professional Practice is Part of the System.
Experienced operators and engineers contribute more than domain knowledge or labelled data. Their expertise is expressed through professional practice: how they recognise weak signals, test competing explanations, apply operating standards, coordinate across teams and determine when an apparent exception requires intervention and what action is appropriate.
Much of this capability sits between formal systems. It appears in shift handovers, conversations between operations and maintenance, the interpretation of laboratory results, and the judgement applied when several individually acceptable conditions combine into an emerging risk. These interfaces can be difficult to capture in a process map, yet they are often where an operation either prevents or experiences failure.
A digital twin should therefore be designed around the practice of operating the asset, not only the physics or visualisation of the asset itself – to integrate with effective processes and shape improvements where required. Experienced practitioners must shape the failure modes, data relationships, decision thresholds, workflows, and escalation rules. Their role continues after deployment because the process, equipment, and professional understanding continue to change.
Encoding experience in software does not mean freezing current practice. It means making valuable knowledge more visible and consistent while preserving the ability of practitioners to question the model, respond to unfamiliar conditions, and improve the system. Deep domain expertise adds meaningful context and interpretation to the outputs from AI and Machine Learning.
Autonomy is a Transfer of Decision Rights.
The progression from predictive analytics to closed-loop control is commonly described as a sequence of technical upgrades. Operationally, it is better understood as a sequence of transferred decision rights as trust and confidence increases.
In idoba's Digital Twin Concept of Operations, the levels below describe a staged pathway. They are not a claim that every process should progress to autonomous control. The appropriate end point depends on the value of the decision, process variability, available evidence and the consequences of error. Goh et al. (2019) similarly position process variability as a central consideration in automation decisions.
Each advancement in the Digital Twin to this end should be earned. It requires evidence that the model performs under changing conditions, data and instrumentation are reliable, operating boundaries are understood, actions are traceable, and the system fails safely. The availability of automation technology is not, by itself, evidence that the operation is ready to transfer authority.
Trust Must be Maintained After Deployment.
A validated model can still lose relevance. Sensors are replaced, laboratory methods change, operating practices evolve, and equipment ages. These changes can alter the relationship between the data, the process, and the outcome even when the software continues to run normally.
Operational governance should therefore define data-quality controls, model and configuration versions, performance monitoring, recalibration or retraining triggers, and an audit trail of recommendations and actions. It should also name who can override, restrict or retire the model. These controls are part of the twin because they determine whether its output remains trustworthy in service.
What This Means in Aluminium.
idoba.predict currently applies these principles at Level 2/3, providing predictive decision support for cathode and sidewall failure risk in aluminium reduction cells. The twin is organised at pot level because investigation and intervention occur at pot level. Operational and laboratory data are brought together over time because neither data source is sufficient on its own. The high-level Concept of Operations describes a pathway that must be validated with each operation, not capability assumed at the outset.
Cathode and sidewall risks are modelled separately because they involve different failure mechanisms, signals, and responses. Aluminium specialists do more than validate the model. They determine which mechanisms matter, how emerging risk appears in practice, what evidence engineers need, and which interventions remain credible under actual operating conditions. Machine-learning models then identify complex relationships across the operation's history within that professional and technical frame.
The output enters an engineering workflow. Teams can view developing risk across the potline, move to an individual pot, review contributing conditions, prediction history, and record the investigation or action. Engineers retain accountability and ownership for process related decisions. The current value lies in extending consistent, failure-mode-specific attention across the potline and creating a wider window for response.
That response window is the connection between prediction and value. Earlier visibility can give the operation more time to protect pot life and stable metal production, coordinate intervention, and reduce exposure to urgent unplanned failure. The twin creates value because the operation receives advance warning and can act on the insight.
The Capability is in the Combination.
Building this kind of decision system requires more than a modelling team. idoba brings together deep domain expertise, advanced data science, full-stack digital technology and collaborative delivery. Domain specialists define the operational mechanism and decision. Data scientists develop and test the analytical approach. Software teams connect the model to reliable data and a usable workflow. Client engineers and operators test whether the system represents the operation and supports action.
This is not about replacing technical expertise. It extends the reach of professional practice while keeping experienced practitioners responsible for interpretation, challenge and action. It also gives organisations a disciplined path from predictive decision support toward prescriptive and, where justified, closed-loop operation.
Five Tests Before Funding a Digital Twin.
A proposed digital twin should have clear answers to five questions before significant investment is committed:
• 01 Decision - What recurring operational decision are we trying to improve?
• 02 Representation - What is the smallest, reliable representation needed to improve it?
• 03 Action - What corrective actions can the operation implement when the twin produces an insight?
• 04 Validation - What evidence will show that it works under real operating conditions?
• 05 Governance - Who retains authority and accountability when the model is uncertain or wrong?
The maturity of a digital twin should be judged by the quality of the decisions it can safely support, and the evidence required before greater authority is transferred to it. The overall value of the digital twin should be judged on the impact of the actions taken as a result of the insights. That is the discipline that connects technical possibility to operational value.
Frequently Asked Questions.
-
An industrial digital twin is a working representation of an asset that connects operating data, models, workflow and decisions over time. It is not a physics model, a machine-learning model or a visual dashboard on its own. It is the architecture that brings these forms of knowledge together around an asset, an outcome and a decision.
-
A minimum viable digital twin is the smallest representation of an asset that can be tested against a valuable operational decision. It contains enough physical structure, operating history and current context to support that decision reliably. More detail is added only when it improves performance, confidence or action.
-
Most fail because they replicate the asset without changing a decision. The event may be immaterial, the response window too short, the data unreliable or the workflow unable to absorb the output. Starting with the decision, the available response and the workflow keeps the twin tied to an operating outcome.
-
Physics-based models provide mechanisms, constraints and boundaries. Machine learning learns complex relationships from an operation's own data and history. Operator expertise supplies context and practical judgement. A digital twin connects all three, so that each covers the limits of the others.
-
Validation should progress from retrospective testing to prospective shadow operation and then to a controlled operational pilot. Tests should cover discrimination, lead time, false-alarm burden, calibration, regime stability, decision impact, outcome value and operational integration, not model accuracy alone.
-
Only when the evidence supports it. Authority should transfer in stages as the model proves reliable under changing conditions, data and instrumentation are dependable, operating boundaries are understood, actions are traceable and the system fails safely. Not every process needs to progress to autonomous control.Item description
Next Step.
If you are assessing a digital twin for aluminium reduction, start by putting the five tests above to your own operation. Book a discovery call with idoba to map the decision, the response window, and the evidence you need, or to see idoba.predict on your data.
Meet the Authors.
Like to hear more from the idoba team?
Subscribe to our emails to receive our content straight to your inbox.
