Joint Venture “Golden Thread” Data Protocol: How to Build a True Common Data Environment With Multiple Contractors

By

Anna K. Cottrell

Last Updated Jul 24, 2026

By

Anna K. Cottrell

A Joint Venture (JV) construction project always comes with high stakes. Multi-million, multinational collaborative projects come with so many benefits - from highly ambitious project concepts to the significant profits in store for the participants. But on the other side of the JV coin are the enormous logistical, legal and data management challenges that translate into big risks. Merging two separate workforces is never a simple process; it often results in miscommunications and disputes and costly delays. But now, following the implementation of the BSA, a mismatch in processes can be even more costly.

Let’s imagine the following scenario. Two Tier 1 heavyweights win a massive, £500-million infrastructure scheme. Both have incredible, highly refined digital workflows. But Contractor A uses one proprietary Common Data Environment (CDE), and Contractor B uses another. They are operating as a Joint Venture, but digitally, they are building two separate projects.

The result? A failed Gateway 3 application.  The Gateway 3 "hard stop" does not accept fragmented data. If the JV cannot present a single, unified, and verifiable Asset Information Model (AIM), the Building Safety Regulator (BSR) will halt occupation. You cannot hand a client a building with two different sets of digital keys.

What went wrong for the JV? And how can this all-too-possible Gateway 3 disaster be averted?

The Problem

The most likely cause of the broken Golden Thread is an inherent power imbalance that so often plagues JVs. Typically, one contractor is bigger and/or more experienced than the other and forces their systems on the other. As any contractor worth their salt will know, imposing new systems without understanding and consent on the ground leads to poor implementation and even resistance. In practice, this leads to shadow-IT, lost data, and broken audit trails. 

By the time the discrepancies in data management are spotted, it’s often too late: you can’t re-manage an entire project. And consequences are hefty: The BSR doesn't care about your internal IT disputes. A broken Golden Thread means a rejected Gateway 3 application.

The Solution: Standardising Before Design

It can’t be emphasised enough that the right time to fix this issue is at the very beginning of the project fixing a data clash cannot happen at handover. It must be negotiated before starting on site.

It’s also important to stress that the solution to a digital clash isn’t so much about implementing any one specific type of software but about implementing consistent and transparent processes for how data is handled at every stage and every level of the project. 

At the macro level, it is essential that all parties in the JV are on the same page about shared data management structures from the outset. As any contractor with experience of a JV will know, these complex projects require precise and unambiguous definitions of contractual terms if everyone’s legal and commercial interests are to be adequately protected. The same level of intricacy should apply to negotiating data management processes. One way to do this is by drawing up a Master Information Delivery Plan (MIDP) as the binding digital contract between JV partners. It dictates exactly how and when data drops occur, regardless of the software being used. An MIDP is a roadmap everyone involved in the project will use, but the consent to use it should be unanimous and explicit.

At micro level, the success of this roadmapping will depend on all parties using the same language. We already mentioned the power imbalance that results from one contractor imposing its systems on another: this will include preferred definitions, which can be a source of confusion. As part of its adherence to a master plan, a JV should use established strict, agnostic naming conventions. The easiest way to do this is to align all namings with the UK National Annex and Uniclass 2015, which is, in fact, now a requirement for UK BIM projects. As a classification system, it assigns every construction element a specific code and description, which eliminates ambiguity from the project’s records. 

The end product of aligning a JV’s partners’ data systems on both the macro- and the micro level is a Common Data Environment (CDE) in the true sense: transparent, accessible, and reliable. A true CDE acts as the connective tissue for complex JVs, fostering predictable performance and trust at scale.

Building the Middleware Bridge

You’ve successfully drawn up and cosigned the MIDP and agreed to adopt the Uniclass. The question at this point is: How do you actually get Contractor A's data to sync with Contractor B's data, and ultimately the client's Computer-Aided Facility Management (CAFM) system?

Fortunately, the blueprint to how to effectively organise the vast amount of data that are the inevitable byproduct of a large joint venture project is already there: it’s in the ISO 19650-4 standard.

The ISO 19650-4 is essentially a suite of protocols that offers a standardised approach to every facet of an organisation’s data management. It includes concepts and principles(ISO 19650-1), asset delivery phase (ISO 19650-2), asset operational phase (ISO 19650-3), information exchange (ISO 19650-4) and security (ISO 19650-5). The ISO 1960 is part of the UK BIM Framework, but the processes are internationally recognised, which makes implementation even more sensible if your project has an international team. ISO standards can be downloaded and learned online, and contractors can get certified in ISO by an accredited organisation, which means meeting specific requirements depending on whether you’re a Tier 1 or Tier 2 contractor. 

There are huge benefits to acquiring training and certification in the ISO 19650 - essentially, you’ll be learning the new lingua franca for data management. If you then pair up with a contractor who is also certified, your data synching process will run smoothly: you essentially speak the same language.

But opportunities for standardisation go further than sharing a set of concepts and protocols. You can ensure seamless connections with other contractors by adopting standardised technical tools for the job: IFC for 3D geometric modeling and COBie for non-graphical facility asset data.

The easiest way to think about IFC and COBie is that IFC is the 3d BIM model that encompasses the entire design of the building, including materials. It’s the whole ‘pie’ of your project, as it were, in its three-dimensional form. COBie, on the other hand, lets you examine slices of the pie in more traditional, spreadsheet format. It can cover things like scheduling, warranties, and so on. 

COBie is a great additional tool that often allows teams to feel more comfortable by drilling into subsets of their project data that are pertinent at a particular stage of the project, in an interface that is familiar and easy to use. It’s often referred to as being a bit less ‘scary’ to navigate than IFC. It is important to remember, though, that COBie is the additional tool, and IFC is the main one, not the other way around. The former offers partial drilldowns into the data, while the latter is the complete picture.

Which is where a third type of tool in the contractor’s new toolbox comes in handy: the ‘middleware’ category of software for BIM. The name is the giveaway: this type of tool operates as the middleman or translator between your BIM authoring applications and your data management systems. Whenever you’ll be asking a question like, “where does this data set correspond to in the actual, living model?” is where this type of application will be doing the heavy lifting for you. Middleware translates these datasets so the client receives a perfectly mapped Asset Information Model.

The Gateway 3 Rehearsal

By the time the time of the Gateway 3 submission comes, a JV with such a robust data management protocol is perfectly positioned to present the BSR with a cohesive dossier that includes all the mandatory items from the federated CDE (e.g., As-Built drawings, Change Control Logs, Dutyholder Declarations). These can be easily accessed and audited by the BSR's Multi-Disciplinary Team making the Gateway 3 assessment.

This is a stress-free, highly predictable scenario that is the complete opposite of the late-stage scramble that can occur when a JV operates in a ‘digital clash’ environment and does not unify its data streams. 

Conclusion: A Unified Front

At the end of the day, though,  unified Golden Thread isn’t just for the regulator; it protects both JV partners from the 30-year retrospective liabilities of the Defective Premises Act.

When enterprise data flows seamlessly, the JV doesn't just deliver a building; they deliver a flawless digital twin.

Written by

Anna K. Cottrell

Writer and Editor | Freelance

14 articles

Anna K. Cottrell is a writer and researcher with an expertise in the property and finance sectors.

View profile