1. Purpose and Scope
This reference document defines a framework for Powered Shell delivery under the GridCore campus model. It does not define a final lease, sale, master service agreement, development agreement, construction agreement, or operating agreement. Final scope, delivery terms, acceptance criteria, and operating obligations vary by project and customer requirements.
The document is intended to align the developer, campus operator, customer, EPC contractor, commissioning authority, and operations teams around a common understanding of what constitutes a properly scoped and delivered Powered Shell — before contracting, construction, or handover begins.
This document does not constitute a construction commitment, capacity guarantee, permitting representation, interconnection commitment, or any legally binding delivery obligation.
2. Powered Shell Definition
“A commissioned compute-ready building or building section delivered with defined power, cooling, connectivity, access, security, and operations interfaces, where the customer receives a more complete platform than Powered Land but more control and responsibility than Turnkey Colocation.”
The Powered Shell model sits between Powered Land and Turnkey Colocation in the GridCore offering spectrum. Each model serves a different customer profile with a different distribution of delivery responsibility and operating control.
| Model | Customer Receives | Customer Typically Controls | Campus / Platform Responsibility | Best Fit |
|---|---|---|---|---|
| Powered Land | Parcel with defined power delivery point, fiber access, and campus services interface | Site design, building, all internal infrastructure, and operations | Campus infrastructure to the delivery point; site access and safety rules; perimeter security | Sophisticated developers or operators who want to build their own facility within a served campus |
| Powered Shell | Commissioned building with defined power, cooling, connectivity, and security interfaces | Internal data hall fit-out, IT deployment, and some internal M&E depending on scope | Building shell, power to delivery point, cooling to interface, connectivity to demarcation, security perimeter | Customers who want a faster start and a capable building without full managed service |
| Turnkey Colocation | Managed service: space, power, cooling, connectivity, monitoring, security, support, and SLA | Customer equipment configuration and IT operations within approved envelope | All data center infrastructure, operations, monitoring, and support within the service scope | Customers who want to focus on IT operations and outsource the data center operating environment |
3. Powered Shell Design Premise
A powered shell should reduce delivery risk by standardizing site utilities, power delivery, core building design, cooling basis, carrier pathways, access controls, and commissioning evidence. It accelerates customer deployment by eliminating the blank-slate development process while allowing sophisticated customers to retain meaningful operational control over their fit-out, IT deployment, and in some cases their mechanical and electrical systems.
The success of the model depends entirely on precise scope and boundary definition. A powered shell with ambiguous handover criteria, incomplete commissioning evidence, or undefined operating boundaries creates exactly the delivery and operational risk the model is designed to avoid.
The single most important function of the Powered Shell framework is to define boundaries — what is delivered, what is commissioned, what evidence exists, where the customer takes responsibility, and how the building continues to operate as part of the campus after handover.
4. Scope Categories
Powered Shell scope varies significantly by project. The following table describes the reference treatment of common scope items. Not every item is included in every powered shell. Final scope is defined in the project-specific scope exhibit.
| Scope Item | Baseline Powered Shell Treatment | Optional Enhancement | Typically Customer Responsibility |
|---|---|---|---|
| Building shell | Delivered by campus/developer | — | — |
| Structural system | Designed and constructed to data center load assumptions | Additional floor loading for specific heavy equipment | — |
| Roof, walls, envelope | Delivered per building specification | Enhanced insulation or vapor barrier | Tenant improvements within space |
| Utility corridors | Campus utility corridors to building entry | — | Internal utility distribution within building |
| MV power delivery point | Campus delivers MV to defined delivery point | — | — |
| Transformers / switchgear | Main building transformer and switchgear delivered | Redundant transformer or switchgear | Additional customer-side switching within space |
| Low-voltage distribution | Project-specific; may or may not be included | Floor-level PDU installation | Data hall LV distribution from defined point |
| UPS | May be campus or customer responsibility — project-specific | Modular UPS installation | Customer-side UPS where not in scope |
| Generators | May be campus or customer responsibility — project-specific | Additional generation capacity beyond base design | Customer generators where not in scope |
| Cooling plant | Campus may provide cooling to building interface | Additional cooling capacity for higher density | Internal CDUs, manifolds, and rack connections |
| Fluid coolers / dry coolers | Cooling yard included in standard Powered Shell | Additional capacity or redundancy | — |
| Pump skids | Primary loop pumping included | Redundant pump sets | — |
| CDUs / manifolds | Project-specific; may be campus or customer scope | Pre-installed CDU/manifold racks | Customer rack-level liquid distribution |
| Data hall fit-out | Not included in baseline shell; building is delivered as white space | Raised floor, cable trays, containment | Customer fit-out per approved plan |
| Racks | Not included | — | Customer-provided |
| Cabling | Campus fiber to demarcation; building backbone may be included | Structured cabling installation | Data hall cabling from demarcation |
| Carrier entrance | Campus carrier pathway to building demarcation | — | — |
| Meet-me room | MMR access via campus; may be shared campus MMR | Dedicated in-building MMR | Customer cross-connect within MMR |
| Security systems | Building-level access control integrated with campus security | Enhanced interior access control | Customer space access control |
| Fire protection | Building fire protection system delivered | Specialized suppression for specific equipment zones | — |
| BMS / EPMS | Building management and power monitoring systems | Enhanced integration with customer DCIM | Customer DCIM and monitoring tools |
| Tenant monitoring interface | Defined monitoring data feed to customer | API or portal integration | Customer-side monitoring platform |
| Office / support space | Project-specific | Enhanced office fit-out | — |
| Loading dock | Included | — | — |
| Spare parts / storage | Not included in baseline | Designated on-site spare parts storage | Customer spare management |
| Commissioning | Campus-provided systems commissioned to defined evidence standard | — | Customer fit-out commissioning |
| Operations staffing | Campus operations team responsible for campus-level systems | — | Customer operations for internal systems |
5. Power Interface
The power interface is the single most critical boundary definition in a Powered Shell agreement. Every aspect of the power interface must be explicitly defined before construction begins. Ambiguity at the power boundary creates safety risk, commissioning failure, and long-term operational disputes.
| Power Interface Element | Definition Required | Handover Evidence | Operating Owner |
|---|---|---|---|
| Delivery point | Physical location where campus power responsibility ends and customer responsibility begins | As-built single-line diagram showing delivery point; physical labeling | Campus to delivery point; customer from delivery point |
| Voltage class | Delivered voltage and power quality requirements | Commissioning test results; power quality baseline measurement | Campus defines and delivers voltage class; customer designs to it |
| Capacity allocation | Maximum contracted power at delivery point; current and future phases | Metering configuration; capacity allocation exhibit | Campus manages campus-side; customer manages within allocated capacity |
| Metering point | Location and configuration of revenue and check meters | Meter test certificates; communications test records | Campus-owned meters; access for verification per agreement |
| Protection device | Campus-side protection relay or fuse at delivery point | Relay test records; settings documentation; arc flash labeling | Campus owns and operates campus-side protection; coordinate settings with customer-side |
| Switching procedure | Defined sequence for energization, de-energization, and emergency isolation | Written switching procedure; tabletop sign-off; training records | Campus authority for campus-side switching; customer authority for customer-side switching |
| Arc flash / safety labeling | Current arc flash analysis labels on all electrical equipment at interface | Arc flash study report; physical labeling inspection | Campus provides and maintains on campus-side equipment |
| Commissioning records | Full commissioning evidence for all power systems at and above the delivery point | Commissioning test package; punch list resolution evidence | Campus provides and retains; copies to customer in handover package |
| Load step approval | Documented process for approving load increase events after handover | Load step approval procedure; initial load release certificate | Joint process: campus approves campus-side readiness; customer certifies customer-side readiness |
| Emergency shutdown / escalation | Defined emergency contacts and authority for emergency de-energization | Emergency procedure document; contact matrix; annual review confirmation | Campus authority for campus-side emergency action; joint escalation protocol |
6. Cooling Interface
Cooling scope in a Powered Shell must be explicitly defined at every level — from the campus cooling yard through to rack-level liquid distribution. Without clear boundaries, cooling responsibility gaps emerge during construction, commissioning, and operations, creating performance risk and safety risk.
| Cooling Item | Required Definition | Potential Owner | Acceptance Evidence |
|---|---|---|---|
| Heat rejection equipment | Type, capacity, redundancy, and control of dry coolers or cooling towers | Campus | Commissioning report; capacity test; controls integration test |
| Pump skids | Flow rate, pressure, redundancy, and control logic | Campus (primary loop); project-specific for secondary loop | Commissioning report; flow balance; pressure test |
| Building loop | Supply/return temperature, flow, pressure, fluid type, and monitoring | Campus to building interface | Fluid chemistry analysis; pressure test; commissioning records |
| CDU / manifold | Supply/return conditions at CDU connection; CDU control integration | Campus or customer — project-specific | CDU commissioning; leak test; flow verification; alarm test |
| Rack connection | Manifold port assignment; quick-connect specifications; pressure limits | Customer | Customer installation inspection; leak test before energization |
| Residual air cooling | Airflow rates, CRAC/CRAH capacity, hot-spot limits, containment design | Campus (building-level equipment); customer (containment) | Airflow commissioning; thermal scan; containment inspection |
| Controls integration | How customer cooling equipment integrates with building BMS/EPMS alarms | Joint definition; customer provides DCIM interface | Controls integration test; alarm response drill |
| Leak detection | Sensor placement, alarm routing, and response procedure | Campus for campus-side piping; customer for rack-level piping | Sensor function test; alarm routing test; response procedure review |
| Fluid chemistry | Inhibitor type, concentration, and monitoring program | Campus for primary loop; customer for secondary loop where applicable | Initial fluid analysis report; chemistry program documentation |
| Thermal performance test | Load step test demonstrating cooling system responds correctly | Joint commissioning activity | Test report showing thermal response within design parameters; sign-off by both parties |
7. Building and Fit-Out Boundary
The powered shell is delivered as a commissioned building ready for customer fit-out. The fit-out boundary defines what is part of the shell delivery and what is customer scope. Any customer modification to the building infrastructure requires a formal change approval process.
Building envelope
Roof, walls, and structure delivered per specification. Customer cannot modify structural elements without engineering review and campus approval.
Floor loading
Designed to defined live load assumptions. Customer must verify planned equipment loads comply. Overloading requires structural review.
Clear heights
Documented clear heights in data hall, mechanical rooms, and electrical rooms. Customer equipment must comply.
Equipment access
Access routes for large equipment delivery defined and must be maintained clear at all times.
Loading dock
Dock height, door dimensions, and staging capacity documented in building specification.
Fire/life safety
Building fire detection, suppression, and egress delivered per code. Customer may not obstruct or modify without authority approval.
Electrical and mechanical rooms
Campus equipment in electrical and mechanical rooms is off-limits to customer staff except as coordinated through the operations interface.
Customer improvements
All customer fit-out must be documented, submitted for approval, and comply with campus construction rules before work begins.
Change approval process
Written process for requesting, reviewing, approving, and documenting changes to the building infrastructure defined in the operating agreement.
8. Connectivity and Demarcation
Campus carrier entry pathways are provided to the building demarcation point. Beyond demarcation, the customer is responsible for internal network infrastructure and carrier circuit procurement. Carrier availability at any specific campus is subject to project-specific due diligence and is not assumed or guaranteed.
- Campus carrier entry: Physical conduit and pathway from campus perimeter to building MMR or demarcation point delivered as part of the shell.
- MMR access: Customer access to campus MMR or in-building demarcation point for carrier circuit termination.
- Building demarcation: Physical and logical demarcation point between campus infrastructure and customer network responsibility documented in the connectivity exhibit.
- Dark fiber: Campus may provide dark fiber from MMR to building; customer activates with own optics and equipment.
- Customer circuit procurement: Customer procures all carrier services directly. Campus facilitates physical access.
- Route diversity: Campus provides diverse physical pathways where feasible. Customer must verify route diversity of their specific circuits with carriers.
- Fiber documentation: As-built fiber route drawings and splice records delivered in handover package.
9. Security and Access Boundary
| Access Domain | Campus Operator | Customer | Coordination Required |
|---|---|---|---|
| Campus perimeter | Operates and maintains perimeter security | Complies with site access rules | Customer credential registration; escort coordination |
| Site access | Controls vehicle and pedestrian access; maintains site access log | Registers all personnel; pre-registers visitors | Badge issuance; access log audit rights per agreement |
| Building access | Operates building access control; monitors building entry | Manages customer credential assignments; reports lost credentials | Credential provisioning; access change request process |
| Customer-controlled spaces | CCTV of corridor exterior; no routine interior access | Operates interior access control; manages keys and credentials | Campus emergency access procedure defined in agreement |
| Visitor processing | Processes all visitor registrations; verifies identity | Pre-registers visitors; provides or requests escort | Visitor registration system; escort rules documented in site rules |
| Emergency access | Defines emergency access procedures; coordinates with first responders | Provides emergency contacts; cooperates with emergency procedures | Joint emergency access procedure; annual review |
| Camera / access control ownership | Owns and operates campus and building-level systems | May operate systems within customer-controlled space | Integration requirements and data retention policy defined in agreement |
| Restricted zones | Defines and enforces restricted zones (electrical, generation, etc.) | Complies with restricted zone rules; no unauthorized entry | Restricted zone orientation required before first access |
10. Controls, Monitoring, and Data Sharing
Even when the customer operates internal building systems, the campus must retain sufficient monitoring visibility to protect shared infrastructure — particularly power delivery, cooling interfaces, and safety systems. The monitoring interface must be explicitly defined.
Monitoring Interface Requirements
| System | Campus Visibility Required | Customer Visibility Required | Data Sharing Definition |
|---|---|---|---|
| BMS (campus scope) | Full visibility and control of campus-scope systems | Alarm feed for conditions affecting customer environment | Defined alarm point list; API or portal per agreement |
| EPMS / metering | Revenue metering; power delivery monitoring | Real-time and historical power usage data | Data feed format and frequency defined in monitoring exhibit |
| SCADA / OT (campus) | Full visibility; campus authority | None — cybersecurity boundary maintained | No direct customer access to campus OT systems |
| Customer DCIM | None — customer authority | Full visibility of customer-side systems | Customer responsible for their DCIM; alarm escalation interface defined |
| Tenant portal | Provide portal access per service scope | Access to defined reporting and ticketing functions | Portal capabilities and data formats defined in service agreement |
| Incident logs | Retain campus incident records | Access to incidents affecting customer service | Incident report sharing per agreement |
| Maintenance notifications | Provide advance notice per agreement | Receive notifications via portal or email per defined process | Notice period and format defined in operating agreement |
Cybersecurity separation between campus OT/SCADA systems and customer networks must be maintained at all times. Customer access to campus control systems is not permitted without specific engineering review and documented approval.
11. Commissioning and Handover Package
The handover package is the formal evidence set that documents what was delivered, how it was tested, and what the customer is accepting. An incomplete handover package should not be accepted as a basis for final acceptance. Critical items must be resolved before the customer takes responsibility for operating the building.
| Handover Artifact | Purpose | Required Before Customer Acceptance? | Notes |
|---|---|---|---|
| As-built drawings | Record of what was actually built vs. what was designed | Yes | Must reflect all field changes; architectural, structural, MEP, and civil |
| Single-line diagrams | Authoritative electrical reference for operations and emergency response | Yes | Must match installed configuration; used for switching procedures |
| Protection relay settings | Verified relay configuration for all protective devices | Yes | Must be filed with commissioning authority; available for future relay testing |
| Commissioning reports | Evidence of system testing to defined acceptance criteria | Yes | All systems within scope; signed by commissioning engineer |
| Equipment O&M manuals | Reference for operation and maintenance of installed equipment | Yes | Must cover all campus-provided equipment; digital preferred |
| Warranties | Equipment and installation warranty terms | Yes | Registered in customer name where applicable; transfer documentation |
| Thermal performance test records | Evidence that cooling system responds to load steps as designed | Yes | Conducted during commissioning; signed off by both parties |
| Controls points list | Complete list of monitored and controlled points with descriptions | Yes | Reference for alarm response and monitoring system integration |
| Alarm matrix | Mapping of alarms to response procedures and escalation paths | Yes | Must be trained to operations staff before go-live |
| Fire / life safety documentation | Inspection records, test certificates, system diagrams | Yes | Authority-having-jurisdiction approvals where required |
| Punch list | Record of known incomplete or deficient items | Yes — classified by severity | Critical items must be resolved before acceptance; minor items tracked to completion |
| Training records | Evidence of operations training on delivered systems | Yes | Campus team and customer team trained on interface systems |
| Spare parts list | Identified critical spares and their location | Recommended | Supports maintenance planning and emergency response |
| Emergency procedures | Documented response procedures for abnormal events | Yes | Must be reviewed and acknowledged by customer operations team |
| Load release certificate | Formal sign-off that the building is ready to accept customer load | Yes | Signed by required parties per the load release authority matrix |
12. Customer Acceptance Process
Customer acceptance is a formal process, not an informal walkthrough. Each stage should produce documented evidence before proceeding to the next.
01
Scope Verification
Customer confirms all contracted scope items are present and accessible for inspection.
02
Documentation Review
Handover package reviewed for completeness. Missing documents identified and resolution path agreed.
03
Physical Inspection
Joint walkthrough of all delivered spaces, equipment, and interfaces. Inspection list documented.
04
Safety Systems Verification
Fire detection, suppression, egress, and emergency systems verified operational.
05
Electrical Commissioning Review
Customer reviews electrical commissioning evidence. Protection settings and metering verified.
06
Cooling Commissioning Review
Customer reviews cooling commissioning evidence. Thermal performance test results reviewed.
07
Controls / Monitoring Verification
BMS, EPMS, monitoring interface, and alarm feeds tested and verified.
08
Security / Access Verification
Access control, CCTV, and badge systems tested. Credential provisioning process verified.
09
Punch List Classification
Outstanding items classified as critical (must resolve before acceptance) or minor (tracked to completion).
10
Customer Fit-Out Authorization
Customer authorized to begin fit-out activities in commissioned spaces. Campus construction rules apply.
11
Initial Energization
Campus energizes building at delivery point following agreed procedure. Customer witnesses.
12
Staged Load Release
Load accepted in approved steps per load release procedure. Each step signed off before proceeding.
13
Final Acceptance / Operations Transition
All critical punch items resolved. Operating boundary agreed. Operations teams in place. Final acceptance executed.
13. Post-Handover Operating Model
A Powered Shell is not walk-away infrastructure. The building remains part of the campus after handover. Campus rules, safety programs, maintenance windows, emergency procedures, and visitor management protocols continue to apply. The campus must retain the ability to protect shared infrastructure and respond to campus-wide events.
| Operating Domain | Campus Operator | Customer | Coordination Trigger |
|---|---|---|---|
| Campus power system | Operates and maintains all campus-side power systems | Operates internal building power systems from delivery point | Any change to load profile or switching that affects the campus delivery system |
| Building electrical system | No authority for customer-side equipment without consent | Full operational authority from delivery point | Maintenance outages that affect campus delivery point; emergency isolation |
| Cooling interface | Operates campus cooling plant and primary loop | Operates customer-side cooling from interface point | Changes to thermal load; cooling interface maintenance outages |
| Internal cooling | No authority; monitoring visibility only | Full operational authority; responsible for thermal envelope | Out-of-envelope conditions detected by campus monitoring; emergency cooling event |
| Carrier access | Provides MMR access; campus carrier pathway maintenance | Procures and manages carrier circuits | Physical access to MMR; carrier pathway maintenance outage; new circuit installation |
| Visitor access | Processes all campus site visitors; site rules apply | Manages access to customer-controlled spaces; pre-registers visitors | Any visit by non-badged personnel to campus or building |
| Safety program | Campus EHS, PTW, and safety rules apply to all campus areas | Customer safety program applies within customer-controlled spaces; campus rules apply for any shared space | Any work in campus-controlled areas; contractor access; emergency events |
| Emergency response | Campus SERP; first responder interface; campus emergency authority | Customer emergency procedures within customer space; joint notification protocol | Any safety event; campus-level emergency; utility/generation/cooling emergency |
| Maintenance outage | Provides advance notice per agreement; schedules maintenance | Plans customer operations around campus maintenance windows | Any campus maintenance that affects power, cooling, or access to the building |
| Load increase | Reviews and approves load step requests | Submits load step request per process; does not exceed approved load | Any increase in customer load at or above defined notification threshold |
| Incident escalation | Campus escalation procedure for campus-side incidents | Customer escalation procedure for customer-side incidents | Any incident with potential cross-boundary impact; any emergency |
| Environmental / compliance reporting | Campus-level permit compliance and reporting | Customer-level compliance for internal operations | Any event or condition requiring joint reporting to regulatory authorities |
14. Common Failure Modes This Framework Prevents
The following failure modes commonly occur in powered shell and build-to-suit data center projects where scope and operating boundaries are not precisely defined. The GridCore Powered Shell framework is specifically designed to prevent these outcomes.
01
Unclear power boundary
Customer and campus both assume the other is responsible for protective devices, metering, or switching procedures at the interface. Discovered during commissioning or a fault event.
02
Capacity equals released load assumption
Customer assumes reserved or contracted capacity means they can energize equipment at full load immediately. Commissioning evidence has not been produced; load release has not occurred.
03
Cooling design basis not tied to actual hardware
Cooling system designed to a generic density assumption. Actual customer hardware runs hotter or draws more coolant than the design basis. Discovered after installation.
04
Incomplete commissioning evidence
Handover package missing test records, relay settings, or as-built drawings. Customer accepts building; gaps discovered during first maintenance event or operational incident.
05
Customer installs equipment before safety plan is ready
Customer begins equipment installation before PTW, access control, emergency procedures, or commissioning gates are in place. Safety event occurs during installation.
06
Carrier path assumed but not delivered
Customer assumed carrier would be present at handover. Carrier pathway exists but no carrier has committed service. Customer discovers gap after operational date.
07
Campus switching authority unclear
During an emergency, both campus and customer attempt to operate the power interface boundary simultaneously without a defined authority matrix. Conflict or safety incident results.
08
Maintenance windows not coordinated
Campus performs MV system maintenance without coordinating with customer. Customer load affected without warning. SLA and operational relationship damaged.
09
Monitoring responsibility ambiguous
Neither campus nor customer is clearly responsible for monitoring the cooling interface. Thermal excursion event is not detected promptly.
10
Handover with unresolved critical punch items
Customer accepts building with outstanding critical issues to meet commercial date. Issues are never resolved. Operational risk persists for the life of the building.
11
Load profile exceeds designed operating envelope
Customer installs hardware with different power or thermal characteristics than disclosed during design. Campus power and cooling systems unable to support actual load.
15. Project-Specific Exhibits
The following documents should be developed and attached to the Powered Shell agreement. Their absence creates the scope ambiguity and operating risk described above.
Scope exhibit
Building description and specification
Power interface exhibit
Cooling basis of design
Connectivity and demarcation exhibit
Security and access rules
Customer fit-out rules and approval process
Construction logistics plan
Commissioning plan
Handover package checklist
Operations boundary matrix
Maintenance coordination process
Load release procedure and authority matrix
Insurance and risk requirements
Change management process
This reference describes a Powered Shell framework. Actual delivery scope, acceptance criteria, customer obligations, operating rights, remedies, warranties, exclusions, and commercial terms must be defined in the applicable project agreement and 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.