Reported Versus Desired State
Holding two representations of a device — what it last said it was, and what it should be — with the gap between them driving reconciliation.
A digital twin is not a simulation; it is a pair of documents. Reported is the device's last known state, updated when it connects. Desired is the configuration it should have, set by the backend at any time regardless of whether the device is reachable.
This decoupling is what makes managing intermittently connected devices tractable. An operator changes a setting while the device is offline; the change is recorded as desired. When the device next connects, it fetches the delta, applies it, and reports its new state. Nobody has to wait for the device to be online to express an intention.
The gap between the two is the operational signal. A device whose reported state has matched desired for weeks is healthy and idle. A gap that persists across several connections means the device is receiving the change and failing to apply it — which is a different fault from one that is simply offline, and the twin distinguishes them where a single state document would not.
Two properties are needed for it to work: the device must apply changes idempotently, since it may receive the same desired state repeatedly, and the reported document must include a version or timestamp, or a stale update overwrites a newer one.