ARTICLE
Making the Golden Thread Work: Models, Revisions and Handover
The golden thread is a legal duty, but it is won or lost as a records problem: how the model is structured, how revisions are controlled, and what actually gets handed over at the end. Here is what that looks like on a live project.
A records problem before it is a legal one
The Building Safety Act put a name and a statutory duty on a discipline that well-run project teams already practiced before the Act existed: keeping an accurate, current, traceable record of a building's design and construction information. For what the duty actually requires at each stage of a project, and who holds it, see our companion piece on what the Building Safety Act requires. This piece is about the other half of the problem — what "keep a golden thread" means for the model and the document set on a Monday morning, not just in the legislation.
Satisfying the letter of the duty is the easy part: keep files somewhere digital. Satisfying its intent is harder, and it is a data and modelling discipline more than a compliance exercise. Get the structure right and the record stays close to invisible — questions get answered by looking something up. Get it wrong and the record exists, technically, while still failing everyone who has to rely on it.
Structuring the model and the document set
A golden thread that works starts from a simple principle: every drawing, model and document has one current version and one location, not a copy in an inbox and another on a shared drive both claiming to be current. That means a naming and coding convention applied consistently — discipline, zone, type, revision — agreed before the first drawing is issued, not retrofitted once hundreds of files already exist under inconsistent names. A workable convention is usually simple to state even where it is detailed to apply: a fixed set of codes for discipline, building zone, drawing or model type and revision, agreed and written down once, so that anyone new to the project can decode a file name without asking. The convention matters less in its specifics than in being applied without exception — a naming rule with regular exceptions carries less real information than no rule at all.
A federated BIM model, where each discipline's model is maintained separately but coordinated into a single reference, is usually the practical backbone of this on anything beyond a small project. It gives the record a structure that mirrors how the building is actually designed, rather than forcing every discipline's information into one file that nobody can maintain cleanly.
Revision and change control
Every change needs to be traceable to a person, a date and a reason, not just a new file with an incremented number in its name. That is what turns a folder of drawings into an audit trail: a record that can answer, months or years later, exactly what changed, who approved it, and why — rather than requiring someone to reconstruct the answer from memory or from an email thread that may no longer exist.
One distinction is worth being precise about, because confusing it is a genuine safety risk rather than an administrative slip: the latest revision of a drawing and the revision that is actually approved for construction are not always the same thing. A drawing can be revised for coordination purposes and shared for review before it carries the status that permits anyone to build from it. A record that only tracks "latest" and not "approved for construction" is not doing the job the golden thread requires of it. A common version of this failure: a coordination comment gets actioned in one drawing, and the same change is needed in three others that reference the same detail, but only the first one is updated because nothing forced the other three to be checked. An audit trail does not prevent that by itself — it at least makes the gap visible and traceable once someone goes looking for it.
The common data environment, and where ISO 19650 fits
A common data environment is the practical mechanism most project teams use to enforce the structure above: it gives each container of information — drawing, model, document — one unique identity, one current status and one location that everyone with permission is looking at. ISO 19650 is the internationally recognised framework many teams structure this around, defining how information is organised, exchanged and managed through a project using status and suitability codes that describe both where a piece of information sits in its workflow and what it may be used for at that point. A model can be shared with status "work in progress" and suitability "for coordination" long before it reaches the status and suitability that permit anyone to build from it, and the golden thread depends on that distinction being enforced rather than left to individual judgement.
Neither a common data environment nor ISO 19650 is, by itself, the golden thread — they are the tooling and the framework that make a compliant golden thread achievable without reinventing the structure from scratch on every project. We go into the mechanics of status, suitability and audit trails in more depth in our piece on engineering data management systems.
Handover that the next owner can actually use
At completion, what gets handed to the accountable person should be a defined export from a record that has been current throughout the project, not a document assembled retroactively in the final weeks before Gateway Three. In practice, that means the current as-built model and drawing set; the approval and revision history behind it, not just the final versions; specification and product data for what was actually installed, which frequently differs from what was originally specified; and structured asset information formatted for whatever facilities management system will operate the building afterward. None of this needs to be exotic in format — structured, consistently named files that a facilities management system can actually ingest matter more than any particular software choice — but it does need to be planned as a deliverable from the start of the project rather than defined for the first time in the handover meeting.
A handover package assembled this way is a query, not a project. A handover package assembled retroactively is a multi-week reconstruction exercise, running at the exact point in the programme when everyone involved is trying to close the project out.
Where to start on a live project
Agree the naming convention, the model structure and the status and suitability codes before the first drawing is issued. Name someone accountable for the record itself — not just for the design — with the authority to enforce the convention rather than merely recommend it. And treat the golden thread as continuous from the first day of design, not as a deliverable that gets assembled once, late, under deadline pressure.
None of this is complicated in principle. It is only difficult when it is left until the record already needs to be reconstructed rather than simply exported.