1. Purpose and Scope
This reference defines the tenant onboarding framework for GridCore campuses. It is not a final MSA, SOW, SLA, service order, move-in procedure, customer handbook, load release certificate, or installation approval.
It is intended to align the customer, campus operator, commercial team, engineering team, network team, security team, safety team, facilities team, commissioning authority, and vendors around a structured onboarding process. Final onboarding requirements must be documented in project-specific agreements, tenant handbooks, site rules, service orders, technical exhibits, and approved operating procedures. This framework applies to turnkey colocation tenants, dedicated suite or building customers, powered shell customers where the campus has an operating interface, powered land customers where customer load interacts with campus power delivery, and carrier or network-related customers where applicable.
2. Onboarding Premise
AI/HPC onboarding is more complex than traditional cabinet delivery. Power density, load volatility, cooling interface design, installation logistics, equipment delivery sequencing, firmware and configuration timelines, network cutovers, and commissioning dependencies all affect whether a customer goes live safely and on time.
Onboarding must begin before equipment arrives. It should produce documented evidence at each stage — not just meeting notes and email threads. Customer go-live should be staged, measured, and formally approved at each load step. Commercial reservation of capacity is not the same as technical readiness for load.
3. Onboarding Lifecycle Overview
4. Stage 1: Initial Capacity Discussion
The initial capacity discussion should capture enough information to assess whether the customer and the campus are a fit — technically, commercially, and operationally. Key topics include the requested MW or kW, anticipated deployment timeline, ramp schedule, desired offering model, rack density assumptions, liquid or air cooling assumptions, network requirements, location and latency needs, security or compliance requirements, and commercial structure.
Outputs: initial requirements summary, customer fit assessment, and a follow-up diligence list. A reservation or preliminary discussion does not constitute an offer or commitment. Campus feasibility must be confirmed before commercial commitments are made.
5. Stage 2: NDA and Technical Exchange
A mutual confidentiality agreement should be in place before detailed technical and commercial information is exchanged. The technical exchange should produce a documented intake package capturing customer equipment specifications, network architecture overview, power and cooling assumptions, project schedule, commercial structure assumptions, and security questionnaire responses where applicable.
Outputs: technical intake package, document request list, defined meeting cadence, and single points of contact on both sides. A data room or secure document exchange may be appropriate for large or sensitive deployments.
6. Stage 3: Load Profile and Dynamic Power Review
High-density AI/HPC workloads must be reviewed not only by nameplate power but by operating behavior. Nameplate capacity describes the maximum theoretical draw — actual behavior in production depends on workload scheduling, GPU utilization patterns, cooling response, UPS interaction, and orchestration software.
| Load Attribute | Why It Matters | Customer Input Required | Operating Output |
|---|---|---|---|
| Nameplate load | Sets upper power delivery sizing basis | Equipment nameplate specifications | Confirmed in power service schedule |
| Expected steady-state load | Determines actual facility sizing and cooling basis | Actual average utilization at steady-state | Operational load assumption in SLA/SO |
| Maximum demand | Drives UPS, transformer, and breaker sizing | Peak demand window and duration | Power circuit design and breaker sizing |
| Ramp rate | Affects power quality and cooling lag response | Time from idle to full load, scheduler behavior | Dynamic power schedule tier assignment |
| Maximum load step | Single largest load change event | Largest single restart or job submission event | Power quality review, cooling response verification |
| Restart behavior | Post-failure restart can create simultaneous large load step | Restart sequencing, delay timers, batch size | Restart procedure documented in operating handoff |
| Workload scheduling | Scheduled jobs may create predictable large load changes | Job scheduler configuration, maintenance windows | Load shape documented, advance notice required |
| Power quality sensitivity | Some equipment is sensitive to voltage sag, harmonics, or flicker | Customer equipment specification, known sensitivities | Power quality design review, UPS configuration |
| Demand limiting | Can customer control load in response to campus request? | Demand limiting capability, response time | Demand response procedure if applicable |
| Failover behavior | Failover from primary to secondary may create transient load increase | Failover sequence, expected load change | Failover behavior captured in dynamic power schedule |
| Emergency shutdown | EPO or UPS bypass may create abrupt load disconnection | EPO location, scope, customer safety procedures | EPO coordination procedure, campus notification |
| Maintenance load state | Planned maintenance may change load significantly | Maintenance window requirements, typical load reduction | Maintenance notification process established |
7. Dynamic Power Capability Framework
Some customers should have a Dynamic Power Capability Schedule attached to their service order or SOW. This schedule documents permitted ramp behavior, notification requirements, abnormal load behavior definitions, customer-side demand controls, workload scheduling commitments, and the consequences of repeated load excursions outside the agreed envelope.
| Tier | Intended Workload Behavior | Example Characteristics | Customer Controls | Operational Treatment |
|---|---|---|---|---|
| Stable / Predictable | Load changes slowly and follows a predictable daily pattern | HPC batch, storage, rendering, scheduled training runs | Basic scheduler controls, maintenance window coordination | Standard monitoring, no dynamic schedule attachment required |
| Moderately Dynamic | Load changes occur within defined ranges and timeframes | Mixed inference/training, auto-scaling within limits | Demand limiting capability, advance notice for large changes | Dynamic power schedule with notification requirements |
| Highly Dynamic | Large, rapid, or unpredictable load changes | Large GPU cluster restarts, burst inference, simultaneous scale-out events | Active demand controls, workload stagger capability | Dynamic power schedule, load step monitoring, campus notification required for large events |
| Special Review | Load behavior cannot be characterized without additional analysis | Novel architecture, uncertain orchestration behavior, customer unable to characterize ramps | To be determined after review | Special commissioning protocol, phased approval |
Dynamic power behavior should be validated during staged load release, not assumed to be correct at full load. A customer whose actual behavior does not match their declared profile may require additional controls or a revised dynamic power schedule before load release approval is extended.
8. Stage 4: Power and Cooling Requirements Review
| Requirement Area | Customer Input | Campus Review | Output |
|---|---|---|---|
| Power capacity | Requested kW/MW, phased vs. immediate | Available and commissioned capacity review | Reserved capacity documented in SO |
| Voltage/interface | Customer equipment voltage requirements, single/three-phase | Power distribution design compatibility | Power circuit specification in Schedule I/J |
| Rack density | kW per rack, expected average and peak | Cooling system capacity per zone | Rack density envelope documented |
| Liquid cooling | CDU type, flow rate, supply/return temperature | Liquid loop capacity, CDU connection points | Cooling interface spec in Schedule K |
| Air cooling | Residual air cooling requirements | CRAC/CRAH capacity, hot aisle containment | Air cooling plan per zone |
| Redundancy | N, N+1, or 2N expectation | Commissioned redundancy design | Redundancy level confirmed in SO/SLA |
| UPS requirements | Customer equipment UPS tolerance, ride-through requirements | UPS design and bypass options | UPS configuration confirmed |
| Power quality | Voltage sensitivity, harmonic limits, known equipment issues | Power quality baseline, filter options | Power quality review record |
| Cooling fluid | Coolant type compatibility (if customer-side CDU) | Fluid type and chemistry compatibility | Compatibility confirmed in writing |
| Thermal monitoring | Customer monitoring integration needs | Sensor availability, data sharing options | Monitoring integration plan |
| Maintenance expectations | Customer SLA requirements for maintenance windows | Campus maintenance schedule and procedures | Maintenance window protocol documented |
9. Stage 5: Connectivity and Security Review
Connectivity and security requirements must be documented before the customer's service order is finalized. Post-contract surprises about carrier lead times, cross-connect scope, or access control requirements are among the most common causes of delayed go-live dates.
Key topics: carrier circuits needed and procurement responsibility, private circuit or dark fiber requirements, internet transit options, cloud on-ramp requirements, out-of-band management path, cross-connect scope, tenant network demarcation, route diversity requirements, customer security standards (SOC, ISO, FISMA, etc.), access control requirements, camera restrictions in customer spaces, compliance-driven requirements, customer network separation requirements, and OT/IT boundary obligations. Outputs: connectivity plan, demarcation plan, access model, and security review findings.
10. Stage 6: Commercial Scope and SLA Alignment
Commercial scope alignment converts the technical review into a defined service package. Key topics include offering model confirmation, service order structure, capacity reservation, deposits, monthly recurring charges, power billing basis, cooling charges, remote hands scope, cross-connect fees, installation charges, SLA measurement methodology and exclusions, maintenance window definitions, customer responsibility scope, dynamic power capability schedule attachment, service start date dependencies, and go-live criteria.
11. Stage 7: Installation Logistics Plan
| Logistics Topic | Required Customer Input | Campus Review | Approval Output |
|---|---|---|---|
| Delivery date | Planned equipment delivery date | Dock availability, staging capacity, other active deliveries | Approved delivery schedule |
| Equipment list | Complete equipment manifest with quantities | Dock capacity, elevator/lift requirements, handling equipment | Approved equipment list |
| Weights/dimensions | Equipment dimensions, packed and unpacked weight | Floor load capacity, loading dock height, aisle clearance | Floor loading review, handling plan |
| Rack layout | Rack positions, power circuit assignments, cable routes | Campus cage/suite floor plan, power circuit map | Approved rack layout drawing |
| Cabling plan | Intra-rack and inter-rack cable routing, network drop locations | Overhead vs. underfloor routing, cable management | Approved cabling plan |
| Contractor list | All contractors and technicians who will be on site during installation | Contractor access process, insurance, orientation | Approved contractor list, badging completed |
| Access schedule | Daily start/end times, after-hours work requirements | Campus access hours, escort availability | Approved access schedule |
| Work permits | Types of work requiring PTW (hot work, electrical connections, etc.) | PTW issuance process, lead time | Pre-issued or pending permits identified |
| Storage/spares | Spare parts and packaging to be stored on campus | Available staging space, storage period limits | Approved storage plan |
| Waste handling | Packaging waste removal plan, recycling requirements | Campus waste removal procedures | Waste removal schedule |
| Special tools/lifts | Specialized lifting equipment, overhead cranes, or forklifts | Campus crane/forklift availability, lift plan requirements | Approved lift plan if required |
12. Stage 8: Infrastructure Readiness Review
Before customer equipment arrives on site, the campus must complete an infrastructure readiness review. This review confirms that power circuits are energized and tested, cooling systems are commissioned and operational, network circuits are installed and tested, security access is configured, monitoring systems are active, support escalation contacts are established, and documentation is complete.
Open punch items must be classified as blocking or non-blocking. Any item that creates risk to customer equipment, customer data, or customer SLA commitments is blocking and must be resolved before the delivery begins. This stage cross-references the Load Release & Readiness Review Reference for the complete gate model.
13. Stage 9: Equipment Delivery and Installation
Equipment delivery and installation must be managed as a controlled operation on a critical infrastructure campus, not treated as a standard freight delivery. Every piece of equipment arriving on site must be logged, inspected, escorted to its assigned area, and installed according to the approved layout and cabling plan. Deviations from the approved plan must be documented and approved before proceeding.
Key controls include controlled receiving with chain of custody for sensitive equipment, access control and escort for all installation crew, equipment inspection on arrival, rack placement per approved layout, cabling per approved plan, power connection with breaker verification, liquid cooling connection and leak check where applicable, equipment labeling per campus standard, and customer sign-off on installation completeness before energization is requested.
14. Stage 10: Staged Load Release
| Load Step | Purpose | Monitoring Focus | Approval Required Before Next Step |
|---|---|---|---|
| Pre-energization | Confirm all installation and safety prerequisites are met | Punch list closure, connection verification, safety sign-offs | Installation readiness sign-off from campus and customer |
| Initial energization | Energize equipment at no or minimal load to confirm power delivery and equipment behavior | Voltage, current, alarms, trip events | Electrical engineering and campus operations |
| Low-load validation | Apply a small fraction of contracted load to observe system response | Power draw, cooling response, alarm state, customer workload behavior | Campus operations and EHS |
| Intermediate load | Step load to an intermediate level, observe sustained behavior | Power quality, cooling supply/return temperatures, trends, alarm state | Campus operations and engineering |
| High-load validation | Approach contracted operating envelope, observe ramp behavior | Power ramp rate, cooling lag, load step response, alarms | Campus operations, engineering, and customer representative |
| Contracted operating envelope | Operate at full contracted load, validate sustained performance | Sustained power, temperature stability, alarm stability, customer workload output | All sign-off domains per load release gate model |
| Steady-state approval | Formally declare load release complete and transition to steady-state operations | All systems within operating envelope, no open blocking items | Operations director or designated authority, customer acceptance |
15. Stage 11: Steady-State Operations Handoff
Steady-state handoff is not the end of onboarding — it is the beginning of the operating relationship. Support channels, escalation matrix, maintenance notification procedures, access request processes, ticketing system introduction, reporting cadence, billing activation where applicable, and SLA commencement confirmation should all be formally communicated and acknowledged before this stage is closed.
Customer contacts, emergency contacts, authorized requestors for remote hands, and change request approvers must be documented and confirmed. The campus must confirm that all monitoring points for the customer's environment are active and that alarm escalation paths are functioning.
16. Stage 12: Post-Go-Live Review
A formal post-go-live review should be conducted after an initial operating period — the timing and scope should be defined in the onboarding plan. The review should compare expected vs. actual power behavior, cooling performance, network performance, ticket trends, access and logistics issues, and any incidents during the initial operating period.
Outputs: updated dynamic power profile if actual behavior differed from declared, updated runbooks, confirmed resolution of residual punch items, lessons learned shared with the onboarding and operations teams, and customer satisfaction confirmed. Unresolved items from the initial period should be assigned owners and due dates before this review is closed.
17. Tenant Responsibility Matrix
| Domain | Campus / Operator Responsibility | Tenant Responsibility | Joint Responsibility | Evidence / Record |
|---|---|---|---|---|
| Load profile disclosure | — | Disclose accurate operating profile, update if changed | — | Load profile worksheet in onboarding package |
| Equipment specifications | — | Provide current and accurate equipment data | — | Equipment list in onboarding package |
| Rack layout | Approve and record final layout | Provide and adhere to approved layout | Layout change process | Approved rack layout drawing |
| Power interface | Provide and maintain power circuits per specification | Connect equipment per approved specification | Commissioning sign-off | Power circuit record, connection inspection |
| Cooling interface | Provide cooling per contracted specification | Connect cooling equipment per specification, report leaks | Leak check sign-off | Cooling interface inspection, leak test record |
| Network demarcation | Provide and maintain campus-side demarcation | Manage customer-side network from demarcation | — | Demarcation record, circuit test |
| Cross-connects | Fulfill cross-connect work orders per process | Submit authorized work orders, maintain circuit inventory | — | Cross-connect work order archive |
| Access requests | Manage access control system | Submit access requests through defined process | — | Access log, approved requests |
| Contractor management | Campus safety and access requirements | Ensure contractors comply with campus requirements | Pre-approval of contractor list | Approved contractor list, orientation records |
| Installation | — | Complete installation per approved plan, report deviations | Inspection and sign-off | Installation inspection record |
| Commissioning support | Provide power, cooling, and network readiness | Provide equipment ready for staged energization | Joint sign-off at each load step | Load step approval records |
| Load release | Approve load release through gate process | Satisfy installation and equipment readiness gates | Joint execution of load release record | Load release sign-off record |
| SLA reporting | Measure and report against SLA where applicable | — | — | SLA reports per agreed cadence |
| Maintenance coordination | Advance notice per SLA/MSA terms | Respond to maintenance notices, confirm impact | Joint coordination for high-impact windows | Maintenance notification log |
| Incident response | First responder for campus infrastructure events | First responder for customer equipment events | Joint escalation for campus-impacting events | Incident report, RCA, corrective action |
| Decommissioning | Confirm all campus infrastructure restored after customer departure | Remove all customer equipment, cable, and materials | Joint inspection and sign-off | Decommission inspection record |
18. Offering Model Variations
| Customer Type | Onboarding Focus | Customer-Owned Scope | Campus-Owned Scope | Special Gate |
|---|---|---|---|---|
| Turnkey colocation tenant | Full 12-stage process, all domains | Equipment, cables, OS/software, network from demarcation | Space, power, cooling, network to demarcation, support | Dynamic power review for high-density customers |
| Dedicated suite/building | Power, cooling, access, support defined per contract | Everything within licensed area including power distribution | Building shell, shared infrastructure, common areas | Building handover acceptance, load release per contract |
| Powered shell customer | Scope boundary at shell handover, limited ongoing interface | Everything inside the building from handover point | Building structure, power to building, shared utilities | Shell acceptance, handover package delivery |
| Powered land customer | Parcel boundary definition, power delivery interface | All infrastructure on parcel beyond delivery point | Land, power delivery to parcel, shared roads, utilities | Load release for power delivery interface |
| Carrier / network provider | MMR access, conduit, power, escort rules | Carrier equipment, circuit delivery, network operations | MMR space, power, conduit, escort | Carrier access agreement execution before installation |
| Managed connectivity customer | Circuit delivery, cross-connect, demarcation, support | Customer-side network from demarcation | Circuit procurement, cross-connect, monitoring, support | Circuit delivery and acceptance record |
19. Required Onboarding Artifacts
- Customer technical intake form
- NDA / confidentiality agreement
- Load profile worksheet
- Dynamic power capability schedule (for applicable customers)
- Power and cooling requirements worksheet
- Approved rack layout
- Liquid cooling interface worksheet (where applicable)
- Network requirements worksheet
- Security and access requirements worksheet
- Installation logistics plan
- Delivery schedule
- Approved contractor list
- Infrastructure readiness review checklist
- Staged load release plan
- Customer contact and escalation matrix
- Steady-state operations handoff record
- Post-go-live review record
20. Common Onboarding Failure Modes
The following failure modes are among the most frequently observed in complex data center and compute campus deployments. This list is not exhaustive. Each represents a gap in onboarding discipline that the framework is designed to prevent.
| Failure Mode | Root Cause | Consequence | Framework Control |
|---|---|---|---|
| Customer nameplate used instead of actual operating profile | Load profile review skipped or rushed | Campus power and cooling undersized for actual behavior | Stage 3 load profile review required before SO finalization |
| Equipment arrives before power/cooling/network readiness | Stage 8 skipped, schedule pressure | Equipment staged in aisle, no safe installation path | Infrastructure readiness review gates Stage 9 |
| Rack density exceeds approved cooling basis | Customer changed configuration without notification | Thermal excursion, equipment damage, campus SLA risk | Rack layout approval process and change notification requirement |
| Carrier circuit not ordered early enough | Connectivity planning not started at Stage 5 | Customer go-live delayed by circuit lead time | Stage 5 requires carrier order timeline confirmed before logistics plan |
| Access/badging not completed before install crew arrives | Contractor list submitted late | Install crew turned away, schedule delay | Stage 7 requires contractor list and access approval before delivery date |
| Customer assumes reservation equals load release | Commercial and technical stages not linked | Customer schedules workload launch before load release | Stage 6 explicitly states commercial reservation ≠ load release |
| Dynamic workload behavior not disclosed | Customer characterizes load as nameplate, not actual | Campus power and cooling not designed for actual load dynamics | Stage 3 dynamic power review with documented customer attestation |
| Customer installation changes not reflected in documentation | Change management not enforced on site | As-built records incorrect, future maintenance risks | Installation deviation process and Stage 9 inspection sign-off |
| Unclear SLA start date | Commercial handoff to operations incomplete | Billing dispute, SLA measurement gap | Stage 6 documents SLA trigger, Stage 11 confirms commencement |
| Incomplete handoff from sales to operations | No formal Stage 11 handoff record | Operations team without context, repeated customer questions | Stage 11 requires formal handoff record with contacts, scope, and open items |
Framework Disclaimer: This reference describes a tenant onboarding framework only. Actual onboarding obligations, technical requirements, installation approvals, service levels, support commitments, SLA start dates, billing start dates, load release conditions, and customer responsibilities must be defined in the applicable agreements, service orders, technical exhibits, tenant handbook, site rules, and approved operating procedures.
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.