A drone inspects a construction site at 2 PM.
Its camera fails during one section of the flight. By the next morning, workers have covered that section with concrete.
The team can repair the data pipeline, process another flight and update the BIM model.
But yesterday’s missing observation remains missing.
A reconstruction may help explain what probably existed. It cannot become a photograph that was never captured.
For infrastructure owners, this creates a practical problem: a digital twin can become more complete while losing the distinction between evidence and hindsight.
That distinction matters when someone asks why a machine proceeded, why an alert was delayed or why a team approved the next stage of work.
What we know today may be different from what the system knew when it acted.
A cleaner dataset can create a misleading history
Backfilling is useful. It can restore delayed sensor readings, correct processing errors and improve historical analysis.
The problem begins when those improvements silently change the apparent basis of an earlier decision.
Consider a hypothetical construction robot.
At 10:03, its available observations do not identify an obstacle.
At 10:04, it proceeds.
At 10:07, delayed footage reaches the platform and shows that an obstacle was present.
That footage improves our understanding of the incident. However, if it is inserted into the historical view without its arrival time, a reviewer could conclude that the robot had access to it before proceeding.
The record now contains better evidence but tells the wrong story about the decision.
This can send an investigation toward the wrong cause. Teams may blame perception when the problem was transmission, or blame an operator for overlooking information that had not reached their screen.
Why this matters as AI enters physical operations
An Phan’s September 25 WeAreDevelopers session, You Can’t Rerun Sunlight: Designing ML Data Architectures for Physical AI, highlights this constraint: physical observations can be lost irreversibly, and backfilled data can alter our understanding of what a system knew at the time.
For geospatial systems and digital twins, the implication extends beyond robotics.
A crack photographed after a repair does not establish its exact condition before repair.
A satellite image received after a flood warning may improve the assessment without having informed that warning.
A drainage reading captured locally during a network outage may explain an event even though the control room received it much later.
These are different evidence situations. A platform should preserve those differences.
In my view, the next test of a digital twin’s usefulness is whether it can explain the information available at a specific decision point.
Keep two timelines
A useful starting point is to separate:
Event time: when the observation or event occurred.
Knowledge time: when the relevant system received or recorded that information.
Temporal databases already provide foundations for this distinction. IBM’s bitemporal model combines application or business time with system history. That supports historical queries, although reconstructing an operational decision also requires records of what reached the relevant application or person.
Consider a hypothetical drainage incident:
Time - Evidence or action
Around 14:00 - Blockage begins, estimated retrospectively
14:06 - Sensor captures an abnormal reading
14:09 - Platform receives it and generates an alert
14:31 - Field team confirms the blockage
14:34 - Operator accepts the confirmed status
The final assessment may place the start near 14:00.
It should also retain that the platform first received relevant evidence at 14:09 and obtained field confirmation at 14:31.
That makes response times interpretable. It also keeps an estimated onset from acquiring the appearance of an exact observation.
Preserve three kinds of evidence
For practical implementation, I would distinguish three categories.
Observed evidence comes from an actual capture: an image, measurement, inspection or device log. It still needs source identity, location, timing and quality information. Observation alone does not guarantee accuracy.
Reconstructed evidence comes from interpolation, simulation, inference or retrospective analysis. It can be valuable, but its method, assumptions and uncertainty should remain visible.
Verified operational state records the conclusion accepted through an appropriate review process. It should identify the supporting evidence, reviewer and acceptance time.
These categories can coexist.
A reconstruction can guide an inspection. A field inspection can support an accepted status. Later evidence can revise that status.
Each step should remain traceable.
Capture the evidence before the opportunity disappears
Historical integrity starts at the point of capture.
Where connectivity is unreliable, local buffering can preserve observations until transmission becomes possible. The receiving platform should retain capture time alongside receipt time.
For significant events, teams can preserve an evidence window around the anomaly, including relevant readings before and after it. The duration should reflect the process: a rapid machine fault and a slowly developing drainage blockage need different windows.
Decision records also need context.
Which model version ran? Which threshold applied? Which observations were available? Was a sensor offline? Did an operator acknowledge the alert? What action followed?
Without that context, rerunning the same model against a repaired dataset may produce a result that says little about the original decision.
Retention should be deliberate. Preserve evidence according to operational consequence, privacy obligations and investigation needs, with controlled access and a traceable correction process.
Test the historical view
A simple acceptance test can reveal whether a platform preserves decision history:
Select a past alert. Add relevant evidence with an earlier capture time but a later arrival time.
Then inspect both views.
The current assessment should incorporate the new evidence.
The historical decision view should still show what was available when the alert was handled.
If both views change identically, the platform may be merging hindsight with the original information state.
This test is useful for owners, integrators and delivery teams because it turns an abstract trust requirement into observable behavior.
The business value is better diagnosis
Preserving historical context helps teams distinguish capture failures, transmission delays, model errors and response failures.
That creates a stronger basis for corrective action. It can also support maintenance reviews, contractor discussions and training datasets that reflect the information available during actual operations.
For AI evaluation, the distinction is especially important. A model tested with information that arrived later may appear more capable than it could have been at the decision point.
The commercial question is therefore broader than whether a platform stores enough data.
Can it explain why a decision was reasonable or flawed using the evidence available then?
A trustworthy digital twin should improve its understanding as new evidence arrives while preserving the path to that understanding.
The standard I would apply is straightforward:
Every important physical decision should retain a traceable record of its evidence, its gaps and its timing.
