The Digital Twin Gap: When the Dashboard Outruns the Data

From my point of view, the Digital Twin conversation is starting to feel familiar.

The industry moved from CAD to BIM. CAD helped document the asset. BIM added structured information, coordination, and a shared digital representation to support decisions. Now Digital Twin is being positioned as the next step.

The concept has value.

The hype is the risk.

A Digital Twin should not be treated as complete simply because a dashboard exists, a model is connected to a data feed, or a presentation says “next-generation.” In my view, a useful Digital Twin needs a defined purpose, trusted data, maintained connections, system ownership, and a clear decision it is meant to support.

Without that foundation, it can become a magic mirror: impressive to look at, expensive to build, and unclear in what it actually solves.

Where the idea came from

The modern Digital Twin concept is commonly associated with Michael Grieves’ product lifecycle management work in the early 2000s. Later sources credit John Vickers of NASA with helping establish the term “Digital Twin.” [1]

NASA and the U.S. Air Force helped bring the concept into a serious engineering context. A 2012 paper by Edward Glaessgen and David Stargel described Digital Twin thinking in aerospace around high-fidelity simulation, vehicle health management, maintenance history, and historical fleet information. [2]

That origin matters.

The concept did not begin as a marketing dashboard. It was connected to complex physical systems, lifecycle performance, simulation, monitoring, maintenance, risk, and decision support.

That is very different from treating Digital Twin as a software label.

What formal sources point toward

ISO/IEC 30173:2023 establishes terminology and concepts for Digital Twin. In plain language, it frames a Digital Twin around a digital representation of a target entity, connected through data so the digital and physical states can remain aligned at an appropriate rate. [3]

The Digital Twin Consortium also emphasizes that a Digital Twin is data-driven, represents real-world entities or processes, and depends on synchronization at an appropriate frequency and fidelity. [4]

The Gemini Principles, developed for the UK National Digital Twin programme, organize Digital Twin thinking around purpose, trust, and function. That is a useful signal for the built environment because it pushes the discussion away from technology alone and toward value, confidence, and use. [5]

Different sources use different wording, but the pattern is consistent.

A Digital Twin is not just a model.

It is not just BIM.

It is not just sensors.

It is not just a dashboard.

It is not just a vendor platform.

It depends on connection, synchronization, data quality, operational purpose, governance, and trust.

The BIM problem before the Digital Twin problem

This is where I think the built environment needs to be careful.

ISO 19650 already frames BIM as information management across the built asset lifecycle. It connects information production, information requirements, information containers, common data environment workflow, project information models, asset information models, and the use of information to support decisions. [6]

That is already a serious information-management requirement.

Before an organization claims it is ready for a Digital Twin, it should ask whether it has already mastered the BIM information layer.

Can the organization trust its asset data?

Are model objects structured consistently?

Are spaces, systems, and components classified properly?

Are information requirements defined?

Are exchanges validated?

Is the asset information model maintained after handover?

Are legacy systems mapped?

Are data owners identified?

Are operational workflows connected to the information?

If the answer is unclear, the Digital Twin may not be the next step.

It could be a new label placed on unresolved BIM, handover, and information-management problems.

The slide-deck problem

The sales narrative can sometimes move faster than the operating model behind it.

Digital Twin presentations often show the outcome: the dashboard, the 3D view, the live data, the colour-coded asset, the executive summary, the predictive insight, and the promise of better decisions.

Those outcomes can be real.

But they are not automatic.

A Digital Twin depends on the infrastructure beneath it: legacy data, asset registers, naming standards, sensors, integrations, metadata, system ownership, cybersecurity, validation, operational workflows, and long-term funding.

Without that foundation, the organization can buy the presentation before it understands the work.

At the executive level, the Digital Twin story can sound like an operational shortcut. In practice, the value depends on less visible work: data quality, system integration, ownership, validation, funding, and ongoing maintenance.

That is where expectations can become disconnected.

The executive team hears “Digital Twin” and expects smarter operations.

The project team hears “Digital Twin” and inherits another data requirement.

The BIM team hears “Digital Twin” and is expected to clean up years of inconsistent information.

The operations team hears “Digital Twin” and receives another system to maintain.

The IT team hears “Digital Twin” and is asked to connect platforms that were not originally designed to work together.

That is where the Digital Twin can become another layer of complexity instead of a clearer operational tool.

The realistic timeline and cost problem

From my point of view, one of the largest gaps in the Digital Twin conversation is the lack of realism around timeline and cost.

There is no universal timeline.

There is no universal cost.

A Digital Twin can involve BIM, GIS, IoT sensors, building automation systems, CMMS or EAM platforms, asset registers, document systems, APIs, data lakes, semantic models, simulation tools, analytics, visualization, cybersecurity, governance, training, and long-term support.

That is not one technology.

It is an operating model.

The real timeline depends on the use case, the condition of existing data, the number of systems involved, the level of synchronization required, the security requirements, and the organization’s ability to maintain the twin after implementation.

Some guidance treats Digital Twin implementation as a multi-year investment programme, not a quick software rollout. Other public-sector guidance frames the business case through staged decision points before implementation: strategic justification, options analysis, full business case, implementation, monitoring, evaluation, and feedback. [7]

That is the right level of seriousness.

A realistic path should probably start smaller.

One asset class.

One system.

One building.

One operational question.

One data connection.

One measurable outcome.

Then expand when value is proven.

Trying to build an enterprise Digital Twin before the organization understands its own information environment can turn the Digital Twin into another transformation programme without a clear return.

The cost is also not only the software.

The cost includes data cleanup, model preparation, asset tagging, system mapping, sensor deployment, integration, cybersecurity, change management, training, maintenance, support, governance, and the people required to keep the twin current.

If those costs are not planned, the Digital Twin becomes another unfunded expectation pushed onto BIM teams, IT, operations, asset managers, and project delivery teams.

That is where hype turns into frustration.

Is it just sensors?

A Digital Twin is not just sensors.

Sensors can be part of the solution, but they are not the solution by themselves.

A sensor can tell you that something changed. It does not automatically tell you whether the asset data is correct, whether the equipment is mapped to the right system, whether the operational workflow is ready, whether the model is maintained, or whether anyone is using the information to make a better decision.

The value comes from the connection between the physical asset, the data, the model, the operational process, and the decision being supported.

Without that connection, sensors can become another stream of unmanaged data.

More data does not automatically mean more intelligence.

Sometimes it just means more noise.

The legacy data problem

A Digital Twin is only as good as the data beneath it.

If the legacy asset register is incomplete, the twin inherits that weakness.

If equipment naming is inconsistent, the twin inherits that inconsistency.

If spaces, systems, and components are not mapped correctly, the twin becomes difficult to trust.

If maintenance records live in one system, drawings in another, BIM models in another, commissioning records in another, and inspections in another, the Digital Twin becomes an integration problem before it becomes an operational tool.

This is not only a technology problem.

It is an information-management problem.

It is also a business transformation problem.

Where are the lessons learned?

This is another area where I think the industry should be more careful.

Many Digital Twin presentations show the final state. They rarely spend the same amount of time showing what happened underneath.

What data was missing?

What legacy systems were difficult to connect?

What did the integration actually cost?

How long did the cleanup take?

Which use cases failed?

Which sensors were not useful?

Which workflows were abandoned?

Who maintained the twin after the pilot?

What was the actual return?

What did the organization stop doing because the twin made it unnecessary?

These questions should be part of the conversation before the next organization buys the same vision.

The West Cambridge Digital Twin lessons-learned work is useful because it shows that even a focused campus-scale Digital Twin involved sensor data architecture, privacy considerations, event processing, structured data formats, and visualization. That is very different from simply connecting a model to sensors and calling it finished. [8]

A real Digital Twin strategy should include lessons learned from past use cases, not only future-state diagrams.

Otherwise, each organization can end up starting the same journey again, with the same assumptions, the same data gaps, and the same surprise when the dashboard is easier to buy than the information is to trust.

What the standards and guidance imply

NIST has identified Digital Twin standardization as important because fragmented implementation can lead to higher development costs, slower deployment, and interoperability barriers. [9]

ISO/IEC 30173 helps formalize Digital Twin terminology and concepts, including system context, lifecycle process, functional views, and stakeholders. [3]

The Gemini Principles emphasize purpose, trust, and function. For the built environment, those themes matter because a Digital Twin should create value, be trusted, and function effectively within the real systems and people using it. [5]

The common message is not that Digital Twins are bad.

The common message is that Digital Twins require structure.

They require purpose.

They require governance.

They require interoperability.

They require maintained data.

They require an operating model.

A practical starting point

From my point of view, the Digital Twin conversation should start with a use case, not a platform.

A practical starting point could be:

Define one operational problem.

Confirm the data source.

Confirm the system owner.

Define the update frequency.

Define the required level of fidelity.

Validate the information.

Measure one outcome.

Capture lessons learned.

Then expand.

That approach does not slow innovation.

It protects it.

It gives the Digital Twin a better chance of becoming useful instead of becoming another expensive technology label.

The tighter test

A practical test is simple.

If the Digital Twin cannot improve a decision, reduce risk, support operations, improve maintenance, validate performance, or create measurable value, then the organization should question whether it needs a Digital Twin at all.

It may need better BIM.

It may need a cleaner asset register.

It may need better handover requirements.

It may need system mapping.

It may need better information governance.

It may need a scoped operational dashboard.

It may need one well-maintained data connection before it needs a “next-generation” Digital Twin.

Digital Twin is not the problem.

The hype is the problem.

A real Digital Twin is not a magic button. It is a maintained information system connected to a physical or operational reality for a defined purpose.

Without that purpose, it is not transformation.

It is another layer of technology language sitting on top of unresolved data problems.

Reference note

This article reflects my own interpretation of publicly available Digital Twin concepts, standards, and guidance. It is not a reproduction of any standard, vendor material, proprietary implementation, or third-party framework. Formal definitions and origin references are credited to their respective sources, including ISO/IEC, the Digital Twin Consortium, NASA, Michael Grieves, John Vickers, NIST, the Gemini Principles, and related public guidance.

No diagrams, tables, definitions, or proprietary implementation details from the referenced sources have been reproduced.

References

[1] Michael Grieves, Digital Twin / product lifecycle management concept history; John Vickers of NASA is commonly credited in later sources with helping establish the term “Digital Twin.”

[2] Edward Glaessgen and David Stargel, NASA, “The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles,” 2012.

---

[3] ISO/IEC 30173:2023, Digital Twin — Concepts and terminology.

[4] Digital Twin Consortium, Definition of a Digital Twin.

[5] Centre for Digital Built Britain, The Gemini Principles.

[6] ISO 19650-1:2018, Organization and digitization of information about buildings and civil engineering works — Information management using building information modelling — Concepts and principles.

[7] Team Defence Information, Digital Twin Implementation Roadmap and Development Framework.

[8] West Cambridge Digital Twin lessons-learned work.

[9] NIST, Digital Twin Standardization.