Golden Thread? Coders solved this years ago
The entire construction industry is awash with commentary and suggestions on the Grenfell Tower Hackitt report and how a “Golden Thread of information” will be achieved in practice.
I want to clarify that I don’t think a “Golden Thread” is something you have; you can’t acquire one and be done with the process. You have to BUILD your Golden Thread as the project goes through every phase and MAINTAIN it with every step and decision taken.
Building owners will be expected to create a “complete as possible” record of every project, providing a huge wealth of data that can be used to make future decisions about the building. In practice, this could be a paper-based system (think site diaries, printed drawings, entire rooms of O&M manuals, etc) but a digital record is much easier to share, maintain, update, and search.
This data set can be used to extract more value from the building during its lifetime by both owners and occupiers. Any issues that are found in the future can be investigated in a way that is impossible with construction projects completed today because we currently don’t capture all the information required.
The ability to understand what a team was thinking years or decades ago when they made a decision is critical to solving the problems that will inevitably occur with a multi-decadal asset.
So let’s define what do we want to capture in a “Golden Thread”? From my discussions with others, I think it’s four things:
- What decision was made?
- When was the decision made?
- Who was involved?
- What was the thought process?
All of that needs to be achievable across (potentially) thousands of documents created by a constantly fluctuating workforce in an environment where specification changes, value engineering, and legislation are constantly creating the need for modifications. To add complexity, this needs to happen for all information over extended time periods.
How is that going to be achievable?
What if I told you that coders solved this problem in 2005 and nearly every software project is built using the solution?
The solution is called Git.
“Git is a version-control system for tracking changes in source code during software development.”
If you replace “source code” with “any document” and “software development” with “construction”, you have suddenly created a system that can manage the Golden Thread for any project.
Woah, Woah, Woah; back up; what is Git?
Git is a way that any group of people can collaborate on the same document, making any edits they like, allowing users to merge different versions together into a single final version AND still know who did what in the document. It’s even possible to have discussions about the edits within a Git environment, meaning the meta of a document is stored alongside the list of changes.
I’m still not getting it; can you break it down further?
Sure. Let’s imagine Annie is writing the specification for a new building. This document will have a creator (Annie) and multiple other collaborators (Bert, Charlie, and Dave).
Annie uploads her first draft of the specification to the Git system creating a “master” version of the document. She invites the other three to the document as collaborators. Bert, Charlie, and Dave now have access to the document.
Charlie decides she wants to rewrite a section of the document, so she creates a new “branch” and makes a couple of edits. Once Charlie has made her changes, she creates a merge request.
The other collaborators see that there is a new merge request and check the edits. Everyone agrees to accept the new changes after some discussion on the merge request. Charlie’s merge request is accepted into the master branch.
Let’s break down what just happened.
- someone was able to make edits to a document without affecting the source of truth that is the master document.
- the editor then presented their edits to all the relevant stakeholders.
- a discussion was had about the edits, and the edits were merged into the master document once they were accepted.
At no point was the master document in danger of being edited and shared as “the correct version” AND we have stored the discussion and decision for each edit alongside those edits.
Sounds like building a Golden Thread to me.
But we’re just getting started. Git is more powerful than the first simple example. It is possible (and preferable for efficiency) that anyone invited to a document can create their own branches in parallel and merge the edits into the master document at different times.
Git checks the edits before merging and won’t allow merging of changes if there are “conflicts”. Conflicts occur when changes have been made to the same part of the document on two different branches and it requires the person doing the merge to decide what the final version content should be.
Powerful stuff, especially if different people or teams are working on different parts of a document. Now let’s imagine you have a big team who are all working on a big rewrite of a document, how can you manage that? By creating branches of small edits off of other branches.
For me, creating a Git system for documents in construction is a necessity if we are to achieve a Golden Thread for every project. On new projects, we can capture every edit, suggestion, and discussion around each document to create a record that provides context around every decision. Imagine the benefit for future investigators who need to understand why a decision was made‽
Another benefit is for future designers and maintainers who need to review the existing building for refurbishment or modification. Rather than spend many months performing site surveys to collect information, everything should be present in the history of the documents for the project.
Unfortunately, the context for existing buildings has already been lost to time; that isn’t a reason to avoid collecting it via a Git system in the future. If the information isn’t there, anyone can add it as another merge, increasing the value of the building documents as time goes on and heading towards an up-to-date Golden Thread as the building is refurbished.
The writer, Ben Jeater is the Technical Director of Prin-D Technology Ltd, a company dedicated to helping clients achieve accurate and complete CDM records of their assets through the use of Blockchain and Git technology.
