A digital twin may show that a pump is deteriorating, a cooling system is consuming more energy, or a structural element requires inspection.
But it may still be unable to answer the questions that determine whether anything happens next:
- Who is contractually responsible?
- Is the asset still under warranty?
- Which service-level commitment applies?
- Who can authorize the intervention?
- What evidence is required before payment or closure?
This is a major gap in how digital twins are designed.
Most twins are built around physical dependencies. They connect assets, spaces, systems, sensors, operating conditions, and maintenance histories. This helps teams understand how a change in one part of an asset affects another.
Yet infrastructure does not operate through physical relationships alone. It also depends on contracts, suppliers, warranties, permits, budgets, service agreements, insurance conditions, and decision rights.
If these commercial dependencies remain outside the twin, the organization may detect a problem quickly but still respond slowly.
A physical problem often becomes a commercial workflow
Consider a building chiller showing signs of declining performance.
The operational twin may identify rising energy use, reduced cooling output, abnormal vibration, and a likely failure window. Technically, the diagnosis may be sound.
The next action, however, depends on a different set of relationships.
The facilities team must know whether the chiller is covered by the original equipment warranty, an annual maintenance contract, or a performance-based energy agreement. They must establish which party is required to act, the response time committed in the contract, the evidence needed to raise a claim, and the person authorized to approve work outside the agreed scope.
These are not administrative details added after the technical analysis. They are part of the intervention pathway.
The same issue appears across infrastructure:
- A road defect may fall under a contractor’s defect-liability period.
- A solar plant underperformance event may trigger an equipment warranty or an output guarantee.
- A water-network failure may involve an operator, an equipment vendor, a civil contractor, and a local authority.
- A construction delay may be linked to design approval, material supply, access rights, or payment certification rather than site productivity alone.
The physical condition identifies what is happening. The commercial context determines who must respond, under what authority, within what time, and at whose cost.
Commercial context changes the meaning of operational data
A sensor reading is not commercially meaningful by itself.
The same equipment condition can lead to different actions depending on the active obligation. A temperature excursion might require immediate vendor intervention under one service agreement, internal review under another, or no contractual action if the relevant coverage has expired.
This means that an operational threshold should not be interpreted only against an engineering rule. It may also need to be evaluated against:
- contractual performance levels;
- warranty terms;
- maintenance responsibilities;
- safety and regulatory obligations;
- insurance requirements;
- approved budgets;
- concession or lease conditions;
- supplier response commitments.
Without this context, the twin can recommend an action that is technically correct but commercially incomplete.
It may send an internal maintenance team to repair an asset that should have been handled by a vendor. It may miss the evidence window for a warranty claim. It may approve work without the required authority. It may close an incident without confirming that the contracted performance level was restored.
The cost is not limited to inefficient maintenance. It can include duplicated work, delayed recovery, rejected claims, contract disputes, unplanned expenditure, and weak accountability.
What a commercial-dependency layer should contain
The objective is not to load complete legal documents into a 3D model. It is to connect each operationally important asset, system, or service to the commercial facts that affect decisions.
A practical commercial-dependency layer should map five areas.
1. Active obligations
What commitments currently apply to the asset or service?
These may include uptime targets, inspection intervals, response times, performance guarantees, handover conditions, warranty coverage, or reporting duties. The twin must also know when each obligation starts, changes, expires, or transfers to another party.
2. Responsible and authorized parties
Responsibility and authority are not the same.
One party may be required to investigate, another may authorize expenditure, and a third may certify completion. The twin should distinguish who is obligated to act, who may approve the action, and who verifies the outcome.
3. Service continuity dependencies
An asset may depend on external services that are easy to overlook: software licenses, cloud hosting, communications networks, specialist maintenance, calibration, data feeds, or spare-parts agreements.
A technically healthy asset can lose operational capability when one of these commercial services expires or fails.
4. Financial exposure
The twin should show how an event may affect cost, revenue, penalties, claims, or lifecycle value.
This does not require the twin to become an accounting system. It requires a clear connection between asset condition and financial consequence, for example, whether delayed action could trigger liquidated damages, increased energy cost, lost production, or an avoidable capital replacement.
5. Outcome evidence
Closing a work order is not the same as proving that the intervention worked.
The twin should retain the evidence that links the detected condition, applicable obligation, approved action, completed work, and restored performance. This creates a traceable chain from problem to result.
From asset twin to dependency twin
The architecture must therefore extend beyond BIM, GIS, IoT, and maintenance data.
BIM can define equipment, spaces, and system relationships. GIS can connect assets to networks, parcels, service areas, and external risks. IoT can provide live condition and performance data. Enterprise systems can contribute contracts, procurement records, work orders, payments, warranties, and organizational roles.
The twin’s role is not to replace these systems. It is to preserve the operational relationship among them.
For each significant event, the organization should be able to follow a decision chain:
Physical condition → active obligation → responsible party → authorized action → financial consequence → verified outcome
This chain turns disconnected information into an accountable workflow.
It also reveals dependencies before they become failures. An expiring maintenance agreement, unsupported software component, unavailable specialist supplier, or approaching warranty deadline can be treated as an operational risk not discovered only after an incident.
Start with decisions, not documents
Organizations do not need to model every clause and commercial relationship at once.
A focused implementation can begin with one asset class, one high-cost service, or one recurring operational failure. The team can then identify the few commercial facts that repeatedly affect action.
A useful starting assessment asks:
- Which operational alerts frequently become delayed interventions?
- Which assets have complex warranty or vendor responsibilities?
- Where are claims, approvals, or handoffs commonly disputed?
- Which services could stop when a license, contract, or supplier arrangement ends?
- What evidence is currently missing when performance is reviewed?
These questions help define a manageable dependency model tied to measurable outcomes.
Governance is essential. Contract data may be sensitive. Responsibilities change over time. Amendments can override earlier terms. The twin must preserve effective dates, source references, access controls, approvals, and version history. AI can help extract and connect commercial information, but accountable teams must validate the obligations and authority rules that influence action.
The next digital twin must explain what keeps the asset operational
The value of a digital twin is often measured by how accurately it represents the physical environment.
That remains important, but it is no longer sufficient.
An asset continues to perform because multiple physical, digital, organizational, and commercial dependencies remain intact. If the twin models only the asset, it sees only part of the operating system.
The next generation of digital twins should not stop at showing that something is wrong. It should help establish what obligation applies, who must respond, what action is authorized, what value is at risk, and whether the intervention restored the expected result.
That is the shift from a representation of assets to a system of operational accountability.