Digital Twins & BIM don't stay accurate on their own

Why a digital twin needs a maintenance plan, not just a capture date

A digital twin is usually sold, and bought, as a one-off deliverable. Someone captures a building or a site, hands over a model, and the project moves on. The assumption baked into that process is that accuracy is a moment in time: true on the day of capture, and someone else's problem after that.

It isn't, and treating it that way is the main reason digital twins lose value faster than the organisations that commission them expect.

A building or a construction project changes constantly, from the first design revision through to years of operational life. A twin that isn't maintained against that change doesn't stay neutral, it actively misleads. Every day it goes unmaintained, the gap between the model and reality gets a little wider, and nobody notices until a decision gets made on the wrong information.

This isn't only a facilities management problem that shows up after handover. Drift starts far earlier than that, and it's relevant to everyone who touches a project: architects and engineers managing design changes, contractors managing variations and sequencing, developers managing fit-out, and FM teams managing the building for the rest of its working life.

Where drift actually enters a project

1. During design

Design models change constantly between RIBA Stage 2 and practical completion. Layouts shift, specifications get value-engineered, coordination clashes get resolved in ways that alter what was originally modelled. If the digital twin (or the model that will eventually become one) isn't updated in step with those changes, it starts drifting from the design intent before a single wall has gone up.

2. During construction

This is where the gap usually opens widest. Site variations, RFIs answered informally, snagging fixes, and sequencing changes all happen faster than documentation can keep up with in a typical project. Contractors are, understandably, focused on delivery, not on maintaining a spatial record. Unless capture and verification are built into the construction programme, what gets handed over as "as-built" is often closer to "as-designed with unrecorded exceptions."

3. Around fit-out and early occupation

Even after a formal handover, the pace of change doesn't slow down straight away. Tenant fit-outs, snagging resolution, and commissioning adjustments in the first few months of occupation are some of the most active periods of physical change a building goes through, often more active than anything that happens in the following several years.

4. Through operational life

Once a building is running, drift becomes slower but never stops. Plant gets replaced, spaces get reconfigured, leases turn over. Structure and envelope stay relatively stable for years, but the systems and spaces people actually interact with day to day change far more often than most FM contracts account for.

None of these are exceptional events. They're what normal project and building life looks like. A digital twin that isn't built to absorb that is a snapshot with an expiry date, not an operational asset.

Why a single capture date was never going to work

The industry's default approach, capture once, deliver, move on, treats a digital twin like a photograph rather than like the asset register or the BIM model it's meant to complement. Nobody would expect an asset register to stay accurate forever without anyone updating it. A digital twin needs the same discipline, applied across the whole project lifecycle rather than bolted on at the end.

The practical failure mode is familiar: significant budget goes into an accurate capture at one point in time, the model looks impressive at handover or at launch, and within a year it's quietly unreliable because nobody was ever assigned to keep it current.

Building a maintenance approach into the project, not after it

The fix doesn't require constant re-scanning of an entire building or site. It requires three things, applied consistently at every stage of a project rather than only at the end.

An update trigger, not a fixed schedule. Rather than committing to arbitrary re-capture dates, tie updates to events that are already tracked on any project: a design freeze, a variation sign-off, a fit-out completion, a plant replacement, a lease change. Each of those is a natural point to check whether the model still matches reality in the area affected.

Clear ownership at every stage. Design-stage accuracy should sit with the design team. Construction-stage accuracy should sit with the contractor, built into the same sign-off process as any other variation. Post-handover accuracy needs an owner too, whether that's the FM team directly or a managed service. The costly gap is the handover point itself, where ownership is assumed to transfer but is rarely formally assigned.

Targeted verification over full re-capture. Most drift is localised. A spot-check or partial re-scan of the specific area that changed is almost always faster and cheaper than re-documenting an entire building, and it's usually all that's needed to keep the record trustworthy.

Specifying this from the start

For architects and engineers, this means treating data currency as an explicit requirement in the Employer's Information Requirements from Stage 2 onward, not something addressed retrospectively at Stage 6.

For contractors, it means building verification into the variation and snagging process, so the model updates as the change is agreed rather than being reconstructed from memory later.

For developers and asset owners, it means specifying an update trigger and an owner in the FM contract from day one, the same way maintenance schedules are specified for any other building system.

None of this depends on a single technology or vendor. It's a process discipline that sits above whatever capture method or platform is being used, which matters because most projects and portfolios end up working across more than one.

Where this fits with what we do

At TWINFLOW, this is the part of digital twin delivery that gets skipped most often, because it doesn't have a clean project end date the way a capture programme does. We work with design teams, contractors and FM teams to build a maintenance approach into the brief from the outset: what triggers an update, who owns it at each stage, and how verification happens without re-capturing an entire building every time something changes.

Where a live, versioned platform is useful for holding that ongoing record, SIM-ON is one of the tools we use to do it, alongside other capture and platform technologies depending on what a project actually needs. The technology is secondary. The discipline of keeping the twin honest across the life of a project and the building that follows it is what makes the investment hold its value.

If you're specifying a digital twin for a project currently in design or on site, or trying to work out why one you already have has started to feel unreliable, we're happy to talk through what a maintenance plan for it would look like.

Reach out to us if you would like to find out more.

Request a TWINFLOW consultation