A water network can have healthy pumps and still fail to deliver enough water.
A data center can have thousands of working servers and still lack the power or cooling to support the workload customers need.
An infrastructure dashboard may show mostly green assets while the service those assets support is under pressure.
This is a gap in how many organizations think about digital twins.
We often begin with the physical object: a pump, a transformer, a building or a pipeline. We collect its geometry, location, operating data and maintenance history. That is valuable.
But the executive question is usually broader:
Can the system deliver its intended function under current conditions?
Answering it requires a digital twin that connects individual assets to dependencies, service capacity, decisions and verified outcomes.
Healthy assets do not guarantee a healthy service
Imagine a city water network serving a residential district.
The reservoir has sufficient water. The treatment plant is operating normally. Two pumps are healthy, and the main valve is open.
On an asset dashboard, everything appears satisfactory.
But a restriction in a connecting pipeline reduces how much water can reach the district. The pumps may still be working within their operating limits, yet customers experience low pressure.
The figures in this example are illustrative. The operational point is familiar: the condition of individual components does not, by itself, tell us what the whole system can deliver.
A conventional asset view might ask:
- Is the pump running?
- When was the valve last maintained?
- What is the reservoir level?
A service view adds:
- How much water can reach the district now?
- Which constraint limits delivery?
- What happens if demand rises?
- What evidence supports the answer?
- What action should the operator take?
Both views are necessary. One explains the components; the other connects them to the result people depend on.
From an asset model to a service model
I see a useful hierarchy emerging for digital twins:
Physical asset → Interface → Dependency → Functional service → Decision → Evidence requirement → Observation → Action → Verified outcome
Consider what each layer contributes.
An asset is a physical component: a pump, pipe, server or transformer.
An interface describes where components connect and what must pass between them. A pump may be healthy, but its connection to a pipeline can still restrict performance.
A dependency describes what relies on what. A treatment plant may depend on electricity, while a district depends on the plant, pumps, pipelines and valves.
A functional service describes the outcome those components collectively provide: water delivery, electricity supply, cargo movement or computing capacity.
The remaining layers bring the model into operations: which decision needs to be made, what evidence is required, what is observed, what action follows and whether the expected result is confirmed.
This hierarchy is not necessarily a fixed sequence in every workflow. An unexpected observation can start the process, and a failed outcome may require the operator to revisit earlier assumptions. Its value is in making those relationships explicit.
The service may span several locations
This approach becomes especially relevant when a service is delivered across geographically separated sites.
Consider an AI service supported by computing infrastructure in Hyderabad, Chennai and Mumbai. Each location has its own power, cooling, servers, storage and operating constraints. Network connections link the sites.
A facility twin can describe each location. But the customer needs an answer that spans all three:
How much workload can the combined system support while meeting its reliability and response-time requirements?
Installed capacity alone cannot answer that. The usable capacity depends on how workloads can be placed, whether power and cooling are available, which sites can take additional demand and whether network performance meets the service requirement.
Adding the capacity of all three sites may overstate what is actually available. For example, spare capacity at one site may not be usable for a workload that depends on data or network performance elsewhere.
This points toward what I call a distributed functional twin: a model of a service delivered by assets and dependencies across multiple locations.
The same idea applies to water networks, electricity systems, logistics corridors and industrial production. The service becomes the organizing question; the physical assets remain the foundation of the answer.
Capacity must be calculated, with its assumptions visible
A service-level view cannot be created simply by placing a new dashboard above existing asset dashboards.
It needs an explicit model of how the system works.
For a water service, that might include:
- Available reservoir supply and treatment capacity.
- Pump operating states and pipeline constraints.
- Valve positions and the connectivity of the network.
- Demand by service area.
- Required pressure and delivery conditions.
The resulting estimate should distinguish installed capacity from currently available capacity and from the capacity that can be delivered while meeting the service requirements.
It should also show its assumptions. Are valve positions current? Is the pipeline restriction measured or inferred? Was the demand estimate updated this morning or last month?
A useful twin should be able to say, in effect:
“The estimated delivery capacity is constrained by this section of pipeline. The estimate depends on a recent pressure reading and an assumed valve position. The valve position has not yet been verified.”
That explanation helps an operator judge whether to act, investigate or obtain better evidence.
Evidence must support the decision
A digital twin can contain extensive data and still be unable to answer a particular operational question with confidence.
A drone survey from yesterday may be recent, but it may not show the area needed to verify a suspected obstruction. A sensor may report a sudden change, but its calibration or communication status may be uncertain. A BIM model may describe the intended installation, while the field condition has changed.
This is why the evidence requirement should follow the decision.
If the decision is whether a pipeline can sustain a specified flow, the team needs evidence relevant to flow, pressure, asset condition and operating configuration. A recent image of the facility may provide context, but it cannot answer that question on its own.
For each critical decision, organizations can define:
- The claim: What does the team need to establish?
- The evidence: Which observations, records or measurements can support it?
- The acceptance conditions: How recent, complete and reliable must that evidence be?
When the evidence is insufficient, the twin should make that visible and help the team identify the next observation. It should not present an unsupported estimate as a settled fact.
Action is not the end of the workflow
Suppose the water operator investigates the restricted pipeline and completes a repair. The maintenance system closes the work order.
Has the service recovered?
Perhaps. But closing the work order tells us that an activity was recorded as complete. It does not establish that the district has regained the required pressure and delivery capacity.
The final step is to compare the result against an agreed acceptance condition. That may involve pressure readings, flow measurements or another suitable observation after the intervention.
The full chain then becomes:
A service constraint was identified → an action was taken → the resulting service was measured → the outcome was accepted or further investigation was triggered.
This creates a stronger basis for operational accountability. It also gives leaders a clearer picture of whether investment and maintenance are improving the service customers actually receive.
A better question for digital twin investments
This shift changes how organizations can judge a digital twin.
Instead of asking only how many assets have been modelled, they can also ask:
- Which critical services can we assess with it?
- Can we see the dependencies that limit those services?
- Do we know whether the supporting evidence is sufficient?
- Can operators trace a recommendation back to its assumptions?
- Can we verify whether an intervention improved the result?
GIS, BIM, IoT, UAVs, remote sensing and AI all have roles in this picture. Each can contribute context, observations, analysis or explanations. Their value depends on how well they support the decision.
A useful digital twin can therefore be understood as a continuously evidenced model of whether a physical system can deliver its intended function.
That is a demanding goal. Evidence will sometimes be missing, models will have limits, and human judgement will remain essential. But making those limits visible is itself part of a trustworthy system.
The opportunity is to connect the digital representation to the service, the decision and the outcome, so that a green asset dashboard can be tested against what the physical system is actually delivering.
