Label what is real, the most underrated feature of a digital twin
A digital twin mixes measured, designed, published, estimated and simulated data. Saying which is which, on every record, is what makes the real parts trustworthy. A practical pattern from three builds.

Every digital twin I have seen is a blend. Some of it was measured. Some was drawn by an engineer. Some came from a spec sheet, some was estimated by someone who knows the process, and some is simulated because the sensor does not exist yet. That blend is normal and fine. The problem is when the twin does not say which part is which.
A twin that hides its provenance fails in a predictable way. Someone notices one number is made up, and from then on nobody trusts any of the numbers, including the ones that were measured carefully. The twin goes from decision tool to demo in a single meeting.
Five labels are enough
Across my recent builds I have used the same five labels:
| Label | Meaning | Example |
|---|---|---|
| Captured | Measured from the real thing | Gaussian splats trained from video of a racking aisle |
| Designed | Drawn or modeled for the twin | A Blender model of the parts of the building no camera saw |
| Published | Taken from a public, citable source | A kitchen's floor area and equipment schedule, from published sources |
| Estimated | A judgment call by someone who knows the process | Operation times not stated in any recipe |
| Simulated | Generated by a model, because no sensor exists yet | Freezer temperatures and forklift positions |
Five is a small enough set that people remember it, and it covers every case I have met.
Put the label on the record, not in a footnote
A provenance note on a slide gets lost the first time someone screenshots a chart. The label has to travel with the data.
In the Michelin Kitchen Twin, every record in the master data has a src list pointing at a bibliography, or est: true. A validator fails the build if a reference is broken. In the Food Bank Spatial Twin, every API payload carries simulated: true, so no dashboard, script or person downstream can mistake the feed for a real sensor. In the Academic Matchmaker, records missing a verified email or an institutional page carry flags like missing_email and are sorted after fully verified ones.
The same idea shows up in the UI. In the food bank twin's architecture diagrams, solid boxes are deployed and dashed boxes are designed and priced but not built. The browser badge says "Simulated feed" until the live API answers, then "Live from AWS". The labels cost almost nothing to add, and they answer the first question every serious reviewer asks.
Labels make the real parts more valuable
The counterintuitive effect is that labeling the estimated parts makes the measured parts more credible. When a reader can see that the freezer temperatures are simulated, they can trust that the splat capture of the aisle really came from the video. When the kitchen's recipe quantities for one dish are marked as published and tested against the source, the estimated timings next to them read as honest estimates rather than hidden guesses.
Labels also tell you where to spend money next. In the food bank twin, the labels made the next step obvious. The geometry is good enough to start. The simulated telemetry is the gap, and real sensors are priced at about $2,700 once and $12 a month. Without labels that conversation turns into a debate about whether the whole twin is real. With them, it is a line item.
A checklist I now use on day one
- Pick the labels before collecting any data, and put them in the schema.
- Make the build fail on a record with no source and no estimate flag.
- Carry a
simulatedflag through every API and into every chart legend. - Draw built and designed parts differently in every diagram.
- Write one page that lists what is real, what is not, and what would make it real.
None of this is sophisticated. It is the discipline a good plant already applies to its own data, applied to the twin. And it is the difference between a twin people use and one they politely admire.