---
title: "Buying a Digital Twin: What Does Its Current View Actually Describe?"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/operational-digital-twin-identity-time-relationships"
last-updated: "2026-10-20"
---

# Buying a Digital Twin: What Does Its Current View Actually Describe?

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Evaluate a proposed digital twin against an operational question about identified physical assets at a stated time. Its answer needs to connect each value to the asset it describes, the time of observation and the relationship applicable then. A current screen or recently processed update can leave those connections unresolved. Compare the demonstrated answer and its unanswered parts before buying a maintained representation.

## Start with the question the representation must answer

Suppose a buyer wants to ask at noon: which observations describe racks A and B, and do they support a comparison of their conditions now? A detailed rack image can help locate the equipment. Answering the question additionally requires a connection from each observation to the intended physical object and the relevant time.

An as-built model can provide a valuable record of an installation at a documented issue. A maintained operational representation takes on a continuing problem: values and relationships may change after that issue. A sensor can remain the same identified object while the rack it describes changes.

For the intended user's representative question, specify the assets and time. Follow each returned value back to its observation and applicable relationship. Exposing a missing observation is more useful than silently substituting another asset's data.

## Why NIST puts relationships beside building digitization

NIST's Building Digitization and Semantic Interoperability programme identifies labor-intensive mapping between building data sources and application needs as a barrier. Its page, updated February 19, 2026, describes the need for synchronized representations of physical buildings and their systems. The technical idea includes machine-readable descriptions of components, their relationships and associated data points across design and operation.

Its research plan includes developing and assessing a building digital-twin framework to improve transparency for buyers. The programme remains ongoing. These are research aims, rather than a completed procurement standard or proof that a particular purchase delivers the anticipated benefits.

For this buying decision, the useful implication is specific: recognizable geometry leaves the meaning of a connected value to be established. Knowing which object a value concerns, and under which relationship, is part of making it useful.

References: [DT-NIST](https://www.nist.gov/programs-projects/building-digitization-and-semantic-interoperability)

## An assigned twin identity leaves physical correspondence to establish

Azure Digital Twins offers a concrete product example. Microsoft's graph documentation, updated January 27, 2025, describes twins as custom-model instances connected by relationships. Its JSON distinguishes the user-provided $dtId from the model ID in $metadata.$model. A relationship identifies source and target twins and its relationship name.

Those fields describe a proposed sensor-rack connection. They leave its physical correspondence to establish: does S1 identify the intended sensor, and did it concern this rack when the observation was made? A permitted relationship or familiar label does not supply that evidence. This is editorial reasoning about assigned records, rather than a documented Azure defect.

Follow the provider's answer to that correspondence. If the originating sensor is unresolved, naming a rack cannot repair it. If the sensor identity is established but the applicable rack association is wrong, the value is still attributed to the wrong asset.

References: [DT-AZ-GRAPH](https://learn.microsoft.com/en-us/azure/digital-twins/concepts-twins-graph)

## Recently processed does not mean recently observed

Microsoft's Manage digital twins documentation, updated March 4, 2025, distinguishes property lastUpdateTime, when Azure processed the update message, from optional writable sourceTime, representing the real-world observation time. It identifies 2022-05-31 as the minimum stable REST API version supporting sourceTime.

The same documentation describes a consequential case: after both value and sourceTime have been updated, a subsequent update of only the value leaves the earlier sourceTime in place. A populated timestamp therefore cannot automatically be treated as the observation time of the latest stored value. The provider needs an evidential basis for interpreting that value and timestamp together.

Processing recency concerns message handling; observation recency concerns the described physical event. Neither timestamp independently establishes a fresh physical observation. A proposal using current or live needs to explain which meaning it supports.

References: [DT-AZ-TIME](https://learn.microsoft.com/en-us/azure/digital-twins/how-to-manage-twin#update-a-propertys-sourcetime)

## Two racks, one sensor and a reassignment at 11:30

Fictional example DT-OP01 supplies exactly two racks, A and B, one sensor S1 and two event records. All times use one stipulated common UTC reference on the same invented day, with no clock drift modeled. The declared applicable relationship associates S1 with A before 11:30 and with B from 11:30 onward. The graphical model, however, still links S1 to A. The declared association supplies attribution for this example; a single sensor reading does not establish a whole rack's temperature.

Event E1 contains an invented temperature of 31 °C, observed at 11:20:00 and processed at 11:59:50. Event E2 contains 29 °C, observed at 11:59:30 and processed at 11:59:55. The question is asked at 12:00:00. No other observation is supplied, including no later observation of A. The temperatures are teaching values, not equipment limits or recommendations. No measurement, movement, model execution or product test occurred. The two events and time-qualified association are supplied inputs to this reasoning; they do not imply that Azure automatically retains or reconstructs historical relationships.

At noon, E1's observation is forty minutes old: 12:00:00 minus 11:20:00. Its processing is only ten seconds old: 12:00:00 minus 11:59:50. Calling E1 a ten-second-old measurement would replace its observation time with a different event.

E2's observation is thirty seconds old, while its processing is five seconds old. That supplies a much more recent observation than E1, but recency alone does not establish which rack it describes. The association applicable at 11:59:30 still matters.

## Both the old relationship and a history-wide replacement can mislead

The stale graphical link would associate S1's fresh E2 value with A. Under the declared relationship, E2 instead concerns B: it was observed after the 11:30 reassignment. Attaching it to A gives a recent value the wrong physical meaning. Making the value arrive sooner would not correct that attribution.

Now suppose the current relationship is corrected to B, but the reader applies that relationship to every historical event. E1 would then be attributed to B too. That is also wrong under the example's inputs: at E1's observation time of 11:20, S1 was associated with A. Fixing the present link does not make it a valid interpretation of the past.

The defensible account at noon is therefore specific. The latest supplied observation associated with A is E1, 31 °C at 11:20, forty minutes earlier. The latest supplied observation associated with B is E2, 29 °C at 11:59:30, thirty seconds earlier. No observation of A after 11:20 is supplied, and neither rack has an observation at exactly noon. Whether either observation is recent enough for an actual use requires that use's criteria; the example supplies no universal freshness threshold.

The arithmetic mean of the two values is (31 + 29) / 2 = 30 °C. It describes the mean of two supplied readings from one sensor at different times and rack associations. It is not a simultaneous two-rack mean, and it establishes no thermal condition at noon. The arithmetic is correct while the proposed interpretation is unsupported.

The unanswered part of the original question must survive: the supplied evidence does not establish a contemporaneous comparison of A and B. Missing evidence for A is neither a zero reading nor an observed equipment failure.

## Compare offers by the answer they can substantiate

Use DT-OP01 as a representative reasoning case for the proposed provider. An offer returning the latest sensor value beside its current rack label could display 29 °C at A while the old link remains. Correcting the label to B improves that current association, but still leaves open whether earlier readings will be interpreted using their applicable relationships. A visually convincing demonstration can therefore leave the purchase question unanswered.

A more useful return explains each observation's physical correspondence, time basis and applicable rack association, and preserves A's missing later observation. It separates the current represented relationship from the relationship used to interpret each earlier event. Ask the provider to show that distinction in the intended product and delivered scope; this article's arithmetic is no demonstration that a product implements it.

The comparison also makes maintenance concrete. If an association changes after handoff, what in the offered service keeps later answers interpretable without rewriting earlier ones? If a value changes while its observation metadata remains older, what does the returned answer establish and what does it leave unresolved? These are consequences of the two failure modes, rather than a request for an undirected list of fields.

A periodic geometric reissue can be useful when the recipient needs an updated physical record. A purchase intended to support the operational question above needs evidence that reaches the observation and relationship interpretation as well. Compare the actual returned scope and its remaining unknowns before treating both offers as equivalent.

## Keep the physical planning contribution within its scope

A physical planning or handoff package can supply agreed equipment identities, locations, connection records and document revisions as inputs to the appointed operational team. The related physical-handoff guide explains that record boundary. Those inputs do not themselves establish continuing sensor correspondence or maintain an operational graph.

If your project separately needs those physical outputs, Leviathan's Physical Infrastructure Planning & CAD service is the relevant scope discussion. Use the related project inquiry to describe the required records, their intended recipient and the authorized inputs available. Authoring resources, formats and review responsibilities require engagement confirmation. Digital-twin software, telemetry integration, analytics and ongoing model hosting remain with separately appointed providers.

References: [L-PLAN](https://www.leviathansystems.co/services/engineering-design)

## Primary sources

- [DT-NIST — NIST — Building Digitization and Semantic Interoperability](https://www.nist.gov/programs-projects/building-digitization-and-semantic-interoperability). Checked 2026-10-20. Ongoing programme, updated February 19, 2026. Its lifecycle-data and relationship research frames the buyer question; anticipated benefits remain programme aims.
- [DT-AZ-GRAPH — Microsoft — Digital twins and their twin graph](https://learn.microsoft.com/en-us/azure/digital-twins/concepts-twins-graph). Checked 2026-10-20. Azure-specific model instances, identifiers and relationships. Documentation updated January 27, 2025.
- [DT-AZ-TIME — Microsoft — Manage digital twins: property observation metadata](https://learn.microsoft.com/en-us/azure/digital-twins/how-to-manage-twin#update-a-propertys-sourcetime). Checked 2026-10-20. March 4, 2025 documentation on processing, observation metadata and retained-sourceTime behavior.
- [L-PLAN — Leviathan Systems — Physical Infrastructure Planning & CAD](https://www.leviathansystems.co/services/engineering-design). Checked 2026-10-20. Agreed physical planning and documentation, with capability and outputs confirmed per engagement. Provides context for a separate physical record requirement.

## Related Leviathan resources

- [Physical installation handoff: identities, revisions and open items](/articles/as-built-handoff-package-gpu-deployment)
- [Physical Infrastructure Planning & CAD: define a separate record package](/services/engineering-design)
- [Project inquiry for physical planning and handoff records](/contact?service=engineering-design&from=%2Farticles%2Foperational-digital-twin-identity-time-relationships)
- [Which Rack Layout Does the Model Quantity Describe? Design Options and Project Phases](/articles/revit-design-options-project-phases-rack-layout-quantities)
- [Why an SSD's Empty-Drive Speed Does Not Describe Repeated Writes](/articles/ssd-garbage-collection-versus-fresh-drive-performance)

## Discuss a separate physical planning requirement

If physical layouts, connection schedules or handoff records are needed, describe those outputs and their recipient so we can discuss scope, resources and availability.

[Discuss the scope](/contact?service=engineering-design&from=/articles/operational-digital-twin-identity-time-relationships)