1. Purpose and Scope
This reference document describes the GridCore colocation service model. It applies where the campus or platform operator provides managed data center service to compute tenants — delivering not only physical space and power, but a complete operating environment with defined cooling, connectivity, security, monitoring, support, and escalation interfaces.
This document is not a final MSA, SLA, service order, statement of work, or facility rulebook. Final service terms are project-specific and contract-specific. The document is intended to align commercial, technical, operational, and customer expectations before contracting and onboarding begin.
No content in this document constitutes a guarantee of capacity, a commitment of carrier availability, a representation of regulatory status, or a legally binding service commitment of any kind.
2. Service Model Premise
“In high-load AI and HPC environments, colocation cannot be reduced to square feet and megawatts. The service must define how power is reserved, delivered, cooled, monitored, released, supported, and governed over time.”
AI and HPC tenants operate differently from traditional enterprise colocation customers. Rack densities are frequently an order of magnitude higher than legacy norms. Workloads can shift between near-zero utilization and full load rapidly and repeatedly. Restart sequences generate large, fast load steps that affect the power and cooling delivery system simultaneously.
This load volatility affects generation dispatch, MV distribution stability, UPS loading, cooling thermal response, and operational risk. A colocation service model for high-density AI and HPC must capture not only the nameplate contracted load, but the actual operating behavior — including ramp rates, restart behavior, power factor, harmonic content where relevant, and thermal loading patterns.
The model should include a Dynamic Power Capability Schedule as part of the service order or SLA for tenants with non-trivial load dynamics. This protects both the customer and the campus operating team.
3. What the Customer Receives
The following table describes the reference service component framework. Actual scope is defined in the project-specific service agreement. Not all components are included in every colocation arrangement — scope is negotiated based on customer requirements and commercial structure.
| Service Component | GridCore / Campus Operator Responsibility | Customer Responsibility | Project-Specific Notes |
|---|---|---|---|
| Colocation space | Deliver commissioned, access-controlled data hall space | Equipment selection, rack configuration, internal cabling | Space type (rack, cage, suite, hall) defined in service order |
| Rack/cage/suite allocation | Assign and manage physical space allocation | Maintain within agreed physical envelope | Modifications require change order process |
| Power delivery | Deliver contracted capacity to agreed PDU or panel | Customer-side distribution from delivery point | Delivery voltage, metering, and redundancy defined in service order |
| Cooling delivery | Deliver cooling capacity against basis of design | Ensure equipment operates within approved thermal envelope | Cooling type (liquid, air, hybrid) defined per project |
| Liquid cooling interface | Provide CDU or manifold interface where scoped | Customer secondary loop, rack connections, manifolds as agreed | Fluid type, pressures, temperatures defined in cooling exhibit |
| Residual air cooling | Provide air cooling for residual and non-liquid heat loads | Ensure total heat load does not exceed design parameters | Density limits and air cooling capacity defined per build |
| Connectivity access | Provide campus MMR access and campus fiber to suite/cage | Procure carrier circuits; manage customer-side cabling | Carrier availability subject to project-specific diligence |
| Cross-connects | Manage cross-connect work order process | Submit cross-connect requests per process | Fees and lead times defined in service agreement |
| Security and access control | Operate campus and data hall access control; CCTV; visitor management | Manage tenant-side access credentials; comply with site rules | Access log retention; escort rules apply |
| Visitor management | Process all visitor registrations; verify identity; log access | Register visitors in advance; provide escort where required | Lead times and registration requirements in site rules |
| Remote hands | Perform defined physical tasks in tenant space upon request | Submit remote hands requests per process | Scope, response times, and fees defined in service agreement |
| Monitoring and reporting | Provide power, environmental, and incident reporting per service scope | Monitor customer-side systems; receive and act on campus reports | Portal access, data formats, and reporting frequency in SOW |
| Incident response | Triage campus infrastructure incidents; escalate per procedure | Triage customer equipment incidents; escalate to campus ops as needed | Escalation matrix and response targets in SLA |
| Maintenance coordination | Provide advance notice of maintenance windows affecting service | Schedule customer maintenance in coordination with campus | Maintenance window notice period defined in SLA |
| Tenant portal / operating interface | Provide portal for reporting, ticketing, and document exchange | Use portal per documented process | Portal capabilities and SLAs project-specific |
| Load release support | Coordinate staged load release; sign off at each gate | Provide load profile; participate in staged load approval | Load release process defined in commissioning exhibit |
| Documentation package | Provide relevant as-built documentation for scoped infrastructure | Maintain customer equipment documentation | Document types and format defined in handover exhibit |
4. Colocation Product Forms
GridCore colocation can be structured across a range of product forms depending on tenant size, operational preferences, density requirements, and commercial structure.
Per-Rack Colocation
Best use: Smaller footprints, test environments, edge deployments
Cooling: Air-cooled; liquid-cooled rack available for high-density
Customer profile: Enterprise, smaller AI/ML teams
Contractual complexity: Low to medium
High-Density Pod
Best use: AI/HPC clusters requiring liquid cooling and concentrated power
Cooling: Liquid-cooled required; dedicated cooling infrastructure
Customer profile: AI labs, model training operators, HPC clusters
Contractual complexity: Medium to high
Private Cage
Best use: Isolated physical environment within a shared hall
Cooling: Shared hall cooling; liquid upgrade where available
Customer profile: Regulated industries, compliance-sensitive tenants
Contractual complexity: Medium
Private Suite
Best use: Fully enclosed, dedicated data room within the building
Cooling: Suite-level cooling delivery; thermal envelope defined
Customer profile: Larger enterprises, managed service providers
Contractual complexity: Medium to high
Dedicated Data Hall or Bay
Best use: Exclusive occupancy of a data hall section or bay
Cooling: Dedicated cooling per hall/bay; full design basis control
Customer profile: Large AI operators, cloud infrastructure tenants
Contractual complexity: High
Dedicated Building
Best use: Sole tenant of a commissioned building on the campus
Cooling: Full building cooling infrastructure delivered
Customer profile: Hyperscale or large enterprise customers
Contractual complexity: High; approaches powered shell in character
Build-to-Suit Colocation
Best use: Custom-designed space and infrastructure for specific tenant requirements
Cooling: Defined by tenant load profile and thermal requirements
Customer profile: Large, specialized compute deployments
Contractual complexity: Very high; requires detailed technical specification
Phased Reservation / Staged Load
Best use: Commercial reservation with capacity delivered in stages
Cooling: Cooling commissioned ahead of load release per phase
Customer profile: Growing AI operators, phased capacity strategies
Contractual complexity: Medium to high; requires load release milestone management
5. Power Service Framework
Power is the most operationally critical service component in a high-density colocation environment. The colocation power service framework must clearly distinguish between commercial reservation and technical load release — these are not the same event.
| Power Term | Meaning | Why It Matters |
|---|---|---|
| Reserved capacity | Commercially committed power allocation | Establishes the customer's right to capacity; does not mean technically available or commissioned |
| Installed capacity | Power equipment installed and capable of energization | Infrastructure exists, but may not be commissioned or load-released |
| Commissioned capacity | Power systems tested, verified, and approved for operation | Commissioning evidence on file; system is ready for load acceptance |
| Released load | Power that has been formally approved for actual tenant load | The only category the tenant should power up to; governed by load release process |
| Contracted maximum demand | The peak power level the customer may draw under the service agreement | Basis for power infrastructure sizing and billing maximum |
| Dynamic power capability | The defined operating envelope for load ramp and step behavior | Protects the campus power and cooling systems from unexpected transients |
| Load step | A single event where load increases by a defined increment | Affects generation dispatch, UPS loading, and cooling thermal response simultaneously |
| Ramp rate | The permitted rate of change of load over time | Drives cooling response time requirements and generation control logic |
| Maintenance derate | Temporary reduction in available capacity during maintenance windows | Customer must operate within derated limits during scheduled maintenance |
| Emergency curtailment | Operator-directed load reduction during abnormal conditions (where applicable) | Scope and triggers must be explicitly defined in service agreement if applicable |
A commercial reservation is not technical load release. Tenants must not energize equipment based on reservation alone. Load release is a formal gate that requires verified commissioning, safety review, and operating approval.
6. Dynamic Power Capability Schedule
High-density AI and HPC tenants frequently have load profiles that are fundamentally different from traditional enterprise colocation customers. The Dynamic Power Capability Schedule (DPCS) is a service order exhibit that defines the operating envelope for a specific tenant's load behavior.
The purpose of the DPCS is to align expectations and protect both the customer and the campus operating team. Without it, unexpected load behavior can damage generation equipment, trip distribution protection, overwhelm cooling thermal response, or create operating risk for other campus tenants.
| Tier | Intended Workload Behavior | Example Ramp Profile | Customer Controls | Operational Treatment |
|---|---|---|---|---|
| Stable / Predictable | Constant or slowly varying load; minimal transients | Gradual ramp over extended period; no sudden steps | Standard power controls; no special scheduling required | Standard operations; campus power system managed for steady load |
| Moderately Dynamic | Regular variation in load; moderate ramp events | Defined step size with minimum interval between steps | Load scheduling coordination encouraged; notification for major changes | Pre-notification for large load steps; cooling pre-conditioning where appropriate |
| Highly Dynamic | Frequent, rapid load steps; restart-driven transients | Defined maximum step size; minimum step interval enforced | Automated or manual load controls required; restart procedure defined | Active monitoring; campus power and cooling team pre-informed of major events |
| Special Review | Novel workload type or behavior outside standard tiers | Requires individual analysis and approval before deployment | Engineering review and commissioning validation required | Enhanced monitoring; dedicated commissioning phase before steady-state release |
This table is illustrative. Specific ramp rates and step profiles are not fixed GridCore standards — they are project-specific and must be defined through technical review of the specific tenant's hardware, workload type, and operating procedures.
7. Cooling Service Framework
Cooling is delivered against a project-specific basis of design. The colocation operator must define the cooling envelope before tenant equipment is specified, approved, or installed. Equipment that operates outside the defined cooling envelope cannot be accepted.
| Cooling Domain | Service Definition | Customer Interface | Key Acceptance Evidence |
|---|---|---|---|
| Facility cooling plant | Campus-level heat rejection equipment providing cooling capacity to the building | Customer receives cooling at defined building-level interface conditions | Commissioning reports; capacity test; redundancy demonstration |
| Liquid loop / building interface | Campus or building liquid loop delivering coolant to CDU connection points | Customer connects to manifold at defined supply/return conditions | Pressure test; flow verification; temperature setpoint confirmed |
| CDU / manifold interface | Campus-supplied CDU or manifold interface where scoped | Customer connects server-side liquid to manifold ports | CDU commissioning; leak test; flow and temperature calibration |
| Rack-level liquid distribution | Rack hoses, quick-connects, and server connections | Typically customer responsibility; must meet approved equipment list | Customer installation inspection; leak test before energization |
| Residual air cooling | CRAC/CRAH or precision cooling for non-liquid heat loads | Customer ensures rack layout does not exceed air cooling capacity | Airflow commissioning; hot-spot scan; containment verification |
| Environmental monitoring | Temperature, humidity, and dew point monitoring in data hall | Customer receives alerts for out-of-envelope conditions | Sensor calibration; alarm test; integration with ops monitoring |
| Leak detection | Under-floor or overhead leak detection where scoped | Customer notified on alarm; must respond per escalation procedure | Sensor placement review; system function test; alarm response drill |
| Thermal load step validation | Verification that cooling system responds correctly to load increase events | Customer participates in staged load commissioning | Thermal step test records; cooling response time documented |
8. Space and Physical Configuration
Physical space configuration must be documented before customer equipment arrives. Unauthorized modifications to the physical environment — including rack placement, overhead cabling routes, containment changes, or liquid piping modifications — require a change approval process.
- Rack rows and aisles: Hot/cold aisle configuration, rack spacing, and containment arrangement defined in the space design exhibit.
- Cages and suites: Physical boundaries, access points, and interior configuration defined in the allocation document.
- Overhead fiber and cabling: Defined cable ladder and tray routes; customer cannot add routes without approval.
- Power distribution: PDU placement, circuit assignments, and breaker labeling defined and documented.
- Liquid piping access: Manifold locations and access clearances must be maintained by customer.
- Equipment delivery path: Defined loading dock, freight elevator, and staging area for equipment moves.
- Service clearances: Minimum clearances for electrical, cooling, and safety equipment access must be maintained at all times.
- No modifications without approval: Customer may not alter data hall infrastructure without written change approval from the campus operator.
9. Connectivity Service Framework
GridCore campuses are designed to support carrier-neutral access where available. The campus provides the physical infrastructure framework — carrier availability at any specific site is a diligence item, not a guaranteed service.
- Campus meet-me rooms: MMR A and MMR B provide physical carrier access points. Route diversity is supported where feasible.
- Cross-connect process: All cross-connects are managed through a formal work order process. Lead times and fees apply.
- Tenant demarcation: A documented demarcation point defines the boundary between campus network infrastructure and customer network responsibility.
- Inter-building fiber: Campus dark fiber connects buildings. Customer procures cross-connect circuits for inter-building connectivity.
- Carrier procurement: Customers procure carrier circuits directly. Campus facilitates access through the MMR but is not party to carrier agreements.
- Carrier availability diligence: Carrier presence at any campus is subject to commercial and technical due diligence. No carrier availability is guaranteed until confirmed through the project-specific diligence process.
10. Security and Access Model
| Access Domain | Description | Operator Responsibility | Customer Responsibility |
|---|---|---|---|
| Campus perimeter | Fenced perimeter with vehicle access control and CCTV | Operate and maintain perimeter security | Comply with access protocols; report breaches |
| Site access control | Manned or automated vehicle gate; identity check | Process and verify all site entrants | Register all personnel and visitors in advance |
| Data hall access | Two-factor or multi-factor access to data halls | Operate access control systems; maintain logs | Manage tenant credential assignments; report lost credentials immediately |
| Cage/suite access | Customer-controlled locks or access control within tenant space | Provide lockable boundary; CCTV of exterior | Operate and audit interior access; manage keys or credentials |
| Visitor management | Registration, identity verification, escort assignment | Process all visitors; maintain visitor log | Pre-register visitors; provide escort or request campus escort |
| Delivery access | Controlled access for equipment and supply deliveries | Manage delivery gate and dock access | Schedule deliveries in advance; comply with receiving procedures |
| Emergency responder access | Controlled emergency access for first responders | Maintain emergency access procedures and first responder relationships | Provide emergency contact information; comply with emergency procedures |
| Access logs | Digital logs of all access events by person, time, and location | Retain logs per defined policy | Request audit log extracts per defined process |
11. Monitoring, Reporting, and Portal Interface
The colocation operating model includes a customer-facing portal or reporting interface that provides visibility into power usage, environmental conditions, incident status, and maintenance notifications. The specific capabilities of the portal are project-specific and defined in the service scope.
Real-time and historical power usage reporting
Temperature and cooling status reporting
Incident and ticket status tracking
Maintenance notice and maintenance window calendar
Access request and visitor registration workflow
Load release milestone tracking
Document exchange and handover record management
SLA compliance reports (scope-dependent)
Audit log access upon request
API or webhook integrations (where scoped)
12. Support and Operations
| Support Function | Included Baseline | Optional / Enhanced | Exclusions / Requires SOW |
|---|---|---|---|
| Facilities operations | 24/7 monitoring of campus infrastructure; response to infrastructure alarms | Dedicated facilities coordinator; enhanced reporting | Customer equipment troubleshooting |
| Remote hands | Standard defined tasks per work order process; standard response time | Priority response time; dedicated technician assignment | Complex IT work; specialized technical skills outside defined scope |
| Incident triage | Campus infrastructure incidents triaged and escalated per procedure | Enhanced reporting; customer escalation manager | Customer-side IT incident resolution |
| Emergency escalation | 24/7 emergency contact; emergency response per SERP | Enhanced communication; dedicated emergency liaison | Customer emergency response decisions |
| Maintenance coordination | Advance notice of campus maintenance windows | Custom maintenance scheduling; impact pre-analysis | Customer maintenance planning and scheduling |
| Shipment support | Receiving dock coordination; delivery scheduling | Staging support; unboxing and staging assistance | Custom logistics management; procurement services |
| After-hours procedures | Defined after-hours contact process and escalation | Enhanced on-call coverage | On-demand staffing outside defined scope |
| Change management | Change request submission process | Change impact analysis; priority processing | Engineering design services for customer-requested modifications |
13. SLA and Service Credits Framework
This reference does not establish an SLA. It identifies service elements that may be measured in a project-specific SLA. Actual SLA terms, credit calculations, exclusions, remedies, and definitions are negotiated and documented in the applicable service agreement.
A colocation SLA may address some or all of the following service elements, depending on the commercial structure and project scope:
| Service Element | Potential SLA Treatment | Common Exclusions |
|---|---|---|
| Power availability | Measured uptime at defined delivery point | Customer equipment failure; utility outage beyond operator control; force majeure |
| Cooling availability | Measured delivery within defined temperature/pressure envelope | Customer load exceeding design basis; customer equipment fault; force majeure |
| Environmental conditions | Temperature/humidity within defined ranges | Customer-caused hot spots; equipment exceeding thermal design basis |
| Cross-connect availability | Uptime of campus-provided cross-connects | Carrier-side outages; customer equipment fault |
| Support response targets | Response time for defined incident severity levels | Customer-caused incidents; complex engineering investigations |
| Maintenance notice | Minimum advance notice period for scheduled maintenance | Emergency maintenance required for safety or imminent damage prevention |
| Reporting | Frequency and format of defined performance reports | Custom reporting outside baseline scope |
| Dynamic power schedule violations | Process for addressing load behavior outside agreed envelope | Customer actions required per notification procedure; consequences defined in agreement |
| Emergency safety actions | Campus may interrupt power or cooling for safety reasons | Not subject to SLA credit; safety overrides service level obligations |
14. Tenant Onboarding Lifecycle
The GridCore colocation onboarding lifecycle is a structured process designed to ensure technical and commercial alignment before any customer equipment is installed or energized.
01
Initial Capacity Discussion
Power, space, cooling, and connectivity requirements reviewed at high level. NDA in place.
02
Technical Exchange
Detailed load profile, hardware specifications, network requirements, and operating model shared.
03
Load Profile Review
Customer load characteristics reviewed: peak demand, ramp profile, restart behavior, power quality.
04
Design Review
Power, cooling, and network design reviewed for compatibility with campus delivery capabilities.
05
Commercial Scope Alignment
Service form, term, capacity, commercial structure, SLA, and key exhibits aligned.
06
Reservation or Service Order
Commercial commitment executed. Capacity reserved. Delivery timeline established.
07
Implementation Planning
Space plan, power plan, cooling interface, network plan, and delivery logistics coordinated.
08
Equipment Approval
Customer equipment list reviewed and approved against design basis and safety requirements.
09
Delivery Logistics
Equipment delivery scheduled through campus receiving process. Dock access confirmed.
10
Installation
Customer installs equipment under campus safety and site rules. Campus support as scoped.
11
Commissioning Support
Customer commissioning coordinated with campus systems monitoring and safety teams.
12
Staged Load Release
Load accepted in approved steps per the dynamic power capability schedule and readiness review.
13
Steady-State Operations Handoff
Service operating under SLA. Portal access confirmed. Escalation paths verified.
14
Post-Go-Live Review
Operating review covering power, cooling, network, incidents, and SLA performance within first 30–90 days.
15. Responsibility Matrix
| Domain | Campus Operator | Tenant | Joint / Coordinated |
|---|---|---|---|
| Power reservation | Define and confirm capacity allocation | Disclose accurate load profile; comply with agreed maximum demand | Load profile review; dynamic power schedule agreement |
| Load profile disclosure | Review and approve load profile | Accurate and timely disclosure; update when profile changes materially | Joint review; Dynamic Power Capability Schedule sign-off |
| Rack installation | Allocate and prepare space; inspect for compliance | Install racks per approved plan; comply with weight and clearance limits | Pre-installation walk-through; clearance verification |
| Customer equipment | Approve equipment list; inspect for safety compliance | Select, procure, install, and maintain equipment | Equipment approval process; physical inspection before power-on |
| Cooling interface | Deliver cooling to defined interface; monitor facility-side conditions | Connect to interface per approved method; maintain within approved envelope | Cooling commissioning; thermal load step test |
| Network circuits | Provide MMR access and campus fiber; manage cross-connect process | Procure and manage carrier circuits; manage customer-side network | Cross-connect coordination; demarcation agreement |
| Cross-connects | Process work orders; maintain cross-connect records | Submit work orders; maintain customer-side cabling | Joint cross-connect work order process |
| Security access | Operate and audit access control systems; maintain logs | Manage tenant credential assignments; comply with site rules | Credential provisioning; access policy training |
| Visitor requests | Process and approve all visitor registrations | Submit visitor registrations per process; provide escort as required | Visitor registration workflow; escort coordination |
| Remote hands | Perform defined remote hands tasks per work order | Submit and describe work orders accurately; scope tasks per agreement | Work order submission; scoping and approval |
| Maintenance windows | Notify tenants in advance; execute maintenance per procedure | Plan customer maintenance in coordination; minimize impact | Maintenance calendar coordination; impact pre-review |
| Incident response | Triage and respond to campus infrastructure incidents | Triage and respond to customer equipment incidents | Cross-domain escalation; joint post-incident review |
| SLA reporting | Produce SLA performance reports per agreement | Review reports; raise disputes per defined process | Monthly SLA review where scoped |
| Compliance evidence | Provide campus-level compliance documentation per scope | Maintain customer-side compliance records | Coordinated audit support where required by agreement |
| Decommissioning | Define decommissioning process; accept returned space | Remove equipment per decommissioning plan; restore space to agreed condition | Decommissioning plan coordination; final walk-through |
16. Commercial Packaging Considerations
GridCore colocation may be structured with a range of commercial components. The following are reference considerations only — actual fees, structures, and terms are project-specific and non-binding until documented in an executed agreement.
Reservation fee
Non-refundable or creditable fee to secure capacity allocation
Capacity deposit
Refundable security deposit against commercial obligations
Monthly recurring charge
Base service charge for space, power, cooling, and baseline support
Power billing
Metered pass-through, bundled rate, or blended power structure
Cooling premium
Additional charge for high-density liquid cooling or special thermal environments
Cross-connect fees
Per-circuit, monthly, or install-time fees for campus cross-connects
Remote hands fees
Per-task or monthly subscription for remote hands services
Install/onboarding fees
One-time charges for delivery, commissioning coordination, and onboarding support
Phased capacity release
Commercial milestones tied to staged capacity delivery and load release
Minimum commitment
Minimum term, minimum power draw, or minimum monthly charge
Termination/decommissioning
Notice periods, decommissioning obligations, and financial obligations on early exit
These commercial considerations are illustrative. They do not constitute a pricing disclosure, rate schedule, or commercial offer. Actual service scope, fees, SLA terms, remedies, operating obligations, customer responsibilities, and exclusions must be defined in the applicable agreement, service order, SLA, facility rules, and project-specific technical exhibits.
Implementation Notice
This reference describes a framework model. It is not a substitute for project-specific engineering, permitting, interconnection approval, environmental review, safety review, legal documentation, procurement, commissioning, or operating procedures. All capacity, availability, timeline, and commercial terms are project-specific and subject to applicable approvals and agreements.