04Document control, the common data environment and transmittals

04.0Scope of this chapter

This chapter explains how project documents are named, versioned, reviewed, issued, stored and replaced on a hyperscale data-centre campus. It also explains how the commissioning manager (CxM) uses the document control system so that every inspection and test is done against the current approved document. Chapter 05 covers requests for information (RFI), chapter 06 covers submittals and method statements, and chapter 07 covers inspection and test plans.

1. Purpose and roles. What document control does, the document classes on a data-centre project, and who is responsible for each step (document controller, information manager, design manager, CxM).
2. ISO 19650 concepts. Information containers, the common data environment (CDE), the appointing party and appointed parties, and the four container states: work in progress (WIP), shared, published and archived.
3. Status and revision codes. Suitability codes S0 to S7, the published codes A and B, the as-built record status (CR) for as-constructed records, the revision codes P01, P01.01 and C01, and the legacy BS 1192:2007 codes.
4. Naming. The seven-field container identifier (project, originator, volume or system, level or location, type, role, number) with the code lists and examples from the MSC-1 campus.
5. Registers and metadata. Document register and drawing register fields, with a filled example.
6. Review status codes. The A, B, C and D review codes used on many contracts in Asia and the Middle East, and what each code allows the contractor to do.
7. Transmittals. Transmittal fields, the transmittal workflow, acknowledgement, and the difference between a transmittal and project mail.
8. Review cycle time limits and key performance indicators (KPI). The time limits in FIDIC 2017, the United States unified facilities guide specification (UFGS) 01 33 00 and NEC, and how to calculate turnaround and overdue figures.
9. Site control. Superseded document control on site, redline mark-ups, as-built drawings and the record set handed to the operator.
10. CDE tools. What Oracle Aconex, Procore, Autodesk Construction Cloud (ACC), CxAlloy and Bluebeam Studio are used for on a commissioning programme.
11. Commissioning records. How the commissioning document set (owner's project requirements, basis of design, Cx plan, checklists, test scripts, issues log) is held in the CDE.

Documents and standards used: ISO 19650-1:2018 and ISO 19650-2:2018 and the UK National Annex guidance for ISO 19650-2 (building information modelling (BIM) Toolkit National Annex Guidance and the UK National Annex code lists as implemented in Autodesk Construction Cloud). The chapter also uses BS 1192:2007 (withdrawn), FIDIC Conditions of Contract for Construction 2017, UFGS 01 33 00 Submittal Procedures and NEC contracts guidance on the period for reply. It also uses Oracle Aconex help, Procore support documentation, Autodesk Construction Cloud help, CxAlloy and Bluebeam product documentation, and the MSC-1 case ledger.

04.1Purpose of document control on a data-centre campus

04.1.1What document control does

Document control is the set of rules and records that decides which version of each document is valid for which use and who may change it. It also records who has received each version and where the old versions are kept. On a data-centre campus the volume is large. The MSC-1 worked example has 4 buildings, 3 data halls per building and 12 data halls in total. Each hall has 16 coolant distribution units (CDU), 8 block transformers and their uninterruptible power supply (UPS) systems. A single building carries several thousand drawings, several hundred submittals and several thousand commissioning checklists.

Document control has six jobs.

1. Identify each document. Every document has one unique identifier that does not change across revisions. The identifier is built from fixed fields (section 04.4).
2. Control the revision. Every issue of a document carries a revision code and a status code. The pair tells the reader whether the content is preliminary or contractual and what it may be used for.
3. Control distribution. Every issue to another organisation is sent on a transmittal and recorded. The register shows who received which revision and when.
4. Control review. Documents that need review (design drawings, submittals, method statements, test scripts) pass through a workflow with a named reviewer, a due date and a review code.
5. Remove superseded information. When a new revision is published, the old one is marked superseded in the CDE and removed or stamped on site.
6. Keep the record. Every revision, transmittal, comment and review code is kept in the archive for the life of the asset and for any dispute.

Check: A tester who picks up a test script on site must be able to answer three questions from the document itself and the register. The questions are: which revision is current, is it approved for use (status A1 or C01 or higher on most projects), and has it been superseded. If the tester cannot answer all three in under two minutes, the document control system is failing at the point of use.

04.1.2Document classes on a data-centre project

The table lists the document classes that the CxM uses and the usual originator of each class.

04.1.3Roles and responsibilities

The role names differ between programmes. The functions in the table are always present.

The following matrix shows who is responsible (R), accountable (A), consulted (C) and informed (I) for each step of the document cycle.

04.2ISO 19650 concepts and the common data environment

04.2.1Information containers and the CDE

ISO 19650-1:2018 calls any named, persistent set of information an information container. A drawing file, a model, a specification, a spreadsheet register and a test script are all information containers. The common data environment (CDE) is the agreed source of information for the project, used to collect, manage and share information containers through a managed process. A CDE can be one software product or several products joined by rules, and the rules are part of the CDE. A shared network drive without states, codes and approvals does not meet the definition.

ISO 19650-2:2018 defines the parties. The appointing party is the client (on a data-centre campus, the owner). The lead appointed party is the organisation that receives an appointment directly from the appointing party, for example the design consultant or the general contractor. Appointed parties are their subcontractors and suppliers, grouped in task teams.

04.2.2The four container states

Every information container sits in one of four states. Figure F04-1 shows the states and the approval gates between them.

The rules for moving between states are fixed in the project information standard. On most hyperscale programmes the usual practice is as follows.

1. WIP to shared. The author completes a self-check, and the task team lead reviews the container against the naming rules and the content checklist. The container then moves to shared with a suitability code S1 to S4. The revision drops the WIP version suffix (P01.03 becomes P01).
2. Shared to published. The lead appointed party authorises the container and the appointing party accepts it. The container receives a published code (A1 to An, or B1 to Bn for partial sign-off) and, for contractual issues, a C revision.
3. Published to archived. When a new revision is published, the previous one moves to the archive automatically. The archived revision stays readable and is marked superseded.
4. Rejection. A container that fails review returns from shared to WIP. It keeps its P revision, and the author increments the version suffix while correcting it.

Check: Open three published drawings for the MV switchroom of building 2 in the CDE. Confirm that each one shows a published status code, a C revision and a reviewer approval record with a date. A published drawing with a P revision and an A status is a configuration error in the CDE and must be raised with the information manager.

04.2.3Information requirements that drive the CDE

ISO 19650 links the CDE to a chain of requirement documents. The CxM needs to know them because commissioning deliverables are listed in them.

Common errors: The EIR does not list commissioning records, so the Level 3 to Level 5 checklists and test reports are delivered as loose PDF files outside the CDE. Correct this at appointment stage by adding a commissioning deliverables table to the EIR. The table names each record type, its format (native and PDF), its naming type code and the milestone at which it is due.

04.3Suitability codes, published codes and revision codes

04.3.1Suitability (status) codes

The status code says what the information in a container may be used for. It does not say whether the content is correct. The codes below follow the UK National Annex to ISO 19650-2 as implemented in the Autodesk Construction Cloud naming standard. Older guidance documents show different text for S4 and S5, so the project information protocol must state the code list in force.

A drawing with code S2 must never be used to build or to test. On a commissioning programme the most common error is a test engineer printing an S2 "for information" single-line diagram to write a test script. The script is then based on a design that has not been accepted.

04.3.2Revision codes

The National Annex guidance uses two integers with a letter prefix:

1. P revisions. P01, P02 and onward are preliminary (non-contractual) revisions used while a container is shared. A WIP container carries a version suffix after a full stop: P01.01, P01.02, P01.03.
2. C revisions. C01, C02 and onward are contractual revisions used when a container is published with an A code or as a CR record.
3. Version suffix dropped on sharing. When a WIP container is shared, the version suffix is dropped. After five WIP versions the sequence is P01.01, P01.02, P01.03, P01.04, P01.05 and then P01.
4. No reuse. A revision code is never reused for different content. If a published C02 is found to be wrong, the correction is C03.
5. Separate from status. The revision code and the status code are separate metadata fields. Most CDE platforms keep them as attributes and show them in the title block; they are not part of the file name in the seven-field identifier.

Worked example: In the MSC-1 worked example, the 20 kV switchgear single-line diagram for building 2 has the following history in the register.

The site team holds C02 from 15 June. The C01 prints are removed from the switchroom drawing rack within 1 working day of the C02 transmittal (section 04.9).

04.3.3Legacy BS 1192:2007 codes

Many suppliers, older templates and some Asian and Middle Eastern projects still use the codes of BS 1192:2007, which was withdrawn when ISO 19650 was published. The main differences are listed below. The exact text of each legacy code must be taken from the project's own information protocol, because projects modified the list.

Common errors: A supplier's drawing arrives with revision "C" and status "AB". The document controller maps it to the project scheme (for example C01 and CR) in the metadata. The document controller records the supplier's own revision in a separate "originator revision" field and leaves the supplier's title block unchanged.

04.4Naming information containers

04.4.1The seven fields

The container identifier is built from seven fields separated by hyphens. Each field is applied in the order shown. Figure F04-2 shows the anatomy of one MSC-1 identifier.

The full identifier is MSC1-EDC-B2-00-DR-E-2101. The revision (C02) and the status (A3) are held as metadata and printed in the title block.

Two codes have fixed meanings in fields 3 and 4: ZZ means all volumes or multiple locations, and XX means no volume or no applicable location. A campus-wide specification that applies to every building is MSC1-EDC-ZZ-XX-SP-E-0001.

04.4.2Type codes and role codes

The project code list is issued by the information manager. The National Annex guidance gives the recommended type codes, and the project may add codes. The codes most used on a data-centre commissioning programme are listed below.

The National Annex list has no separate code for commissioning or for controls. Most data-centre programmes add project codes, for example "CX" for commissioning, "BM" for building management system (BMS) and "PM" for the electrical power monitoring system (EPMS). A two-character role code is allowed because field 6 is 1–2 characters long. The CxM asks the information manager to add these codes before the first Cx document is issued, so that Cx records do not appear under "Z".

04.4.3Volume and level codes for a campus

A campus needs a clear volume code list before any document is issued. The MSC-1 worked example uses this list.

The level codes are 2 characters. "RF" for roof is a project code. The basement code "B1" is the National Annex example code for basement level. "B1" is also building 1 in field 3, and the position in the identifier removes the conflict. The document controller must not shorten the identifier.

04.4.4Naming equipment tags and documents together

The container identifier names the document. The equipment tag names the asset. Commissioning records link the two. The tag format is set in the asset information requirements. In the MSC-1 worked example the tag format is building, hall, system, equipment and number, for example B2-DH3-UPS-A1 (building 2, data hall 3, UPS system A, unit 1). The document identifier for the Level 3 pre-functional checklist of that UPS is MSC1-CXA-B2-01-RP-CX-3051, with the tag B2-DH3-UPS-A1 in the metadata field "Asset tag".

Worked example: The CxM needs to know how many identifiers to reserve for Level 3 checklists in building 2. Building 2 has 3 halls, each with 8 block UPS systems, 16 CDUs and 8 block transformers (MSC-1 ledger). The count of Level 3 checklists is 3 × (8 UPS + 16 CDU + 8 transformers) = 3 × 32 = 96 checklists for these three equipment types. The CxM reserves the number range 3001 to 3200 under type RP and role CX for Level 3 checklists in volume B2. This range leaves 104 numbers for the other systems in the building (switchboards, BMS controllers, fire systems). If the total exceeds 200, the range 3201 to 3400 is reserved before the range runs out.

04.4.5Steps to check a name before upload

Purpose: Stop wrong names entering the CDE, where they break search, transmittals and the MIDP.

Owner: Document controller of the originating organisation.

Steps:

1. Split the identifier into fields. Count seven fields separated by six hyphens. A missing field or an extra hyphen fails the check.
2. Check each field against the code list. Compare fields 1 to 6 with the current project code list (MSC1-KIM-ZZ-XX-SH-K-0002 in the worked example). An unknown code fails the check.
3. Check the number against the MIDP. The number must exist in the MIDP or the TIDP for that originator and type. A number not in the plan is raised with the task team lead within 1 working day.
4. Check the title block. The identifier, revision, status and title in the title block must match the metadata entered in the CDE character for character.
5. Check the file name. The file name equals the identifier, with no revision or status added (for example MSC1-EDC-B2-00-DR-E-2101.pdf). Platforms that store revision as metadata reject duplicate names with different revision suffixes.
6. Upload to WIP or to the shared area as the workflow requires. Record the upload in the register with the date.

Acceptance: All six checks pass. Most CDE platforms (for example the ACC naming standards function) can enforce fields 1 to 6 automatically and place non-compliant files in a holding area.

Records: CDE upload log; naming exceptions log with the reason and the person who approved each exception.

04.5Document register, drawing register and metadata

04.5.1Document register fields

The document register lists every container and its current state. Each CDE platform has its own field names. The fields below are the minimum the CxM needs to trace a commissioning document.

04.5.2Drawing register fields

The drawing register is a filtered view of the document register for drawing types (DR, M2, M3). It adds the fields needed on site.

04.5.3Example register extract

Figure F04-4 shows this extract with the current and superseded rows marked.

Check: The row for MSC1-UPS-B2-01-DR-X-0031 has status S3 and review code C. That drawing is still under review. No Level 2 wiring inspection of UPS B2-DH3-UPS-A1 may be signed against it, and the CxM records the dependency in the Cx programme.

04.6Review status codes and what each code allows

04.6.1The A, B, C, D scheme

Many contracts in Asia and the Middle East use a four-letter review code for contractor documents (shop drawings, submittals, method statements). The wording is set by each contract's specification. The table gives the usual meaning and the action each code allows.

Under code B the contractor proceeds and incorporates the comments; under code C fabrication of the affected items stops until the resubmission is returned with code A or B.

Some specifications add more codes. UFGS 01 33 00 (the United States unified facilities guide specification) uses five codes: A approved as submitted, AN approved as noted, RR disapproved as submitted and resubmit, NR not reviewed, and RA receipt acknowledged (for informational submittals). The mapping to the four-letter scheme is: A to A, AN to B, RR to C or D, NR and RA have no equivalent and must be listed separately in the register.

04.6.2Rules the CxM applies to review codes

1. One code per document. A package with several drawings may have a different code for each drawing. The transmittal lists the code per drawing.
2. Comments are numbered. Every comment has a number, a location (sheet, grid, cloud) and a required action. A comment that only says "check" is not accepted.
3. Code B comments are tracked to closure. The register keeps a comment count and a closed count. A code B drawing with open comments may be built, but the Level 2 inspection checks the comments.
4. Code C stops dependent work in the Cx programme. The CxM marks every checklist and test that depends on a code C document as blocked, with the document identifier as the reason.
5. No verbal codes. A review code given in a meeting is recorded in minutes but is not valid until the stamped document is returned through the CDE.
6. Approval does not transfer design responsibility. Under most contracts a review code does not relieve the contractor of responsibility for errors in its documents. The exact wording is in the contract (for example, FIDIC 2017 Yellow Book Sub-Clause 5.2; the governing wording is in the Particular Conditions of the signed contract).

04.6.3Comment response sheet fields

04.7Transmittals

04.7.1What a transmittal is

A transmittal is the formal record that a defined set of documents, each at a defined revision and status, was sent from one organisation to another for a stated purpose on a stated date. In Oracle Aconex, a transmittal updates the recipients' document registers as part of the audit trail. Project mail is used for correspondence, and a document attached to mail is not registered. On every platform the rule is the same: a document issued for use must travel on a transmittal. An email attachment is an uncontrolled copy.

04.7.2Transmittal fields

04.7.3Transmittal workflow and time limits

Figure F04-3 shows the transmittal workflow as a swimlane between the originator, the document controller, the receiving organisation and the site.

Trigger: A document reaches a state or status that must be communicated (shared for review, published for construction, returned with a review code, issued as a record).

Owner: Document controller of the sending organisation.

Steps:

1. Prepare the issue list. The originator lists the identifiers, revisions and purpose. Time limit: same working day as the approval.
2. Check names and metadata. The document controller checks each container (section 04.4.5) and the status and revision against the approval record. Time limit: 1 working day.
3. Raise the transmittal. The document controller creates the transmittal in the CDE, attaches the containers, enters the purpose, the response due date and the superseded list.
4. Send and log. The CDE sends the transmittal and updates the register. The register shows the new revision as current.
5. Acknowledge. The receiving document controller acknowledges receipt. Time limit: 1 working day for construction issues, 2 working days for other purposes.
6. Distribute internally. The receiving document controller sends the documents to the named users and to site. Time limit: 1 working day.
7. Withdraw superseded copies on site. The site engineer removes or stamps the old prints (section 04.9). Time limit: 1 working day for construction issues.
8. Close. The sending document controller closes the transmittal when every acknowledgement is in. Unacknowledged transmittals older than 3 working days are reported in the weekly document control report.

Acceptance: Every recipient has acknowledged; the register shows the new revision as current; the site withdrawal record is signed.

Records: transmittal record with acknowledgements; site withdrawal record (section 04.9.2).

Common errors:

1. Purpose of issue left blank. The receiver cannot tell whether an S3 drawing is for review or for construction. The CDE template must make the purpose a required field.
2. Superseded list missing. The site keeps both revisions. Make the superseded list a required field for every construction issue.
3. Transmittal sent to a person who has left the project. Acknowledgement never arrives. The document controller updates the distribution matrix weekly from the project directory.
4. Large packages. A transmittal with 300 drawings is not reviewed properly. Some platforms limit the number of documents per transmittal; split large issues by system and building.

04.7.4Distribution matrix

The distribution matrix says which roles receive which document types. The table is an extract from the MSC-1 worked example.

Worked example: Revision C02 of MSC1-EDC-B2-00-DR-E-2101 is published on 15 June at 14:20. The distribution matrix sends it to the general contractor, the MV subcontractor, the CxM (construction), the CxA (review) and the BMS integrator and owner operations (information): 6 organisations. Acknowledgements arrive from 5 organisations on 15 and 16 June. The BMS integrator acknowledges on Friday 19 June. Counting 15 June as day 0, 16, 17, 18 and 19 June are working days 1 to 4. The acknowledgement took 4 working days against the 1 working day limit for construction issues and passed the 3 working day reporting threshold. The transmittal appears on the weekly overdue list. The document controller records the reason given by the integrator (the person named in the matrix was on leave). The matrix is updated to include a second contact.

04.8Review cycle time limits and turnaround KPIs

04.8.1Time limits set by contracts and specifications

The review period is set by the contract. The CxM must read the contract clause and the specification section before agreeing a review schedule. The table lists published values from common forms.

Before the first submission, the CxM confirms whether the contract counts working days or calendar days and records the answer in the Cx plan. A 14-calendar-day period over a public holiday week in Jakarta (for example the Idul Fitri collective leave) can contain only 6 or 7 working days.

04.8.2Turnaround KPIs

The document control report shows the following measures each week. Each measure has a definition that can be calculated from the register.

04.8.3Calculating turnaround and the due date

Figure F04-5 shows the review cycle of this worked example on a working-day axis.

Worked example: The UPS subcontractor submits MSC1-UPS-B2-01-DR-X-0031 P02 on Monday 6 July 2026 at 16:00. The contract states a review period of 10 working days counted from the next working day after receipt, and the project calendar has no holiday in July. Day 1 is Tuesday 7 July, so the due date is Monday 20 July (working days: 7, 8, 9, 10, 13, 14, 15, 16, 17 and 20 July). The reviewer returns the drawing on Thursday 16 July with code C, which is 8 working days. The subcontractor resubmits P03 on Thursday 23 July. The second review is due on Thursday 6 August and is returned on Tuesday 4 August with code B (8 working days). The total elapsed time from first submission to approval is 6 July to 4 August, which is 21 working days. The UPS factory needs the approved control wiring drawing 6 weeks before the factory acceptance test (FAT). If the FAT is planned for 7 September, the latest approval date is 27 July. The approval on 4 August is 6 working days late. The CxM raises an early warning to move the FAT, or to accept a FAT with the wiring drawing at code B and the comments listed in the FAT procedure.

04.8.4Escalation for overdue reviews

1. Due date minus 2 working days. The CDE sends a reminder to the reviewer. The document controller lists the item in the daily look-ahead.
2. Due date. The design manager calls the reviewer and records a committed return date.
3. Due date plus 3 working days. The item is listed in the weekly project meeting with the committed date and the impact on the programme.
4. Due date plus 5 working days. The project manager writes to the reviewing organisation. The contractor may give a notice under the contract (for example a delay notice), as described in chapter 08.
5. Deemed approval clauses. Some contracts state that a document not reviewed within the period is deemed to have received no objection. The CxM checks the contract for such a clause. A deemed approval of a test script or a points list can bring an untested sequence to the integrated systems test (IST) stage.

04.9Superseded document control on site

04.9.1Why site copies need their own control

The CDE controls the electronic copies. Printed drawings in a switchroom, a tablet with downloaded files, and a test folder carried by a testing contractor are outside the CDE once they are printed or downloaded. Most errors in testing against old documents come from these copies.

04.9.2Site copy control procedure

Purpose: Confirm that every printed or downloaded document used on site is the current revision.

Owner: General contractor's site document controller, with the CxM for commissioning documents.

Steps:

1. Issue site copies from the CDE only. Each print carries a stamp "CONTROLLED COPY No. n" with the date printed and the revision. Uncontrolled prints carry "UNCONTROLLED, FOR INFORMATION ONLY".
2. Record each copy. The site copy register lists the copy number, the location (for example the drawing rack in MV room B2-00-MV1) and the holder.
3. Withdraw on supersession. Within 1 working day of a construction transmittal that supersedes a revision, the site document controller collects every controlled copy of the old revision. The controller stamps each copy "SUPERSEDED" with the date and either destroys it or files it in the superseded cabinet. The new revision is placed in the same location.
4. Use QR codes where available. A quick response (QR) code on each print links to the CDE record. Scanning the code on site shows whether the printed revision is still current.
5. Check tablets. Tablets used for checklists must open documents from the CDE in online mode or synchronise before each shift. Offline copies older than the last synchronisation are not used for sign-off.
6. Audit weekly. The site document controller and a CxM representative audit 20 printed documents chosen at random across the active rooms. Any superseded copy found is recorded as a document control non-conformance.

Acceptance: Zero superseded copies in the weekly audit; site copy register matches the drawing register.

Records: site copy register; superseded withdrawal record; weekly site document audit sheet.

04.9.3Site document audit sheet fields

Common errors: Test engineers bring their own printed test scripts from the office. The CxM requires every script used in a witnessed test to carry the controlled-copy stamp, and the witness checks the revision against the CDE before the test starts (chapter 07).

04.10Redlines and as-built control

04.10.1Redline rules

A redline is a mark-up on a controlled site copy that records a difference between the installed work and the drawing. Redlines are the input to the as-built drawings.

1. Use one master redline set per drawing. The site keeps one master redline copy per drawing, identified as RL-identifier-sequence (for example RL-B2-E-2101-01). Redlines on other copies are transferred to the master within 1 working day.
2. Use fixed colours. Red for additions, green for deletions, blue for notes that are not part of the drawing. The colour convention is printed in the legend of the master copy.
3. Reference the authority. Each redline carries the authority for the change: RFI number, site instruction, NCR or variation number. A redline with no authority is a deviation and is raised as an NCR (chapter 09).
4. Date and initial each redline. The person recording the change and the date are written next to the cloud.
5. Record measured values. Cable routes, valve positions, sensor locations and spare ways are recorded with measured dimensions or panel positions.
6. Electronic redlines. Where markups are made in a shared PDF session (for example a Bluebeam Studio Session), the session record keeps the author and time of each markup. Each markup can be edited only by its author. The master redline set is exported from the session at each milestone.

04.10.2As-built process

Trigger: A system reaches Level 3 sign-off, or the contract milestone for as-built drawings.

Owner: The contractor who produced the drawing, with the design consultant where the contract requires the designer to update its own drawings.

Steps:

1. Freeze the redline set. The master redline set for the system is scanned and uploaded to the CDE with status S2 and type DR, linked to the drawing.
2. Incorporate. The author updates the native file and issues it at status S3 for review with all clouds and the authority references.
3. Verify on site. The reviewer, with the CxM for commissioned systems, checks a sample on site. For the MSC-1 worked example the sample is all MV and low-voltage (LV) switchgear schedules, all BMS points schedules, and 10 % of cable routes.
4. Publish as CR. The approved as-built drawing is published with status CR and a C revision.
5. Close the redline set. The master redline copy is archived and the site copy register is closed for that drawing.

Acceptance: Every redline cloud is shown on the CR drawing or closed with a reason; the CR drawing matches the site sample.

Records: redline master set; as-built verification sheet; CR transmittal.

Worked example: The BMS points schedule for the CDU group in building 2 hall 3 (MSC1-BMC-B2-01-SH-BM-0004 C01) lists 16 CDUs with 42 points each, which is 672 points. During Level 3 testing, 3 points were added on each CDU (secondary loop leak detection status, filter differential pressure and pump 2 run hours), as instructed by RFI-B2-BMS-0087. The master redline shows 3 × 16 = 48 added points with the authority "RFI-B2-BMS-0087". The as-built schedule C02 lists 720 points. During verification the CxM compares the as-built schedule with the BMS database export: 720 points in both, with 0 differences in names and addresses. The schedule is published as CR at revision C03.

04.10.3As-built verification sheet fields

04.11CDE tools and what each is used for

04.11.1Tools on a commissioning programme

A hyperscale programme can use more than one platform. Figure F04-6 shows, for an example configuration, the tool in which each document class is drafted, the tool that holds the record and when a copy goes to the main CDE. The owner or the general contractor chooses the main CDE, and specialist tools are used for commissioning and for drawing mark-up. The table describes the functions that each vendor's documentation describes. The project information standard decides which tool holds the record for each document class.

Check: For each document class, the Cx plan names one tool as the record. A test script can be drafted and commented in Bluebeam. The approved version and its review code are held in the main CDE, and the executed test record is held in CxAlloy with a link to the script identifier and revision.

04.11.2Integration rules between tools

1. One identifier everywhere. The seven-field identifier and the asset tag are the same in every tool. CxAlloy equipment records carry the asset tag; checklists carry the document identifier in a reference field.
2. One record per document class. The register of the main CDE is the record for revision and status. Other tools show a copy and a link.
3. Export at milestones. Commissioning records are exported from CxAlloy as PDF and native data at each Cx level milestone and uploaded to the main CDE under type RP and role CX.
4. Access by role. Each tool assigns permissions to project roles. Named individuals receive a role. When a person leaves, the role is reassigned and the history stays intact.
5. Time zone and calendar. All tools use the project time zone (UTC+7 for Jakarta) and the same working-day calendar, so that due dates match across tools.

04.11.3Choosing the CDE configuration at project start

Purpose: Set up the CDE so that commissioning documents can be named, reviewed and found from the first day.

Owner: Information manager, with the CxM as a consulted party.

Steps:

1. Agree the folder or container structure. Use the volume code (building) and the discipline as the first two levels. Do not create folders per person or per company for published information.
2. Load the code lists. Fields 1 to 6 with the project additions (CX, BM, PM roles; RF level code).
3. Configure states and status codes. WIP, shared, published and archived areas with the S, A, B and CR codes. Restrict A codes to the approver roles.
4. Configure workflows. At minimum: design review, submittal review, method statement review, test script review, as-built review. Each workflow has a named role, a review period in working days and an escalation step.
5. Configure the transmittal template. Purpose of issue, response due date and superseded list as required fields.
6. Load the distribution matrix. By role.
7. Test the configuration. Upload 10 dummy containers through every workflow and confirm the register, the status, the revision and the notifications. The CxM signs the test record before the first live upload.

Records: CDE configuration record, test upload record signed by the information manager and the CxM.

04.12Commissioning documents in the CDE

04.12.1The Cx document set

The CxM owns a set of documents that must be held in the CDE with the same control as design documents.

04.12.2Rules for test scripts and checklists

1. Templates are published documents. Each checklist template has an identifier and a revision. An executed checklist records the template identifier and revision it was based on.
2. Executed records are new containers. Each executed checklist for one asset is its own container with its own number, linked to the asset tag. The template is never overwritten with test data.
3. Script changes during a test are redlines. If a step in a Level 4 script is changed during the test, the witness writes the change on the controlled copy, both parties sign it, and the script is revised afterwards. The executed record keeps the redlined copy.
4. Test data is kept in native form. Trend logs, power analyser files, thermographic images and BMS exports are attached to the executed record in their native format and as PDF.
5. Retest records are separate. A retest after a failed test is a new executed record with a reference to the failed one and to the Cx issue that was closed.

Worked example: The Level 4 test script for the CDUs of building 2 hall 3 is MSC1-CXA-B2-01-RP-CX-4012, revision C02, status A4. On 21 September the CxM executes the script on CDU B2-DH3-CDU-07. During step 18 (pump changeover on loss of pump 1), the script states a changeover time of ≤ 5 s, while the approved sequence of operations states ≤ 10 s. The witness and the contractor apply the sequence of operations value (the higher-order document). They record the redline on the controlled copy with both signatures and the authority "sequence of operations MSC1-BMC-B2-01-SP-BM-0002 C02, clause 4.3.2". The measured changeover time of 6.8 s is recorded as a pass. The CxM revises the script to C03 within 5 working days, and the remaining 15 CDUs are tested on C03.

04.12.3Document hierarchy for conflicts

When two documents disagree, the contract states the order of precedence. Where the contract is silent for commissioning documents, the usual practice on hyperscale programmes is the order below, and the conflict is raised as an RFI (chapter 05).

04.13Access, security, retention and handover

04.13.1Access rules

Data-centre drawings include security layouts, network diagrams and power capacity information. The usual practice is to classify these as restricted.

1. Classify at upload. The security class is a required metadata field (public, internal, restricted).
2. Restrict by role. Restricted containers are visible only to named roles. The operational technology (OT) network drawings (chapter 26) and the physical security layouts are restricted.
3. Watermark prints. Restricted prints carry the user name and the print date.
4. Review access quarterly. The information manager exports the user list and the role list and removes users who have left the project. The record is kept.
5. No personal storage. Documents are not stored in personal cloud folders or messaging groups. Photos of drawings sent through messaging applications are uncontrolled copies.

04.13.2Retention and archive

The archive holds every revision, transmittal, review comment and acknowledgement. The retention period is set by the contract and by law. The CxM confirms that executed Cx records, test data and calibration certificates of test instruments are included in the archive scope. Warranty claims and incident investigations after handover need these records.

04.13.3Handover of the record set

Trigger: Practical completion of a building, or the contract milestone for the asset information model. Figure F04-7 shows the five steps and the completeness count of the building 2 worked example below.

Owner: Information manager, with the CxM for commissioning records.

Steps:

1. Check completeness against the MIDP. Every container in the MIDP with a handover milestone has status CR or A code.
2. Check asset data. Each asset tag has the fields required by the AIR (manufacturer, model, serial number, installation date, warranty start, maintenance interval).
3. Check Cx records. Each commissioned asset has its executed Level 1 to Level 4 records and its system has a Level 5 record.
4. Authorise the AIM. The AIM containers are shared at S7 and authorised by the owner.
5. Transfer. The record set is transferred to the owner's operations CDE or CMMS on a transmittal with purpose "for record".

Acceptance: zero missing containers against the MIDP handover list; zero asset tags with missing required fields; owner acknowledgement of the record transmittal.

Worked example: In the MSC-1 worked example, building 2 has 1,940 containers in the MIDP with a handover milestone. At the completeness check, 1,902 are at CR or A code, 31 are at P revisions under review and 7 are missing. The completeness is 1,902 ÷ 1,940 × 100 = 98.0 %. The 38 open items are listed by originator with a due date. The owner does not authorise the AIM until the figure is 100 % or the owner accepts a listed exception for each open item.

04.14Audits, common errors and how to detect them

04.14.1Weekly document control audit

Purpose: Find document control failures before a witness test uses a wrong document.

Owner: CxM, with the general contractor's document controller.

Steps:

1. Sample the register. Pick 20 published documents used by tests planned for the next 2 weeks.
2. Check status and revision. Each must be at an A code with a C revision, or at the status the Cx plan allows.
3. Check transmittals. Each must have a construction transmittal with full acknowledgement.
4. Check site copies. Visit the locations listed in the site copy register and compare the printed revision.
5. Check test scripts. The scripts for the next 2 weeks must be at the approved revision, with the documents they refer to at the revision stated in the script header.
6. Record findings. Each finding is logged with an owner and a due date of no more than 2 working days.

Acceptance: zero findings on documents used in the next week's witness tests.

04.14.2Common errors table

04.15Checklist for site use

1. Code lists issued. The project code lists for all seven fields, including the CX, BM and PM role codes, are published before the first Cx document.
2. CDE configuration tested. Ten dummy containers have passed through every workflow, and the CxM has signed the test record.
3. Contract review periods recorded. The Cx plan states the review period for each document type and whether the contract counts working or calendar days.
4. EIR includes Cx records. The exchange information requirements list every Cx record type, format, type code and milestone.
5. Names checked before upload. Every upload passes the six-step name check, and exceptions are logged.
6. Status before use. Only A-coded documents with C revisions are used for installation and testing, unless the Cx plan states another rule for a named document type.
7. Review codes understood. All parties have the written meaning of codes A, B, C and D, and code C items are blocked in the Cx programme.
8. Comments tracked. Every code B and code C comment is recorded on a comment response sheet with a closure status.
9. Transmittals complete. Each construction transmittal has a purpose, a superseded list and acknowledgements within the time limits.
10. Distribution matrix current. The matrix is updated weekly from the project directory.
11. Site copies controlled. Prints carry controlled-copy stamps, the site copy register is current, and superseded prints are withdrawn within 1 working day.
12. Weekly site audit done. Twenty documents are audited each week with zero superseded copies found at the witness locations.
13. Redlines kept on master sets. Each redline has a colour, a date, initials and an authority reference.
14. As-built verified. Each CR drawing for a commissioned system has an as-built verification sheet.
15. Cx records in the CDE. Templates, executed records, test data and retest records are held as separate containers linked to asset tags.
16. Turnaround KPIs reported. The weekly report shows average turnaround, on-time percentage, overdue reviews and unacknowledged transmittals.
17. Access reviewed. Restricted containers are limited by role and the user list is reviewed each quarter.
18. Handover completeness measured. The MIDP handover list shows 100 % or an owner-accepted exception for each open item.

04.16Sources

1. ISO 19650-1:2018, Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM), Information management using building information modelling, Part 1: Concepts and principles, ISO, 2018. https://www.iso.org/standard/68078.html
2. ISO 19650-2:2018, Part 2: Delivery phase of the assets, ISO, 2018. https://www.iso.org/standard/68080.html
3. Centre for Digital Built Britain, BIM Toolkit National Annex Guidance (information container identification, field codification, status and revision codes), accessed 31 October 2026. https://www.cdbb.cam.ac.uk/files/national_annex_guidance.pdf
4. Autodesk, "Status Codes", Autodesk Construction Cloud Docs help (file naming standards), accessed 31 October 2026. https://help.autodesk.com/cloudhelp/ENU/Docs-Files/files/files-naming-standard/Status_Codes.html
5. Autodesk, "Revision Codes", Autodesk Construction Cloud Docs help, accessed 31 October 2026. https://help.autodesk.com/view/DOCS/ENU/?guid=Revision_Codes
6. Autodesk, "Create Naming Standards", Autodesk Construction Cloud Docs help, accessed 31 October 2026. https://help.autodesk.com/cloudhelp/ENU/Docs-Files/files/files-naming-standard/Set_Up_Naming_Standard.html
7. Designing Buildings Wiki, "Common data environment CDE" (status areas WIP, shared, published, archive), accessed 31 October 2026. https://www.designingbuildings.co.uk/wiki/Common_data_environment_CDE
8. BIM+ (CIOB), "Status codes: why the complexity", on the change from BS 1192 codes to ISO 19650 codes, accessed 31 October 2026. https://bimplus.co.uk/status-codes-why-complexity
9. Oracle Aconex Support Central, "What is the difference between a document, a transmittal, and a mail", accessed 31 October 2026. https://help.aconex.com/mail/what-is-the-difference-between-a-document,-a-transmittal,-and-a-/
10. Oracle Aconex Support Central, "Transmit documents" and "Register incoming mail received from outside Aconex", accessed 31 October 2026. https://help.aconex.com/documents/transmit-your-document/ and https://help.aconex.com/mail/register-incoming-mail-received-from-outside-aconex/
11. Procore, "Create a Submittal", Procore support documentation, accessed 31 October 2026. https://v2.support.procore.com/product-manuals/submittals-project/tutorials/create-a-submittal
12. Bluebeam, "Five things you may not know about Studio Sessions" and "Studio Sessions vs. Studio Projects Guide", accessed 31 October 2026. https://support.bluebeam.com/studio/how-to/tips-and-tricks/five-things-you-may-not-know-about-sessions.html and https://support.bluebeam.com/articles/studio-and-bluebeam-cloud-comparison-guide
13. CxAlloy, "Commissioning project management", product documentation, accessed 31 October 2026. https://www.cxalloy.com/commissioning-project-management/
14. USACE, NAVFAC and AFCEC, UFGS 01 33 00 Submittal Procedures (review action codes, review periods, resubmittal numbering), Whole Building Design Guide, accessed 31 October 2026. https://www.wbdg.org/FFC/DOD/UFGS/UFGS%2001%2033%2000.pdf
15. FIDIC, Conditions of Contract for Plant and Design-Build (Yellow Book), Second Edition 2017, Sub-Clause 5.2.2 review period, as quoted in published contract amendments ("in Sub-Clause 5.2.2 first paragraph, '21 days' is deleted and replaced with '30 days'"), accessed 31 October 2026. https://www.lawinsider.com/clause/contractors-documents
16. NEC, "Period for reply" FAQ, neccontract.com, accessed 31 October 2026. https://www.neccontract.com/support/faqs/period-for-reply
17. BS 1192:2007+A2:2016, Collaborative production of architectural, engineering and construction information, Code of practice, BSI (withdrawn and replaced by BS EN ISO 19650). https://knowledge.bsigroup.com/products/collaborative-production-of-architectural-engineering-and-construction-information-code-of-practice
18. MSC-1 case ledger, ../case_ledger.json, Data Centre Commissioning Field Manual R01 working files, October 2026.
19. London Borough of Camden, contractor documentation requirements listing the BS 1192:2007 codes D1 for costing, D2 for tender, D3 for contractor design, D4 for manufacture or procurement, accessed 1 November 2026. https://camdocs.camden.gov.uk/CMWebDrawer/Record/5189673/file/document

Educational field reference compiled from public standards, guides, manufacturer documents and published incident reports; sources close each chapter. The project specification, the Engineer of Record and the OEM documents govern; check the current edition of every standard before use. Worked examples use an example campus (MSC-1: 4 buildings, 12 halls of 12 MW), not project data. Independent research; not affiliated with any current or former employer. Privacy · Terms.