Operations Boundary Matrix

1. Purpose and Scope

This reference defines the operating boundary framework for GridCore campuses. It is not a final operations manual, emergency response plan, staffing plan, MSA, SLA, security plan, NERC determination, compliance plan, or site-specific SOP.

It is intended to align campus owner, platform operator, colocation operator, powered land customer, powered shell customer, EPC, vendors, security team, safety team, facilities team, power team, carriers, and commercial teams on how operating responsibilities are divided across a complex, multi-domain campus.

Final operating boundaries must be documented in site-specific procedures, contracts, training materials, and escalation matrices. This reference establishes the framework for those project-specific documents.

2. Operating Model Premise

"Integrated infrastructure fails at the boundaries before it fails in the org chart."

Individual teams may be competent in their domains, but interface failures create the most consequential operational risk. Power, cooling, security, network, safety, and customer operations are deeply interdependent on a modern compute campus.

—AI and HPC loads create dynamic, real-time operating conditions that can interact across systems unexpectedly.
—Campus-scale infrastructure requires formal authority boundaries — not informal agreements between team leads.
—Operations must define procedures for normal, abnormal, maintenance, emergency, and customer-caused conditions before the campus is energized.
—A boundary that exists only in someone's head is not a boundary.

3. Operating Domains

A GridCore campus may encompass all of the following operating domains. Each domain has a primary function, typical owner, interfaces with other domains, and a system of record for evidence.

Domain	Primary Function	Typical Operating Owner	Key Interfaces	Evidence / System of Record
Campus power supply	Deliver reliable power to all loads	Power / Facilities	Generation, utility, distribution, cooling, customers	SCADA, metering, EPMS
Utility interconnect	Manage grid connection and compliance	Campus Power / Utility Coordinator	Power supply, metering, protection	Interconnection agreement, protection records
Generation plant	Operate on-site generation where applicable	Power / Plant Ops	Fuel supply, utility, distribution, controls	Plant SCADA, maintenance logs
MV distribution	Route medium-voltage power to substations and buildings	Campus Power	Switchgear, transformers, protection	Switching log, relay records
Building electrical	Distribute power within each building	Facilities / Building Ops	MV feed, UPS, cooling, customer loads	EPMS, maintenance records
UPS / stored energy	Provide backup and power conditioning	Facilities / Building Ops	Building electrical, generator, cooling	UPS monitoring, battery records
Cooling plant	Maintain safe thermal conditions campus-wide	Cooling / Facilities	Building electrical, CDUs, monitoring	BMS, fluid chemistry records
Liquid cooling loops	Deliver coolant to high-density racks	Cooling / Facilities	CDUs, manifolds, rack-level systems	BMS, leak detection, flow logs
BMS / EPMS / SCADA	Monitor and control building/plant systems	Controls / OT Team	All physical domains, cybersecurity	System logs, alarm records
OT cybersecurity	Protect operational technology from unauthorized access	OT Security	SCADA, BMS, EPMS, vendor access	Audit logs, change records
Corporate IT	Support business operations	IT Department	OT boundary, tenant networks, vendor access	IT ticketing, access logs
Tenant networks	Customer IT infrastructure	Customer / Colocation Ops	Campus connectivity, carrier, monitoring portal	Customer records, carrier logs
Carrier connectivity	Provide and terminate external fiber/connectivity	Connectivity / Campus Ops	Tenant networks, demarcation, carrier NOC	Carrier tickets, splice/test records
Physical security	Control access and respond to security events	Security Operations	Visitor control, badge systems, CCTV	Access logs, incident reports
Visitor access	Manage non-employee site access	Security / Front Desk	All operating domains	Visitor log, escort records
EHS / safety	Manage safety programs and compliance	EHS / Safety Manager	All operating domains, contractors	Safety records, corrective actions
Fire / life safety	Protect occupants and respond to fire events	Facilities / EHS	Building systems, first responders	Inspection records, alarm logs
Environmental compliance	Manage environmental obligations	EHS / Compliance	Construction, fuel systems, cooling	Permit records, inspection logs
Construction activity	Manage active construction on campus	Construction / EPC	All domains during construction phase	RFIs, daily logs, safety records
Vendor management	Coordinate third-party service providers	Operations / Procurement	All operating domains	Service records, work orders
Customer support	Manage day-to-day customer requests and issues	Customer Success / Ops	Customers, power ops, cooling ops, security	Ticketing system, email records
Commercial / account management	Manage commercial relationship and obligations	Account Management	Customer support, operations, finance	CRM, contract records
Incident management	Coordinate response to abnormal and emergency conditions	Operations / Incident Commander	All domains	Incident log, post-incident reports
Documentation control	Maintain current operating documentation	Operations / QA	All domains	Document management system

4. Authority Model

Authority types must be explicitly defined and documented. Having access to a system does not confer authority to operate it.

Important Distinction

Viewing data is not the same as operating authority. Monitoring access, control access, maintenance authority, and emergency authority must be explicitly separated — in writing, in training, and in operating procedures.

Authority Type	Meaning	Typical Holder	Control Required
Monitoring authority	Observe, read, and log system status	All operational staff	Read-only access; no control authorization
Operating authority	Direct normal system operation	Qualified operator for domain	Domain-specific training and authorization
Switching authority	Authorize and execute electrical switching sequences	Qualified switching authority	Formal training, written procedure, authorization record
Maintenance authority	Authorize and execute maintenance activities	Maintenance lead / supervisor	PTW issued, LOTO applied, energy isolation verified
Safety authority	Halt or modify work based on safety conditions, including stop-work	EHS / Safety Officer	Must be real, communicated, and protected from override
Security authority	Control access, direct security response	Security Operations Center / Lead	Site security plan, badge system, escalation matrix
Customer communication authority	Communicate officially with customers during incidents	Account Management / Ops Lead	Communication plan, customer escalation matrix
Incident command authority	Lead response to abnormal or emergency conditions	Incident Commander (designated)	Incident response plan, trained backup IC
Load release authority	Approve customer load energization	Operations Lead / Commissioning Manager	Commissioning records, safety checklist, written approval
Commercial approval authority	Approve commercial commitments and changes	Commercial / Executive	Contract authority, escalation to leadership

5. Normal Operations Boundary

Normal operations encompasses routine monitoring, maintenance scheduling, customer requests, access management, performance reporting, and vendor coordination. All of these activities require defined ownership to prevent gaps or duplication.

Activity	Primary Owner	Supporting Teams	Customer Interface	System of Record
Daily operations review	Ops Lead / Shift Supervisor	All domain leads	Summary available on request	Shift log, CMMS
Alarm triage	BMS/SCADA operator	Domain-specific team	Notification if customer-impacting	Alarm log, ticketing system
Work order review	Maintenance Lead	Facilities, Power, Cooling	Coordination required for customer-area work	CMMS / work order system
Preventive maintenance	Facilities / Maintenance	OEM vendors, power team	Change management notification	CMMS, maintenance records
Security access review	Security Operations	HR, Facilities	Customer access requests processed	Access control system, log
Customer ticket review	Customer Support	Ops, power, cooling, connectivity	Direct customer interface	Ticketing system, CRM
Power/cooling trend review	Power and Cooling leads	BMS/SCADA, facilities	Capacity reporting cadence per contract	EPMS, BMS historian
Carrier ticket coordination	Connectivity / Ops	Carrier NOC, customer	Customer notification of carrier events	Carrier ticketing, NOC records
Site walkdowns	Operations / Security	Facilities, EHS	No direct customer role unless on-site	Inspection logs, round records
Documentation updates	Ops Manager / QA	All domain leads	Customer-facing docs updated per contract	Document management system
Shift handoff	Outgoing / Incoming Shift Supervisors	All domain operators	Open customer issues communicated	Shift log, handoff record

6. Abnormal Operations Boundary

Abnormal conditions require pre-defined response paths. Without them, teams default to improvisation — which creates safety risk, customer communication failures, and compounding outage duration.

Abnormal Condition	First Responder Team	Required Notification	Escalation Trigger	Customer Communication Rule
MV alarm	Campus Power	Ops Lead, facilities	Trip event or sustained alarm	Notify if load-impacting
Building electrical alarm	Facilities / Building Ops	Ops Lead	Active fault or derated redundancy	Notify if customer-zone affecting
Cooling alarm	Cooling Team	Ops Lead, customer support	Temperature excursion or cooling loss	Notify immediately if thermal threshold crossed
Liquid leak alarm	Cooling Team	Ops Lead, EHS, safety	Any confirmed leak	Notify if customer area impacted
Power quality event	Campus Power	Ops Lead, customers	Voltage/frequency excursion outside limits	Notify per contract SLA
Unexpected load step	Customer Support + Power	Ops Lead	Load profile deviation from approved schedule	Direct customer contact required
Security alarm	Security Operations	Security Lead, Ops Lead	Perimeter breach or access violation	No customer disclosure unless directly involved
Fire panel event	Facilities / EHS	Security, Ops Lead, Emergency lead	Any active fire event or suppression discharge	Building evacuation notification
Carrier outage	Connectivity / Ops	Customer Support, customer	Carrier confirmation of outage	Notify customer within SLA timeframe
BMS/EPMS/SCADA comms loss	Controls / OT Team	Ops Lead, IT security	System-wide visibility loss	Notify ops, assess impact before customer notification
Customer equipment fault	Customer Support	Customer, ops team	Confirmed impact to campus infrastructure	Immediate customer contact required
Severe weather watch/warning	Ops Lead / EHS	All campus staff, customers	Issued watch for campus area	Advance customer notification per plan

7. Emergency Operations Boundary

Emergency authority must be pre-defined and understood before any emergency occurs. Life safety overrides all commercial considerations. Emergency responders assume control within their statutory authority and must be supported, not managed.

—Campus incident command must be designated before first energization.
—Emergency shutdown authority must be explicit — who can de-energize what, under what conditions.
—Communication channels during emergencies must be controlled and documented, not ad hoc.
—Customer representatives should be identified in advance and their emergency role defined.

Emergency Type	Incident Lead	Technical Lead	Safety/Security Lead	Customer Role	External Party Interface
Fire	Incident Commander	Facilities / Building Ops	EHS + Security	Evacuate; designated contact	Fire department leads on-site
Injury / medical	EHS / Safety Lead	Operations	Security (access for EMS)	Notified if in customer area	EMS and emergency services
Electrical arc flash or shock	EHS / Safety + Power	Campus Power	EHS isolates area	Evacuate if adjacent	EMS; utility if MV event
Major power fault	Ops Lead / Incident Commander	Campus Power	EHS; security for exclusion zone	Notify immediately	Utility if grid-connected
Major cooling loss	Ops Lead / Incident Commander	Cooling Team	EHS	Notify; potential load curtailment	OEM if equipment failure
Gas / fuel event	EHS / Safety Lead	Plant Ops if applicable	Security + EHS	Evacuate if in zone	Fire dept, gas utility, regulatory
Environmental release	EHS Lead	Facilities	EHS	Notify if in affected area	Regulatory agencies as required
Security threat	Security Operations Lead	Operations	Security	Secure customer areas; restrict movement	Law enforcement
Severe weather / tornado	Ops Lead	Facilities + Power	Security + EHS	Shelter-in-place notification	NOAA / local emergency management
Cybersecurity incident affecting operations	OT Security / IT Security	Controls team	IT Security	Notify if customer data or systems affected	Cyber incident response, legal if required
First responder site access	Security / Ops Lead	Facilities	Security manages escort	No role unless their area	Fire, EMS, or law enforcement as applicable

8. Power Operations Boundary

Power operations spans source monitoring, switching, protection event management, metering, maintenance isolation, load release, and emergency response. Each function requires a defined owner, procedure, and evidence record.

Power Function	Campus Power Team	Facilities / Building Team	Customer	Required Procedure
Source status monitoring	Owns and monitors	Receives alarms	Read-only visibility per contract	Monitoring SOP
Feeder switching	Owns; qualified switching authority required	Notified before switching	Notified if customer-impacting	Written switching procedure
Protection event review	Leads investigation	Supports building-level review	Notified of root cause	Protection event report
Metering validation	Owns utility and campus metering	Submetering within building	Billing metering data per contract	Metering calibration records
Planned outage	Schedules and owns process	Supports building isolation	Change management notification required	Outage planning procedure
Maintenance isolation	Switching authority owns LOTO coordination	Supports equipment isolation	Notified of impact window	LOTO procedure, PTW
Load step approval	Validates campus capacity	Confirms building capacity	Requests load step; receives approval	Load release procedure
Emergency shutdown	Authority defined in ERP	Supports local isolation	Evacuate; follow campus direction	Emergency response plan
Customer load increase	Reviews campus capacity impact	Reviews building capacity	Submits request per change process	Capacity change procedure
Power quality investigation	Leads MV/LV investigation	Supports building-level analysis	Provides load profile data	Power quality event procedure

9. Cooling Operations Boundary

Cooling operations require clear boundaries between campus-owned systems and customer-interfacing systems, particularly for high-density liquid cooling deployments where the demarcation between CDU and customer rack can involve significant safety and liability considerations.

Cooling Function	Operator Scope	Customer Scope	Coordination Trigger	Evidence / Monitoring
Plant operation	Campus owns entirely	No role	Customer load changes affect plant setpoints	BMS, plant SCADA
Loop pressure/flow	Campus monitors and maintains	No direct access	Excursion triggers notification	BMS historian, flow records
Temperature setpoint	Campus controls per SLA	May request adjustment per contract	Customer load step or thermal alarm	BMS setpoint log
Fluid chemistry	Campus owns and maintains	No role	Contamination or system expansion	Chemistry test records
Leak detection	Campus monitors system-wide	Customer monitors within racks if liquid-cooled	Any confirmed leak — immediate escalation	Leak detection system, BMS
CDU alarms	Campus operates CDUs	Receives notification of customer-side alarms	CDU fault or thermal limit	BMS alarm log, maintenance records
Rack-level cooling	Campus not responsible inside customer rack	Customer owns rack-level components	Thermal excursion from customer load	Customer DCIM, campus BMS trend
Thermal excursion	Campus leads response	Customer must curtail load if directed	Any measured temperature above threshold	BMS alarm, incident report
Planned maintenance	Campus schedules, owns isolation	Change management notification	Impairment to cooling redundancy	CMMS, maintenance records
Cooling capacity expansion	Campus leads design and installation	Customer may fund or request	New load commitment or customer upgrade	Project records, commissioning

10. OT/IT and Monitoring Boundary

OT systems are operational infrastructure, not ordinary enterprise IT. They directly control physical systems — switchgear, transformers, cooling pumps, UPS, fire suppression, and access control. Treating them as standard IT creates safety and security risk.

System	Data Visibility	Control Authority	Cybersecurity Boundary	Escalation Owner
SCADA	Operations and authorized management	Qualified operators only	Segregated OT network; no direct internet exposure	OT Security / Ops Lead
EPMS	Operations; customer read-only per contract	Campus power team only	OT network; audited remote access	OT Security / Power Lead
BMS	Operations; customer portal view where contracted	Facilities / controls team only	OT network; change-controlled	OT Security / Facilities Lead
Fire / life safety monitoring	Security operations, EHS, Ops Lead	AHJ-approved personnel only	Isolated system; audited access	EHS / Facilities
Security / access control	Security operations only	Security operations only	Dedicated security network	Security Lead
CCTV	Security; legal / HR for incident review	Security operations only	Security network; retention policy	Security Lead
Tenant portal	Customer read access to scoped metrics	No control; read-only portal	Customer-facing DMZ; isolated from OT	IT / Ops
Customer DCIM integration	Customer visibility into agreed data points	No campus control from customer side	API boundary; authenticated and audited	IT / OT Security
Carrier portal	Connectivity team	Connectivity team only	Carrier-managed; campus-side demarcation	Connectivity / IT
Ticketing system	Ops, customer support, customers	Operations / support team	Standard enterprise security	IT / Ops

11. Security Operations Boundary

Physical security is an operating domain, not a vendor service. Access control, visitor processing, escort requirements, CCTV management, incident response, and law enforcement coordination must be procedurally defined and actively managed.

Security Activity	Security Team	Facilities / Ops	Customer	Recordkeeping
Visitor approval	Owns final authorization	Coordinates work-area access	Submits request; provides sponsor	Visitor log, approval record
Contractor access	Validates credentials and authorization	Confirms work order/PTW	No role unless their vendor	Contractor log, PTW record
Tenant access	Issues and manages credentials	Supports area designation	Manages their own staff lists	Badge system, access log
Delivery routing	Controls entry; screens if applicable	Receives delivery in authorized area	Coordinates expected deliveries	Delivery log
Badge issuance	Issues, activates, deactivates	Provides area access requirements	Requests badges per process	Badge system log
Escort assignment	Assigns escort for non-credentialed visitors	Supports in facilities areas	No direct role	Visitor log, escort sign-off
CCTV review	Security operations only	No access	No access	Viewing log; incident request records
Security incident	Leads response; law enforcement interface	Supports evacuation or lockdown	Directed by security/ops during incident	Incident report, access log
Restricted area exception	Approves with escalation	Documents work justification	May request for specific work	Exception request, approval record
Access audit	Conducts periodic access review	Provides area changes and staff changes	Validates their own access list	Audit report, corrective actions

12. Customer Operations Boundary

Customer operating scope varies significantly by commercial model. The boundaries below describe how responsibility differs across offering types.

Powered Land Customer

—Owns and operates all systems inside their facility
—Responsible for load profile compliance
—Responsible for their own safety and security within their boundary
—Interfaces with campus via delivery point, metering, and escalation matrix
—Must coordinate planned load changes and construction activity

Powered Shell Customer

—Campus provides building shell and power to designated points
—Customer installs, owns, and operates IT, cooling, and systems within shell
—Customer responsible for internal safety and building systems compliance
—Interfaces with campus for power, access, connectivity, and carrier services
—Must coordinate any work affecting shared systems

Turnkey Colocation Customer

—Campus operates all shared infrastructure, cooling, power, and building systems
—Customer installs and operates IT equipment only within defined rack/cage
—Customer responsible for equipment installation, operation, and compliance to facility rules
—Access managed by campus security; customer credentials issued
—Load profile must stay within contracted capacity

Carrier / Network Provider

—Authorized to access demarcation and meet-me room only
—No access to compute or power infrastructure
—Coordinates with campus connectivity team for any network work
—Must follow visitor/contractor rules for any physical access
—Escalation through campus connectivity team

13. Change Management Boundary

All changes to campus infrastructure, systems, configurations, load profiles, or access rights must be classified and approved before execution. Uncontrolled changes are a leading cause of outages.

Change Type	Approval Owner	Notice Requirement	Customer Impact Review	Backout Requirement
Emergency change	Ops Lead / Incident Commander	Post-hoc notification	Assess during; notify immediately if impacting	Document in incident record
Standard change	Pre-approved per change library	Per standard cadence	Only if on pre-approved impact list	Standard backout procedure
Normal planned change	Change management board or designated owner	Minimum advance notice per SLA	Full impact assessment required	Written backout plan required
Customer-impacting change	Change board + account management	Per contract change notice period	Customer approval required	Customer-acknowledged backout plan
Security-sensitive change	Change board + security lead	Security clearance required	Assess customer area impact	Security team validates restoration
OT/control system change	Change board + OT security	Pre-work window required	Assess monitoring/control impact	Control system restore procedure
Power system change	Change board + switching authority	Written switching procedure required	Customer power impact assessment	Restoration switching sequence
Cooling system change	Change board + cooling lead	Thermal risk assessment required	Thermal impact to customer areas	Cooling restore procedure
Network change	Change board + IT/OT leads	Connectivity impact assessment	Customer connectivity impact review	Network restore procedure
Commercial capacity change	Account management + ops + commercial	Contract amendment required	Part of commercial process	N/A — commercial action

14. Incident Management and Escalation

All incidents must be classified by severity on first contact and managed through a defined escalation model. Severity determines communication cadence, escalation path, and closeout requirements.

Severity	Example Conditions	Required Escalation	Communication Cadence	Closeout Requirement
SEV 1 — Critical	Life safety event; major outage; critical shared infrastructure failure	Incident Commander + executive leadership immediately	Continuous until stable; then 30-min updates	Post-incident review; root cause; corrective actions with due dates
SEV 2 — Major	Degraded redundancy; major customer-impacting risk; extended maintenance condition	Ops Lead + department heads + customer account manager	Hourly updates until resolved	Incident report; root cause; corrective actions tracked to closure
SEV 3 — Minor	Localized issue; non-critical alarm; controlled maintenance situation	Ops Lead; notify department lead	Updates at key status changes	Work order closeout; corrective action if applicable
SEV 4 — Informational	Minor service request; no impact; informational alarm	Ticket owner	Response per SLA	Ticket closure and resolution documented

15. Documentation and System of Record

Operating boundaries must be reflected in current, accessible documentation. Stale documentation is an operational hazard — teams revert to tribal knowledge, boundaries blur, and incidents compound.

—Site operations manual

—Emergency response plan

—Switching procedures

—LOTO procedures

—Safety program

—Security plan

—Customer interface matrix

—Maintenance plan

—Escalation matrix

—Contact list

—Load release records

—Commissioning records

—As-built drawings

—Change log

—Incident reports

—Training records

16. Governance and Review Cadence

Boundary matrices should not be static documents. They must be reviewed and updated when the campus changes — new customers, new infrastructure, incidents, expansions, or operational experience all trigger review.

Review Trigger	Participants	Output
New customer onboarding	Ops, account management, customer, security, power, cooling	Updated customer interface matrix; new escalation contacts
New building commissioned	All domain leads, commissioning manager	Updated operating domain matrix; new procedures
Major power system change	Power, controls, OT security, ops lead	Updated switching procedures; revised authority records
Major cooling system change	Cooling lead, facilities, ops lead	Updated cooling boundary procedures
Security incident	Security, ops, EHS, legal if applicable	Updated security procedures; corrective actions
Emergency drill / exercise	All domain leads, EHS, security, account management	Updated emergency plan; training gap corrections
Post-incident review	All teams involved in incident	Root cause report; boundary corrections; updated procedures
Annual governance review	Ops management, all domain leads, account management	Full boundary matrix review; annual sign-off; update log

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.

Related References

Reference

Campus Architecture Reference

Reference

Powered Land Interface Matrix

Reference

Safety, Security & Compliance Framework

Back to Reference Index