Commissioning basics

How to Structure a Data Centre Commissioning Folder System

The folder structure is the least glamorous part of a commissioning programme, and one of the first things that goes wrong when nobody decides it up front.

Every commissioning programme generates a lot of documentation — design review records, test scripts, trackers, HSQE forms, handover certificates — and where all of that lives determines how easily anyone can actually find what they need, months into a project or years after handover.

Why this matters more than it seems

An unstructured or inconsistent folder system doesn't fail loudly. It fails quietly, in small ways, throughout a project — a test script that's hard to find during an audit, a tracker that exists in two conflicting versions, a new team member who spends their first week just figuring out where things are instead of doing commissioning work.

None of that is dramatic on its own. All of it adds up to real lost time, and it's entirely avoidable with a structure decided before the project starts generating documents.

Core sections a commissioning folder structure needs

Regardless of which specific framework a project uses, most commissioning documentation falls into the same functional categories:

• Administration — contacts, meeting minutes, correspondence
• Owner's requirements and design basis — OPR, Basis of Design, design reviews
• Commissioning planning — the CIP, hold points matrix, RACI, programme
• Design review — commissionability reviews by discipline, with a findings register
• Factory testing — witness plans, trackers, test scripts by discipline (Level 1)
• Installation verification — check sheets, ITP guidance, snagging (Level 2)
• Systems testing — test scripts and trackers by discipline (Level 4)
• Integrated testing — scenarios, schedule, scripts
• Asset and tag register — equipment register, tag schedule
• HSQE — forms, incident log, permits
• Handover and closeout — punch list, handover certificate, as-builts, training records
• Reference library — standards, naming conventions, master template copies

Keep it framework-agnostic

It's tempting to name folders after a specific client's staged framework — L1_FAT, L2_SAT, and so on. This works fine until you move to a project with a different client using a different staging system, at which point the whole structure needs rebuilding rather than reused.

A more durable approach is to name folders by function — 04_FACTORY-TESTING rather than L1 — and maintain a simple mapping table showing how your structure's stages correspond to whatever framework a given client uses. The structure survives moving between projects; only the mapping changes.

The most common mistake

Improvising the structure on day one of a project, under time pressure, with the intention of "tidying it up later." Later rarely comes — by the time anyone has time to reorganise, dozens of documents already reference the original, inconsistent paths, and fixing it costs more than getting it right at the start would have.