Document control and the common data environment

Three weeks after the Westgate podium slab was poured, a carpentry crew from one of Brightwater's subcontractors set out the formwork for the level 2 transfer beam from a drawing that had been superseded eleven days earlier. The revised drawing moved two embedded steel plates 150 millimetres to suit the timber connections above. Nobody on the crew had done anything careless: the old sheet was still pinned to the wall of their site trailer, and the revision had been posted to the project platform with a notification that went to their office, not to the foreman. The error was caught by Hannah Lowe during her pre-pour check, and it cost a day of rework rather than a cracked connection, but it showed Brightwater exactly why document control is not clerical work.

Document control is the set of rules, roles and tools that make sure everyone on a project works from the right version of the right document, and that every document can be found, traced and trusted later. On Westgate it is run by project coordinator Jun Park, with help from the platform Brightwater uses for every project. In this lesson we look at the parts of a document control system: the register, naming and numbering, revisions and status, the common data environment, distribution, and the audit trail that ties them together.

What a document control system must do

Whatever tools a project uses, from shared network folders to a full construction management platform, the system has to do the same five things.

A system that does only some of these will fail at the worst moment. A perfect filing structure is useless if the foreman cannot reach it from the slab edge. Instant mobile access is dangerous if superseded drawings stay on the tablets. The rest of this lesson takes each function in turn.

The document register

The heart of document control is the register: a list of every controlled document with its current state. For drawings it is often called the drawing register or drawing list; for the whole project it may be called the master document register. On Westgate the register covers about 1,400 drawing sheets across architectural, structural, mechanical, electrical, civil and landscape disciplines, plus specifications, reports and the contract itself.

A register is only as good as its discipline. Every incoming issue is logged the day it arrives, the previous revision is marked superseded at the same time, and the register is reconciled with the designers' own lists at least monthly. On Westgate, Jun sends the register to Arden Moss each month and asks them to confirm it matches theirs; mismatches are investigated, not ignored.

Naming and numbering

Good numbering makes a document self-describing. A person who sees the number should be able to tell the project, the author, the area, the type of document and the discipline without opening the file. Many projects now follow the field structure of ISO 19650, the international standard for managing information over the life of a built asset using building information modelling. ISO 19650 itself leaves the exact codes to each project, and its national annexes and the project's information standard fill in the details.

The figure breaks down a typical Westgate number. WGT is the project. AMA is the originator, Arden Moss Architects. L2 is the level. DR says the file is a drawing, as opposed to M3 for a model or SP for a specification. A is the role, architecture, and 2104 is the sequence number. Revision and status are kept as metadata alongside the number rather than built into it, so the number never changes when the document is revised.

• Keep numbers short enough to read aloud on a site radio, but long enough to be unique across the project.
• Never embed the revision in the file name as the only record of revision; metadata and the register must carry it too.
• Agree the codes at the start of the project and publish them in the project's information standard or BIM execution plan.
• Never reuse a number for a different document, even if the original was cancelled.

Revisions and status

Every document goes through versions as it develops. Two pieces of information describe where it stands: the revision, which identifies the version, and the status or suitability, which says what the version may be used for. Confusing the two causes many site errors. A drawing at its latest revision may still be marked for coordination only and must not be built from.

Many North American projects still use simpler schemes, such as numbered revisions with descriptions like 'Issued for tender', 'Issued for permit' and 'Issued for construction', with clouds and delta symbols marking what changed on each sheet. The scheme matters less than consistency: everyone on the project should be able to look at a sheet and know instantly whether they may build from it.

Revision clouds deserve a warning. A cloud shows what the designer thinks changed. It is not a guarantee that nothing else changed. When a revision arrives, Hannah compares the new sheet with the previous one using the overlay tool in the platform, which highlights every difference. Twice on Westgate the overlay found changes that had not been clouded, including a door swing that affected the fire separation layout.

The common data environment

A common data environment, or CDE, is the agreed source of information for the project: the place where information is collected, managed and shared among the whole team. It is usually a cloud platform, but ISO 19650 defines it by its process, not its software. Information moves through four states, and gates between the states make sure that only checked and approved information is shared and relied on.

The important point for a contractor is the line between shared and published. A model or drawing in the shared state is there to coordinate. Trades who download shared information and build from it take a risk that the contract may not cover. Brightwater's rule is simple: if it is not published with a construction status, it does not go to the field.

In Canada, ISO 19650 is increasingly referenced by public owners and in BIM requirements, often alongside a BIM execution plan and the owner's own information standard. Federal departments and some provincial infrastructure agencies have moved toward requiring structured information management on major projects, although practice still varies widely from owner to owner.

Distribution and the field

Getting the right revision into the hands of the people building the work is the step that failed on the transfer beam. Distribution has two halves: sending the issue, and making sure the old version is withdrawn. Brightwater uses three habits on every project.

• Push to people, not just to companies. Every subcontractor names the foreman and project manager who must receive each discipline's updates, and the distribution list is reviewed monthly.
• Withdraw what is superseded. When a new revision arrives, the old sheet is marked superseded in the platform, and Jun issues a short weekly list of superseded sheets that foremen must remove from trailers and tablets. Paper sets on site carry a stamp showing the date they were printed.
• Check at the point of use. Pre-task plans and pre-pour checklists include a line confirming the drawing revision against the register, which is how Hannah caught the transfer beam error.

Controlled copies and uncontrolled copies need to be distinguished. A controlled copy is one the document controller tracks and updates; an uncontrolled copy, such as a printout taken for a meeting, carries no promise of being current. On Westgate every printed sheet carries a footer: 'Uncontrolled when printed. Check revision in the project platform before use.'

Jun also checks that every file uploaded to the platform follows the project's naming standard. A file with a wrong or missing field is hard to find and easy to confuse with another. A short script checks each name against the pattern before files are accepted.

# Check document names against the Westgate naming standard
import re
pattern = re.compile(r'^WGT-(AMA|KSE|TMC|BWC|LDS)-(L[0-4]|RF|ZZ)-(DR|M3|SP|RP)-[ASMECL]-\d{4}$')
names = ['WGT-AMA-L2-DR-A-2104', 'WGT-KSE-L2-DR-S-3010', 'WGT-TMC-L3-M3-M-0007',
         'WGT-AMA-L2-DR-A-2104-rev3', 'wgt-bwc-l1-rp-c-0102', 'WGT-LDS-ZZ-DR-L-5001']
ok = [n for n in names if pattern.match(n)]
bad = [n for n in names if not pattern.match(n)]
print('Accepted:', len(ok))
for n in bad:
    print('Rejected:', n)

Accepted: 4
Rejected: WGT-AMA-L2-DR-A-2104-rev3
Rejected: wgt-bwc-l1-rp-c-0102

Two names fail. One has the revision added to the end of the name, which would make the same document appear as different files over time. The other uses lower-case letters, which the standard does not allow. Both are returned to their authors with a note explaining the rule.

Protecting records and the audit trail

A good CDE records who uploaded, viewed, downloaded, changed and approved each item, and when. That audit trail is valuable evidence. If a subcontractor later says it never received a revision, Brightwater can show the transmittal, the distribution list and the download log. If an owner asks when a drawing was published, the platform can answer to the minute.

Permissions should follow roles. Designers can upload to their work-in-progress areas; only the document controller or an authorized reviewer can move information to published; nobody can delete a published document, only supersede it. When people leave the project, their access is removed the same day. Exports of the register and the audit log are taken monthly and stored outside the platform, so the record survives if the contract with the software provider ends.