The digital twin doesn't start at handover. It starts on day one.

A digital twin is a living representation of a physical asset — updated, queryable, and useful to whoever is operating the building. The problem is that most conversations about digital twins happen at handover, which is precisely the moment when the model is least likely to be structured for that purpose.

By the time a design model reaches handover, it has been through multiple software translations, discipline separations, and coordination merges. The parametric data that was attached to objects in the original authoring software has often been flattened, lost, or left inconsistent across disciplines. A model that arrives at handover in that state cannot become a useful twin without significant rework — and that rework is rarely budgeted for.

The information requirements for a digital twin need to be established at the same time as the project BEP, not after practical completion. That means deciding — at Stage 2 — what asset data will be carried through the model, what format it will be in at handover, and who is responsible for maintaining it through each stage of design and construction.

Common data environments are the other piece. A CDE that is set up to support design coordination is not automatically set up to support FM. The folder structure, the status workflow, and the naming convention all need to anticipate how the FM team will query the model, not just how the design team will exchange files. Getting that structure right at the start of the project is much cheaper than retrofitting it at Stage 6.

The clients who get the most out of digital twins are the ones who treat the model as a live operational tool from the moment the CDE is set up — not as a design record that gets repurposed at the end. That shift in thinking changes how information is managed at every stage, and it's the single biggest factor in whether a twin is actually useful when the building opens.