Base build now, suites and cages on a schedule of their own
Colocation commissioning software for facilities that hand over capacity to tenants in stages, not all at once.
A colocation facility commissions its base build — power, cooling and BMS — once, then repeats a smaller commissioning cycle for every suite, cage or pod as tenants take capacity. Deskely keeps the base build register and the per-tenant SLA acceptance records connected, so a new suite can be proven against the shared infrastructure without re-litigating what the base build already demonstrated.
- Scope
- Base build plus per-suite fit-out
- Parties
- Operator, MEP, tenant reps
- Cadence
- Continuous suite hand-offs
- Gate
- SLA acceptance per suite
Choose your project type
The problem
The base build is proven once, but every new tenant wants their own proof.
A colocation operator commissions the shared UPS, switchgear, chiller plant and BMS during base build, then has to demonstrate to each incoming tenant that the capacity, redundancy and monitoring they're paying for actually holds for their suite specifically.
Without a shared register, every tenant acceptance becomes a fresh spreadsheet exercise, re-proving facts about shared infrastructure that were already established months earlier.
Deskely keeps the base build record set as the foundation every suite's acceptance references, so tenant SLA testing only has to prove what's actually new: the suite's PDUs, cooling units and monitoring points.
Setting up the register
Base build infrastructure and tenant white space are separate subsystems with a shared dependency.
Utility switchgear, generators, UPS, chiller plant and the site-wide BMS/EPMS sit in the base build subsystem; each suite, cage or pod is its own subsystem referencing the base build systems it draws from.
Single-line diagrams and mechanical schedules for both base build and each fit-out are parsed into the register, so a suite's PDU is tagged against the upstream busway and UPS it depends on.
That link is what lets a new suite's acceptance certificate cite the base build's Level 4/5 test results instead of re-testing shared plant every time a tenant signs a lease.
Per-suite SLA acceptance
Load bank testing, power quality and cooling capacity are proven against the SLA the tenant actually signed.
Suite-level acceptance runs load bank tests against contracted kW, verifies redundant power paths to the rack (A/B feed, dual PDU), and confirms CRAC/CRAH capacity and containment against the design heat load for that suite.
Punch raised during suite acceptance is categorised against whether it blocks the tenant's go-live date, distinct from base build punch that may still be open elsewhere on the floor.
Because every suite follows the same templated record set, the tenth suite handed over takes the same rigour as the first without taking the same time.
Hand-off to the tenant
Each tenant receives a dossier scoped to their suite, not the whole facility.
Tenants rarely need or want visibility into the operator's whole facility register — they need evidence that their own suite meets the contracted SLA: redundancy, capacity, monitoring points and response commitments.
Deskely exports a per-suite dossier referencing the shared base build evidence it depends on, which satisfies audit and due-diligence requests without exposing the rest of the facility's records.
The same structure supports re-certification when a tenant expands or the operator upgrades shared plant, because the dependency between suite and base build is already modelled.
The SLA is a legal document, not a target
Every minute of downtime against the SLA has a financial consequence, and the operator has to be able to prove the number before the tenant disputes it.
A colocation contract's uptime guarantee — 99.99%, 99.999%, whatever the tier — is backed by service credits the operator pays out the moment a tenant's suite drops below the contracted availability, and the first thing a dispute turns on is whether the operator can produce dated, signed evidence of what the infrastructure was actually delivering at the time.
SOC 2 Type II and ISO 27001 auditors ask the same underlying question from a different angle: not just whether a control exists, but whether there is a continuous, tamper-evident record proving it operated as designed across the audit period, for every suite, not a sample.
Deskely's per-suite acceptance record becomes that evidence base — load bank results, redundant feed verification and monitoring point history stay attached to the suite indefinitely, so an SLA credit dispute or an annual SOC 2 walkthrough is answered from the register rather than reconstructed from whichever engineer remembers the incident.
Evidence
The suite acceptance dossier
Colocation runs on continuous suite-by-suite hand-offs, each closed out against its own SLA, so the evidence pack for suite twelve has to stand alone from the base build pack rather than referencing it.
Suite-level power path verification report
The tenant's A and B feeds trace correctly to the contracted UPS and generator paths with no shared single point of failure
Before the suite is offered for tenant fit-out
Redundancy re-verification record
N+1 or 2N configuration at the shared plant level is unaffected by the new suite's load addition
After each suite energisation
Load bank commissioning report for the suite
The suite's contracted kW capacity is delivered and held stable at the rack level
Immediately prior to tenant SLA acceptance
Environmental monitoring and alarm verification
Temperature, humidity and leak detection points in the suite report correctly to the building management system
Ahead of suite handover
Level 5 integrated systems test extract for the shared plant
The shared UPS, generator and cooling plant serving the suite were previously proven under integrated failure scenarios
Referenced at each new suite acceptance
SLA acceptance and witness pack
The suite meets the tenant's contracted uptime and capacity commitments with the operator's evidence attached
Final gate before the suite goes live
How it runs
From a proven base build to the next suite going live.
Colocation is a continuous commissioning operation, not a single project — the register has to support that from day one.
- 01
Commission the base build once
Utility, generator, UPS, chiller and BMS subsystems proven through Level 4/5 and held as the shared reference.
- 02
Model each suite as a subsystem
Cages, pods and suites tagged against the base build systems they draw power and cooling from.
- 03
Template the SLA record set
Load bank, power quality, redundant feed and cooling capacity records defined once per suite type.
- 04
Run acceptance per suite
SLA testing executed and signed on tablet at go-live, referencing base build evidence rather than repeating it.
- 05
Export a scoped dossier
Per-tenant handover pack built from the suite's own records plus the base build dependencies it cites.
FAQ
Questions about Colocation facilities scopes.
Keep reading
Data centre commissioning
The full sector view: commissioning levels, integrated systems testing, punch and the certification ladder to IT load.
Read morePunch lists
Issues raised at the equipment during Level 3–5 testing, categorised by whether they block the next commissioning level.
Read moreWalkdowns
Pre-energisation and pre-IST inspections run as structured walks that raise punch on the spot.
Read moreOther data centre project types: Hyperscale new build data centres, Edge and modular data centre commissioning, Retrofit and capacity upgrade commissioning, UPS and power train commissioning, Cooling, CRAH/CRAC and liquid cooling systems, Standby generators, fuel and switchgear, White space rack, power and busway fit-out, Integrated systems testing and Level 5 commissioning, Campus substation and utility interconnection.
