Digital twins: deciding whether an asset actually needs one
Admin · 22 October 2026
Illustrative image. Photo by Austin Distel on Unsplash. Unsplash License.
An asset owner considering a digital twin should begin with a management problem, not a demonstration. The organisation may need to understand operating conditions, compare interventions or coordinate information across systems. A sophisticated representation can support those aims, but its usefulness depends on the decisions it improves and the information the organisation can maintain. The label alone does not establish a business need or an implementation scope.
For construction clients and facilities leaders, the decision is whether a proposed capability offers a credible improvement over simpler alternatives. That requires a clear use case, dependable data and an accountable operating model. The project should explain how the proposed arrangement will be used after the initial delivery team leaves, including the work and expertise needed to keep it relevant.
Name the decision to be improved
Describe the recurring question the asset team struggles to answer. It could concern a particular operating condition, a change scenario or the relationship between asset information and observed performance. Identify who makes the decision, what information is currently available and what consequence follows from uncertainty. This provides a practical basis for testing whether a digital capability would help.
Be precise about the expected improvement. Faster access to records, better interpretation and evaluation of scenarios are different outcomes. They may require different information and methods. Avoid combining them into a broad aspiration to make the asset smarter. A clear use case allows the team to assess proposals against a recognisable task rather than the breadth of a product’s feature list.
Compare simpler alternatives
Examine whether a better asset register, improved reporting or a focused analytical tool could address the problem. These alternatives may still require process change and data work, but the comparison helps define what additional capability the proposed twin contributes. The aim is not to reject sophistication automatically; it is to understand why it is necessary for the intended decision.
Use common boundaries when comparing options. An elaborate proposal that includes data cleaning and operational support should not be compared with a basic tool whose equivalent work is omitted. Identify the complete operating arrangement and its assumptions. This makes the choice more transparent and helps the client avoid attributing every benefit to the platform itself.
Use purpose and trust as tests
The Gemini Principles, published by the Centre for Digital Built Britain in 2018, offer a foundational discussion of purpose, trust and function for digital twins. They are useful context for asking why a capability exists and whether its information can be relied on. They should not be presented as a complete technical specification for an individual asset.
Translate those broad questions into the proposed use. What must be represented, how current must the information be and what limitation would make the output unsuitable? Ask the relevant specialists to define and assess the requirements. The asset team needs to understand the conditions under which a result is useful, rather than accepting a general assurance that the system mirrors reality.
Assess the data foundation
Identify the sources needed for the use case and their present condition. Some may be well maintained; others may contain gaps, inconsistent identifiers or uncertain ownership. Record those issues and the work required to address them. A new visual interface does not automatically resolve differences in the underlying records or establish which source is authoritative.
Distinguish information available now from information the proposal expects to collect later. Ask who will provide it, how it will be checked and what happens if it remains unavailable. The implementation plan should make these dependencies explicit. Otherwise the organisation may purchase a capability whose intended function depends on data work that nobody has funded or assigned.
Define the human workflow
Explain how the output reaches a person able to act and what they do with it. A signal or scenario result needs interpretation within the organisation’s responsibilities and procedures. Identify where specialist review is required and what decision authority remains with people. Do not assume that a dashboard creates an operational response simply because the information is visible.
Consider a hypothetical commercial estate exploring a system to support plant operating decisions. The team should define the specific decision, the data and assessment needed, and the staff responsible for reviewing the result. A trial could then test that workflow. The example does not establish that automated control is appropriate; any such function requires its own competent assessment and governance.
Plan security and access with specialists
Bring the organisation’s security, technology and relevant operational specialists into the brief. They should assess the proposed connections, information types and responsibilities against actual requirements. A general technology proposal should not be treated as permission to connect systems or expose sensitive asset information. The project needs an approved arrangement suited to its intended use.
Clarify the roles of external providers and the information they can access or alter. Review how access changes when personnel, contracts or responsibilities change. These matters need appropriate technical and commercial advice. The client’s decision paper should identify the material conditions and approvals rather than reducing the issue to a generic security assurance in a supplier brochure.
Test a bounded use case
Define a trial with a clear scope, baseline and acceptance evidence. Include the receiving users and the people maintaining the information. The trial should test whether the capability supports the intended task, not only whether the interface operates. Record the effort needed to prepare data and the support required during use, as well as any apparent benefit.
Keep claims proportionate to the evidence. A successful demonstration on a small, well-prepared sample does not establish performance across every asset or operating condition. Identify what the trial did not test and what would be needed before wider deployment. This gives the decision maker a reasoned next step instead of an extrapolated promise based on a favourable example.
Assign long-term ownership
Identify who owns the capability, who maintains the information and who reviews whether it remains useful. Asset changes and operational practices can alter the basis on which the original model was created. The operating plan should explain how relevant updates are identified and incorporated through controlled processes, with appropriate checks by the responsible people.
Consider supplier changes and the end of the arrangement. Ask how the organisation will retrieve records, preserve context and continue essential work. The appropriate advisers should review the terms, while users test the practical outputs. An exit plan is part of a credible long-term operating model, particularly where the asset may outlast several technology arrangements.
Make an evidence-based commitment
The recommendation should state the use case, expected value, supporting evidence and conditions required for success. Include the work the client must provide and the uncertainties still needing resolution. Separate approval to investigate or pilot from approval for wider implementation. Those are different commitments and can require different evidence.
A digital twin is worthwhile when its defined capability improves an important asset decision through information and processes the organisation can support. The decision should remain open to a simpler solution where that meets the need. What matters is a clear purpose, trustworthy evidence and an accountable route from the output to useful action throughout the capability’s operating life.
Schedule a review of continued usefulness after implementation. Compare the original use case with actual decisions made and note where the system required additional work. If the organisational need changes, reassess the capability rather than maintaining it solely because it has already been purchased. Continued ownership includes deciding when an arrangement should be simplified or retired.
