Digital Twins and the Golden Thread: Evidence Before Prediction
For building safety decisions, we recommend using a digital twin to organise evidence and test specific questions, rather than treating its output as proof of compliance. Start with the records behind a decision and define what the model is allowed to conclude. Our proposed approach separates observed conditions, simulated conditions and approved actions.
NIST's report on digital twin security and trust describes electronic representations of real entities. It distinguishes static models, dynamic simulations, monitoring and command and control. Those are different uses, rather than interchangeable promises of continuous monitoring.
We would therefore ask a supplier to demonstrate the particular use being purchased. For an inspection workflow, require the model to show which asset was inspected and which evidence supports its status. For a simulation, ask for its assumptions and comparison with physical observations. Do not accept a visual demonstration as the acceptance test for either task.
Keep the golden thread distinct from the model
The Building Regulations Advisory Committee's 2021 golden thread principles cover information management as well as information. They address accuracy, access, security and keeping records current. Their change-recording principle includes the reason, evaluation, date and decision process behind a change. These are information-management principles, not a specification for a digital twin.
Our recommendation is to make the twin a consumer of controlled records, with a clear route back to their source. Give each asset a stable identifier. Attach the approved drawing revision, relevant inspection evidence and unresolved issues to that identifier. Label an unverified import as unverified, rather than giving it the same status as an approved record.
When an inspection corrects an earlier entry, retain the earlier entry alongside the correction and its explanation. Define who can make that correction and who must review it. We would not describe this arrangement as immutable unless the storage and administrative controls justify that specific claim. Specify retention and correction behaviour separately from the modelling software.
Illustration only. The figures shown are not measured project results.
Define what real time means for the decision
NIST identifies time and synchronisation as trust considerations. A physical object may deteriorate while its digital representation remains unchanged. The report also treats accuracy and testing as separate trust questions.
For a proposed building monitoring system, we recommend agreeing a freshness rule for each input before setting an alert threshold. Record when a measurement was taken, when the system received it and which device supplied it. Display the age of the observation beside the status it supports. Use a separate unknown status when evidence is missing or older than the agreed limit.
As a hypothetical acceptance test, disconnect a sensor feed while leaving the display running. Ask the operator to identify the last supported condition and the point at which the system stops presenting it as current. Reconnect the feed with delayed measurements and test how the display handles them. Require the system to distinguish a late arrival from a new observation.
For manual inspections, define a different update rule. Ask the responsible team to approve how long each observation remains useful for the particular decision. Avoid giving a manually updated inspection record a live label merely because the screen refreshes.
Test a safety scenario before prescribing action
For predictive safety work, our recommendation is to begin with a bounded question, such as which assets warrant further inspection after a reported change. Keep this separate from declaring an asset safe or diagnosing the cause of a defect. Require a named reviewer to decide what evidence is sufficient for action.
Consider a hypothetical change to a building's internal layout. We would record the proposed revision, the assumptions used in a simulation and the person responsible for checking them. Ask the reviewer to identify which conditions the simulation covers and which require site evidence. Retain the result with the exact model version and input records used to produce it.
Before allowing a recommendation into an operational workflow, define a test set with the safety team. Include a known issue, a normal condition and deliberately incomplete evidence. Record missed issues and unnecessary alerts separately. Agree the conditions under which the system must decline to recommend an action. Treat these as proposed acceptance criteria, not as evidence that an untested system predicts incidents.
Integrate existing systems without hiding their limits
For legacy integration, we recommend mapping the origin and owner of each required field before choosing connectors. Keep source identifiers and units with imported values. Record whether an input is an approved design, an observed condition or a calculated estimate. Do not silently substitute one for another when a field is missing.
Start with one asset type and follow its records through a design change, inspection and correction. Test an export and ask another team to reconstruct the decision without access to the original interface. Our proposed handover test is whether that team can locate the evidence, identify its revision and understand what remains unresolved.
NIST also identifies cybersecurity risks around sensors, centralised measurements and manipulated representations. For an initial implementation, we recommend read-only connections unless there is an explicitly approved need for control. Test permissions at the source and in the twin, including a user who may view an inspection but may not alter its approval.
Our suggested starting point is one reviewable decision with named evidence, freshness limits and an accountable reviewer. Expand only after the team has exercised missing-data, correction and handover cases. Before commissioning a wider model, ask the supplier to demonstrate those cases against the records your team actually uses.
Update, October 2026
For teams adding an AI assistant to this workflow, we recommend giving it dated evidence and explicit gaps before asking for a recommendation. Our engineering article on grounding packs for agents provides a related design discussion. Keep any proposed safety action subject to the review and approval rules agreed for the workflow.
Sources
Want this in your team?
Tell us what you're building and where you want to get to, and we'll think it through with you.