1. Purpose and Scope
This document defines a reference approach for campus-level architecture under the GridCore model. It is not a stamped engineering package, construction drawing set, interconnection agreement, permit filing, or service commitment. It is used to structure early planning, diligence, commercial scoping, engineering coordination, and operating model alignment across the full project team.
The document is intended for project owners, developers, engineering teams, EPC contractors, tenants, infrastructure investors, utility partners, and commissioning authorities who need to understand how GridCore treats the campus as an integrated system before final engineering decisions are made.
- The campus is treated as an integrated infrastructure platform, not a collection of independent buildings.
- Buildings are capacity blocks within a larger coordinated campus system.
- Power, cooling, fiber, access, safety, security, and operations must be designed together from the start.
- The model supports phased capacity delivery — not all capacity is delivered or energized simultaneously.
- The architecture must be adapted to each site's utility, fuel, environmental, geotechnical, permitting, telecom, and customer requirements.
2. Design Premise
AI and HPC compute loads are not simply large — they are operationally dynamic. Power draw can shift rapidly between low and full utilization. Restart sequences can generate large load steps. Cooling demand tracks power demand closely, introducing thermal lag that must be anticipated. A successful campus must deliver not only available power but also structured distribution, operating boundaries, commissioning gates, tenant onboarding discipline, load release verification, and clear interface control at every domain boundary.
The GridCore architecture is designed to reduce ambiguity between the site developer, power provider, building operator, tenant, carrier, EPC contractor, commissioning authority, and operations teams. Each party should understand their scope, their interface, and their escalation path before construction begins.
3. Reference Campus Layers
The GridCore campus model organizes infrastructure into functional layers. Each layer has a defined function, a reference treatment under the model, and project-specific variables that must be resolved through site-specific engineering and diligence.
| Layer | Function | Typical GridCore Treatment | Project-Specific Variables |
|---|---|---|---|
| Land and civil platform | Foundation for all infrastructure | Graded, secured, access-controlled site with defined utility corridors | Geotechnical conditions, drainage, environmental permits, easements |
| Generation or utility supply | Campus power source | Defined in site-specific power strategy (utility, generation, hybrid) | Utility availability, interconnection study, fuel supply, permitting |
| Medium-voltage distribution | Power delivery across the campus | A/B path MV distribution with defined segments, protection, and maintenance isolation | Voltage class, topology, protection coordination study, relay settings |
| Substations / transformer yards | Voltage conversion and protection boundary | Transformer yard with switchgear, metering, protection, maintenance access | Transformer sizing, impedance, spare strategy |
| Building power interface | Point where campus delivers power to a building or capacity block | Defined delivery point with metering, protection boundary, switching authority | Interface voltage, metering configuration, commissioning evidence |
| Cooling heat rejection | Thermal management for compute loads | Campus-level cooling yard planning supporting high-density and residual loads | Cooling technology, climate, design temperatures, redundancy levels |
| Fiber and carrier pathway | Telecommunications and network access | Diverse carrier entries with defined MMR, campus fiber distribution, route separation | Carrier availability (project-specific diligence required) |
| Operations center | Campus command, monitoring, and coordination | Site Operations Center integrating security, facilities, and monitoring functions | SOC scope, system integration, staffing model |
| Security perimeter | Physical security and access control | Defined perimeter, vehicle barriers, access control, CCTV, visitor management | Site-specific threat assessment, regulatory requirements |
| OT/IT networks | Controls, monitoring, and information systems | Separated OT/IT domains with defined interfaces, firewalls, and least-privilege access | Specific control systems, cybersecurity requirements |
| Commissioning and load release | Verified readiness before tenant load is accepted | Formal readiness review with documented evidence before each load step | Commissioning authority, testing scope, sign-off matrix |
| Tenant operating interface | Boundary between campus and tenant operations | Defined interface package covering power, cooling, fiber, security, and escalation | Contract-specific scope, customer equipment requirements |
4. Campus Topology
The GridCore campus is organized as a set of coordinated zones, each with a defined purpose, security classification, access protocol, and interface boundary. Zone separation is not merely a design preference — it controls failure domains, maintenance access, security exposure, and operating authority.
The topology must preserve separation of hazardous or industrial functions from tenant-facing access routes, clear security boundaries between zones, utility corridor discipline, A/B path diversity, maintainable access to electrical and cooling equipment, and the ability to expand the campus without reworking established zones.
5. Power Architecture
GridCore does not prescribe a single power-source model. The campus power architecture is selected based on site-specific utility availability, fuel access, interconnection feasibility, regulatory environment, customer requirements, and project economics. The following configurations are all supported within the GridCore reference framework:
- Utility-fed campus — primary power from the transmission or distribution grid. Backup generation optional.
- Behind-the-meter generation campus — on-site generation as the primary source, with utility as supplemental, backup, or export interface.
- Hybrid utility + on-site generation campus — blended supply with defined operating modes and switching logic.
- Self-generated microgrid campus — on-site generation as sole supply during islanded operation.
- Grid-interactive campus with potential export or BESS capability — generation may participate in market programs, subject to interconnection approvals and regulatory requirements.
- Phased generation plus staged load acceptance — generation capacity added in increments to match phased campus build-out.
Power Architecture Design Considerations
Regardless of the power source configuration, the following elements require explicit project-specific treatment:
| Element | Design Consideration | Project-Specific Variable |
|---|---|---|
| Generation or utility supply | Capacity, redundancy, dispatch sequence | On-site fuel type, utility tariff structure, interconnection study outcome |
| Grid interface | Primary, backup, supplemental, export, or settlement function | Interconnection agreement, protection relay settings, utility requirements |
| Black start / restart | Restart capability after outage event | Generator starting sequence, critical load priority, testing procedure |
| Protection coordination | Coordinated fault isolation across the campus | Protection study, relay settings, arc flash analysis — all project-specific engineering |
| Metering | Billing, settlement, and performance verification | Meter placement, billing configuration, utility/customer settlement |
| Power quality monitoring | Voltage, frequency, harmonic, and event recording | Customer sensitivity requirements, monitoring system integration |
| Maintenance isolation | Safe isolation of equipment segments for maintenance | Switching procedures, safety rules, energy isolation records |
| Phasing and expansion | Staged capacity delivery matching campus build-out | Capacity block sizing, energization sequence, permitting phasing |
6. Medium-Voltage Distribution Model
The campus MV distribution system is the backbone that connects the power source to each building or capacity block. GridCore treats MV distribution as a designed and operated system — not merely a collection of cables and transformers. The distribution model must support normal operations, maintenance switching, fault isolation, and expansion without requiring a full system shutdown.
A/B Distribution Concept
Where project requirements call for N+1 or 2N power resilience, the distribution system is organized into independent or functionally separated A and B paths. Ring or loop architecture may be used where appropriate to enable sectionalizing without a complete outage. Dedicated feeders to buildings or capacity blocks, with defined delivery points, support clear commissioning gates and operating boundaries.
| MV Domain | Reference Function | Operating Consideration | Evidence Required Before Load Release |
|---|---|---|---|
| Source switchgear | Main switching and protection at the generation or utility interface | Arc flash, switching procedure, interlock review | Factory test records, site commissioning, relay setting records |
| Feeder protection | Overcurrent, differential, and distance protection for each feeder segment | Protection coordination with upstream and downstream devices | Relay test records, coordination study, settings documentation |
| Ring/loop sectionalizing | Switchgear enabling controllable segment isolation | Normal open/close positions, fault sectionalizing logic | Interlock tests, SCADA integration, switching procedure |
| Building feeder | Dedicated circuit serving a specific building or capacity block | Isolation and restoration procedure for each building | Commissioning records, metering verification, delivery point test |
| Transformer interface | MV/LV transformation at the building boundary | Tap position, protection settings, loading limits | Commissioning, turns ratio test, thermal imaging baseline |
| Metering | Revenue or check metering at delivery points | Meter class, calibration, data integration | Meter test records, data communication test, billing verification |
| Relay coordination | Time-current coordination from source to load | Selectivity between protection devices | Protection study results, relay settings file, test certificates |
| Maintenance isolation | Visible isolation points for safe working | LOTO procedure, minimum approach distance, work permit interface | LOTO procedure documentation, safety labeling inspection |
| SCADA/monitoring | Remote monitoring and alarming of the MV system | Alarm point list, communication architecture, historian integration | Point list verification, communication test, alarm response procedure |
| Emergency switching procedure | Documented actions for abnormal or fault conditions | Authority matrix, communication path, escalation | Written procedure, tabletop review, training records |
7. A/B Critical Path Philosophy
A/B paths are a design and operating discipline — not simply a drawing convention. Specifying two paths on paper provides no resilience if those paths share a common physical route, a common protection device, a common switchgear room, or a common maintenance team that may inadvertently disable both paths simultaneously.
A/B Design Considerations
- Physical separation: A and B routes must be physically segregated — separate trenches, conduit banks, or overhead routes, depending on the project.
- Equipment independence: A path equipment must not share a fault domain with B path equipment. Common-mode failures must be reviewed at the design stage.
- Failure domain control: A fault on Path A must not propagate to Path B. Protection coordination must support this.
- Maintainability: Each path must be maintainable independently without requiring both to be taken out of service simultaneously.
- Independent monitoring: A and B paths must be monitored separately. Alarm and reporting must distinguish path status.
- Tenant interface implications: Tenants receiving A+B power must understand their own internal redundancy requirements to realize the benefit of a dual-path supply.
- Cross-ties: Planned cross-ties between A and B paths must be carefully engineered. An improperly operated cross-tie can collapse both paths simultaneously.
- Project-specific redundancy: The actual redundancy level (N+1, 2N, 2N+1) is a project-specific design decision, not a fixed GridCore requirement.
8. Building Blocks and Phased Capacity Delivery
The campus should be organized around repeatable capacity blocks — buildings, bays, or pods that can be individually energized, commissioned, and handed over to tenants in sequence. This avoids the risk of a monolithic campus that cannot deliver any capacity until the entire site is complete.
For high-density AI and HPC applications, buildings may be planned in modular increments where each bay or group of bays represents a distinct load-release unit with its own power delivery point, cooling interface, commissioning gate, and tenant access boundary. The GridCore model does not prescribe a fixed building size — the reference concept is repeatable buildings, repeatable electrical yards, and repeatable operating interfaces.
Commercial capacity reservations and actual technical load acceptance are distinct events. A reservation secures a commercial position. Load release is a formal technical and operational decision made after verification of the delivery system at the relevant load level.
9. Cooling and Heat Rejection Integration
Cooling architecture must be integrated at the campus planning level — it cannot be treated as a building-only afterthought. For AI and HPC loads, cooling capacity, thermal response speed, and reliability are as operationally critical as power delivery.
Cooling Design Considerations
| Cooling Domain | Design Consideration | Project-Specific Variable |
|---|---|---|
| Direct-to-chip liquid cooling | Required for high-density AI/HPC loads exceeding air cooling limits | Coolant type, supply/return temperatures, CDU specifications, customer equipment compatibility |
| Residual air cooling | Handles non-liquid-cooled components and auxiliary heat loads | Airflow design, CRAC/CRAH selection, hot/cold aisle containment |
| Heat rejection equipment | Dry coolers, cooling towers, or fluid coolers for campus-level heat rejection | Climate conditions, design wet/dry bulb temperatures, water availability, local regulations |
| Pump skids | Primary and secondary loop circulation | Flow rates, pressure requirements, redundancy level, maintenance access |
| CDU interfaces | Connection between campus loop and rack-level distribution | Manifold design, pressure differentials, leak detection, alarm integration |
| Thermal response | System behavior during load steps and transients | Thermal mass, control response time, over-temperature alarm setpoints |
| Monitoring | Temperature, flow, pressure, leak detection, and trending | EPMS/BMS integration, alarm points, historian data |
| Redundancy | N+1 or 2N pump/cooler configuration | Project-specific resilience target, maintenance derate, financial trade-off |
| Fluid chemistry | Water treatment, inhibitors, biological control | Local water quality, make-up water source, chemistry monitoring program |
| Freeze protection | Protection in cold climates | Antifreeze type, concentration, drain procedures, heat trace requirements |
10. Connectivity and Fiber Architecture
Carrier availability and network connectivity must be treated as diligence items, not assumed facts. The GridCore campus model provides a physical and logical framework for connectivity — but actual carrier availability at any specific site must be verified through commercial due diligence, pre-construction coordination, and carrier agreements.
- Diverse carrier entries: Two or more physically separate carrier entry routes are planned where feasible, serving separate MMRs (A and B).
- Meet-Me Room placement: MMR A and MMR B are located in separate sections of the campus or separate buildings to support physical diversity.
- Campus fiber distribution: Internal dark fiber runs from MMRs to each building, with route diversity where physically achievable.
- Network separation: Tenant networks, carrier networks, corporate IT, physical security networks, and OT/ICS networks are maintained on separate physical or logical paths.
- Cross-connect process: A formal work order process governs all cross-connects between carrier circuits and tenant equipment.
- Tenant demarcation: A clear, documented demarcation point exists for each tenant circuit — beyond which the tenant is responsible.
- Carrier availability: No carrier service is assumed. Carrier availability must be confirmed during the commercial diligence and contracting process for each project and each tenant.
11. Operations Center and Campus Control
The Site Operations Center (SOC) is the coordination hub for the campus — not a single point of authority over all systems. Its role is to integrate security operations, visitor management, facilities monitoring, and incident escalation in a way that supports clear response without blurring the operational boundaries between security, OT, IT, and tenant systems.
12. OT/IT and Controls Boundary
The campus operates multiple distinct network domains that must be physically or logically separated to protect operational integrity, safety systems, and cybersecurity posture. The specific cybersecurity framework applied is project-specific and may depend on regulatory requirements, customer requirements, insurance requirements, and operational risk assessment.
| Network Domain | Typical Scope | Separation Mechanism | Access Model |
|---|---|---|---|
| OT / SCADA | Generation controls, MV SCADA, BMS, EPMS, protection relays | Physically isolated or firewall/DMZ separated | Strict role-based, jump-host required, all access logged |
| Corporate IT | Business applications, email, HR, finance | VLAN or physical separation from OT and tenant networks | Standard enterprise security policies |
| Tenant network | Customer compute, storage, and applications | Physical or virtual separation per tenant | Tenant-managed within defined demarcation |
| Physical security / CCTV | Access control, cameras, badge systems | Dedicated or VLAN-isolated network | Security team access only; SOC monitoring |
| Carrier / network | Carrier POPs, cross-connects, MMR systems | Carrier-managed to demarcation point | Carrier access to carrier equipment; cross-connect process for tenant circuits |
Cybersecurity review requirements, specific frameworks (NIST, IEC 62443, or others), and audit obligations are project-specific and may apply depending on regulatory, insurance, and customer requirements.
13. Readiness and Load Release Relationship
Campus architecture is only complete when evidence exists that the designed systems perform as intended under operating conditions. Construction completion is necessary but not sufficient. Before load is accepted from a tenant, the following must be verified and documented:
- Electrical systems commissioned and protection settings confirmed
- Cooling systems at operating setpoint with redundancy tested
- Safety programs active, PTW operational, and emergency procedures trained
- Security systems online and access control active
- Operations staffing in place with documented procedures
- Monitoring systems integrated with alarm response procedures confirmed
- Tenant installation reviewed and approved against agreed load profile
- Load release authority matrix signed off by all required parties
14. Implementation Variants
The GridCore campus architecture applies across a range of implementation types. The core model — integrated planning of land, power, buildings, cooling, connectivity, safety, and operations — applies in all cases. The specific scope, interfaces, and diligence items vary by implementation type.
15. Project-Specific Outputs
This reference architecture is a starting point. For each specific project, the following documents must be developed through site-specific engineering, diligence, and regulatory processes:
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.