State has direction
Reported state usually flows from asset to twin. Desired state and commands flow back only when a control loop is allowed.
Synchronization loop
Step through the sync contract to see which state is trusted at each point.
Robot cell
Physical asset
Sensors observe the real process and produce reported state.
Edge gateway
Filters, timestamps, buffers, and validates updates before the cloud sees them.
Twin service
Stores state, versions updates, resolves desired deltas, and exposes query views.
Operator app
Reads the twin for decisions and sends commands only through a governed path.
Observation creates reported state
The asset emits a timestamped reading. The twin should not treat that value as fresh forever.
State contract
reported + desired + version + timestamp
Six concepts in the sync loop
Each stage changes what the learner should trust about the twin.
Physical state vs twin state
The chart shows why a twin can look precise while still lagging the process or relying on a model.
Physical state
Twin state
Desired target
State contract snapshot
A twin design becomes easier to reason about when every update has a type, version, timestamp, and owner.
{}
The measured or inferred asset state. It should include source time and quality.
{}
The target configuration. It is not the same as what the asset is currently doing.
{}
Used to order events, detect stale writes, and avoid overwriting newer state.
{}
Commands should be idempotent, acknowledged, and bounded by a safety policy.
Pattern comparison
The best pattern depends on what must be true before a human or controller acts.