# Statewide Data Center Direct Enforcement Architecture: Internal Master Packet and Public-Facing Summary **Research date:** October 8, 2026 **Scope:** Georgia statewide framework, with Project Camellia in Effingham County and QTS Fayetteville in Fayette County treated as independent worked cases **Status:** Legal-engineering design packet; not an executed legal opinion or a substitute for project-specific Georgia counsel ## Executive Summary The research supports a statewide Data Center Direct architecture, but it also draws a bright line around what can and cannot honestly be called existing authority. The strongest defensible structure is **not** “the county gets the power to order a utility to shut off a data center.” Georgia law and the public utility record do not establish that statewide power. Georgia counties are creatures of delegated authority, and an official Georgia Attorney General opinion states the traditional rule bluntly: if there is doubt about a county's possession of a particular power, the doubt is resolved against the existence of that power. Development authorities, however, have broad statutory project-contracting powers, including the ability to structure leases and project arrangements; Georgia Power has its own Commission-approved contracting and enforcement framework; and Georgia Power's Rules expressly allow discontinuance of service after due notice when a customer violates its service contract or the Rules. citeturn21search7turn21search1turn4view1turn4view2 That leads to the central architectural conclusion: > **DCD should not manufacture governmental authority. It should connect pre-existing or voluntarily contracted authorities through an auditable, deterministic enforcement protocol.** The statewide framework should therefore be a **contract stack**, not a new quasi-regulator: **enumerated public/community commitments → evidence → cure → public authorization → DCD execution → independent effect verification → technical failure procedure → public Full Stop decision → utility's own enforcement process → restoration.** DCD's authority should be deliberately narrow. It should not decide whether a data center is socially good or bad, adjudicate motive, determine electrical safety, or independently decide that a project deserves punishment. It should determine whether a signed authorization package meets the contractually specified conditions, issue only a pre-authorized command from a fixed command set, independently verify the observed result, and create an evidentiary record. The governmental party retains governmental judgment; the operator retains responsibility for safe site engineering; the utility retains control of utility infrastructure; and DCD owns its attestations. The research also changes one earlier assumption materially: **a Georgia-wide DCD system cannot be built around Georgia Power alone.** The Georgia PSC fully regulates Georgia Power but has only limited regulatory authority over Georgia's electric membership corporations and municipal electric systems. Georgia law also gives qualifying commercial/industrial loads of at least 900 kW a one-time supplier choice. Coweta-Fayette EMC expressly advertises customer-choice service, load-management assistance, and demand-shedding options, but I found no official public record conclusively identifying the electric supplier for the QTS Fayetteville campus. Accordingly, the QTS case cannot defensibly be modeled as a Georgia Power site today. The statewide architecture needs a **utility-adapter layer** into which Georgia Power, an EMC, or a municipal utility can plug its own contract, forms, API, human workflow, and operating constraints. citeturn27search0turn19search1 Project Camellia is different. Official sources identify Georgia Power as its utility and OpenAI as the project party contracting for approximately 3.2 GW. Georgia Power publicly says the 25-year arrangement includes up to 1,000 MW of flexible demand response and gives Georgia Power the ability to reduce energy delivered at certain times for grid stability. OpenAI separately promises an annual independent public audit and says a Georgia Community Compact will turn community priorities into specific commitments and accountability measures. Those are unusually good existing attachment points for DCD—but **the 3,210 MW service contract itself is trade-secret in its entirety**, so its actual default, curtailment, assignment, safety, and termination clauses cannot responsibly be represented from the public record. citeturn28search1turn28search2turn29view0 Official sources spell the project **Project Camellia**; that spelling is used below. citeturn28search2 The recommended enforcement hierarchy is: | Public name | Formal contract name | Consequence | Who actuates | Authority status | |---|---|---|---|---| | **Notice & Cure** | Corrective Action State | No load consequence; formal cure clock | Operator | **Contractually creatable** | | **Kill Switch: Hold** | Graduated Enforcement State A | Freeze incremental load/ramp; no expansion above current authorized ceiling | DCD endpoint/operator control plane | **Contractually creatable** | | **Kill Switch: Throttle** | Graduated Enforcement State B | Reduce to first site-specific flexible-load ceiling | DCD endpoint | **Contractually creatable** | | **Kill Switch: Deep Throttle** | Graduated Enforcement State C | Reduce to minimum contractually interruptible/flexible envelope | DCD endpoint | **Contractually creatable** | | **Kill Switch: Compute Stop** | Graduated Enforcement State D | Designated interruptible compute to zero; preserve only pre-engineered safe-shutdown/essential loads | DCD endpoint | **Contractually creatable** | | **Full Stop** | Utility Backstop Event | Utility curtailment/discontinuance plus operator no-run obligation, if negotiated | Utility under its own procedure | **Existing utility enforcement power + new contractual trigger required; automatic DCD/County trigger unresolved until utility accepts it** | Georgia Power's existing Rule F.2 is important but narrower than a kill-switch advocate might initially hope. When the customer violates its service contract or Georgia Power's rules, Georgia Power **may**, after due notice, “discontinue service [and] treat the contract for service as at an end.” That provides an existing utility enforcement mechanism. It does **not** presently establish that a DCD certificate or county vote is a service-contract default, nor does it make disconnection mandatory. Those pieces have to be negotiated. citeturn4view2turn3view1 The January 2025 PSC order makes that negotiation pathway more credible without predetermining the answer. The Commission approved special rules for very large customers, ordered Georgia Power to give Staff the terms, conditions, and criteria it intends to use before utilizing them in contracting, required complete new contracts and associated attachments to be filed within 30 days after execution, and retained jurisdiction. A material DCD/Full Stop amendment should therefore be put in front of Georgia Power and PSC Staff early rather than presented after local parties have signed it. That last sentence is an inference from the Commission's review architecture, not an express requirement addressing DCD. citeturn33view1 The Camellia record shows that this review architecture is real rather than theoretical: the 3,210 MW contract was submitted for Staff review on July 27, 2026, deemed approved August 26, and filed as an executed trade-secret contract on August 27; a public summary was filed in September. citeturn29view0turn29view1 The most important fairness rule is equally simple: > **The way out must be designed before the way down.** Every switch schedule should contain a restoration condition before it contains an enforcement condition. A project must know exactly what constitutes cure, who verifies it, who authorizes restoration, how utility reconnection works after Full Stop, and whether restoration is staged. Georgia Power's existing Rule F.3 already contemplates restoration/reconnection following discontinuance under its Rules, providing a real utility-side anchor for the Georgia Power case. citeturn3view1 The most important security rule is: > **No single compromised organization should be able to press the button.** The endpoint should require both a cryptographically authenticated Public Authorization Certificate and DCD's execution credential. DCD alone cannot create the authorization; the public actor alone cannot generate a valid DCD command. Commands must be narrowly allowlisted, short-lived, idempotent, and incapable of providing a general-purpose remote-control path into the facility. Hardware-backed key custody, strong authentication, least privilege, protected audit records, and segmented operational-technology access align with NIST's current security, identity, and log-management guidance and CISA's OT remote-access recommendations. citeturn12search0turn12search1turn12search3turn12search2 Finally, **failure of a Kill Switch is itself a defined event, not an improvisational crisis**. DCD should make three idempotent transmission attempts over a five-minute verification window, contact the operator immediately, open a 12-hour Technical Cure Window, and—if the required state still cannot be verified—issue a factual Failure Certificate. It should not certify “refusal” unless refusal is separately evidenced. It certifies what it knows: valid authorization, valid transmission, DCD's own system health, observed acknowledgments, verification attempts, and the absence of verified required state. The matter then leaves DCD and returns to the designated public authority. That division of responsibility is the key to making the model defensible from every chair in the room. ## Source Record and Authority Map The legal architecture rests on four different kinds of authority. They should never be blurred: **Existing authority** means the public record presently gives the actor the relevant power. **Contractually creatable** means an actor appears to possess enough underlying contracting power to negotiate the obligation, but the obligation does not presently exist merely because DCD proposes it. **Technical design** means a security or process control, not a legal power. **Unresolved** means the public materials do not establish the answer and the packet should say so. A source limitation is important: the internal Hermetic/DCD site-files connector failed during this research run, and the internal governance-record search returned no DCD records. Therefore, DCD's existing internal capabilities are **not** represented here as independently documented company policy. DCD-specific functionality is based on the architecture supplied in this conversation and is treated below as proposed design unless supported elsewhere. **Controlling and high-value source register** | Source | What it establishes | Weight in this packet | |---|---|---| | Georgia Power Rules & Regulations §§ concerning ≥100 MW customers and contract enforcement | Georgia Power can require special terms for very large load; contract/rule default can lead to discontinuance after due notice; restoration exists | Primary utility/regulatory foundation. citeturn4view0turn4view1turn4view2turn3view0 | | PSC January 2025 order, Docket 44280 | Large-load special contracting framework; Staff visibility before use; contract filing after execution; retained PSC jurisdiction | Primary regulatory foundation. citeturn33view1 | | PSC September 2026 Data Center Fact Sheet | PSC's current public description of large-load/data-center oversight and contract protections | Primary current regulatory summary. citeturn29view2turn29view3 | | Executed 3,210 MW filing | Camellia contract reviewed and deemed approved; actual contract confidential/trade-secret | Establishes the public-information ceiling. citeturn29view0 | | Georgia Power Camellia announcement | 25-year arrangement; ~3,200 MW; up to 1,000 MW flexible demand response; utility can reduce delivered energy in certain grid conditions | Existing Camellia curtailment capability, not a DCD trigger. citeturn28search1 | | OpenAI Camellia announcement | OpenAI role, phased 3.2 GW, annual independent audit, Community Compact proposal and community commitments | Existing accountability attachment points. citeturn28search2 | | Georgia Attorney General development-authority opinion | Confirms statutory development-authority lease/project powers under Chapter 36-62 | Primary interpretation of DA authority. citeturn21search1 | | Georgia Attorney General county-authority opinion | Counties possess delegated powers; doubt as to a particular county power is resolved negatively | Critical guardrail against invented county authority. citeturn21search7 | | Georgia Open Meetings materials | Covered public authorities act under open-government requirements; public action cannot simply be replaced by private DCD judgment | Basis for transparent governmental authorization. citeturn11search0turn11search4 | | Georgia PSC electric-regulation page | PSC fully regulates Georgia Power, has limited authority over EMCs/municipals; ≥900 kW qualifying customers have supplier choice | Necessitates utility-neutral statewide architecture. citeturn27search0 | | Fayette County QTS public statement | Real-world AMI/meter mismatch was found and corrected; County/QTS now coordinate monthly | Strong case for independent telemetry, verification, and recurring exercises. citeturn18search2 | | City of Fayetteville QTS ordinance | QTS development agreement was incorporated into zoning; substantial compliance with its obligations is a continuing zoning condition | Local contract/regulatory attachment point, though underlying agreement remains needed. citeturn10view0 | | Coweta-Fayette EMC economic-development materials | Fayette-area EMC participates in customer choice and offers demand shedding/load-management designs | Demonstrates that a non-Georgia-Power backstop model is technically/contractually plausible; does not prove QTS supplier identity. citeturn19search1 | | NIST/CISA security guidance | Least privilege, authenticated identity, audit/log management and protected OT remote access | Technical-control foundation. citeturn12search0turn12search1turn12search3turn12search2 | **Authority-by-provision matrix** | Provision | Status | Defensible basis and required mechanism | |---|---|---| | Community may submit evidence or complaints | **Existing / policy-creatable** | Public bodies can receive public input; Camellia already contemplates public engagement and a Community Compact. A complaint itself must have no actuation authority. citeturn28search2 | | County unilaterally creates a statewide data-center shutdown power | **Unresolved / do not assume** | No researched Georgia source establishes it; county powers cannot be invented from policy preference. citeturn21search7 | | Development authority places operating/accountability conditions in project agreements | **Underlying authority exists; specific DCD condition contractually creatable** | Chapter 36-62 project/lease authority is broad, but the specific provision must actually be contracted and project counsel must validate scope. citeturn21search1 | | DCD appointed independent verifier/technical agent | **Contractually creatable** | Add DCD as named verifier/agent in relevant development, operator, and community-accountability agreements; no public record currently creates that role. | | Operator maintains a DCD enforcement endpoint | **Contractually creatable** | Operator agreement/control schedule must define API/interface, command states, safe envelope, availability, change control and credentials. | | DCD directly decides breach | **Reject** | This would unnecessarily combine adjudication and execution and is not supported by identified law. Public/contractual authorizer decides; DCD verifies conditions and executes. | | DCD directly controls Georgia Power switches | **Unresolved; reject as default** | No public source grants DCD that access. Georgia Power should specify its own interface if it wants a machine interface at all. | | Georgia Power imposes specialized large-load contract conditions | **Existing authority** | Current Rules and PSC framework expressly allow specialized terms for ≥100 MW customers. citeturn4view0turn4view1turn33view1 | | Georgia Power discontinues service following customer contract/rule default | **Existing discretionary authority** | Rule F.2 authorizes discontinuance after due notice. citeturn4view2turn3view1 | | DCD Failure Certificate automatically constitutes Georgia Power default | **Contractually creatable in concept; acceptance unresolved** | Must be inserted into the customer service contract/rider and reviewed through the PSC/Georgia Power process. F.2 alone does not create it. citeturn4view2turn33view1 | | Georgia Power must automatically disconnect on a county/DCD event | **Unresolved until agreed** | Existing F.2 says Georgia Power *may* act; mandatory treatment would require negotiated language and regulatory review. citeturn4view2 | | Full Stop includes shutdown of backup-powered compute | **Contractually creatable with operator; not created by utility disconnection alone** | This is an architectural consequence: a utility controls utility service, while an operator agreement must govern continued operation from behind-the-meter resources. | | Public meeting on every ordinary Kill Switch | **Not established as mandatory** | Open-government law governs official public-body action, but research did not identify a statute specifically requiring a town hall for DCD enforcement. citeturn11search0turn11search4 | | Full Stop public hearing before referral | **Contractually/policy creatable; recommended decision** | Self-imposed due-process safeguard. It should be distinct from whatever minimum Open Meetings Act procedure independently applies. | | PSC directly presses or authorizes DCD switches | **No identified authority / not recommended** | PSC's existing role is regulatory oversight of Georgia Power, not facility-level DCD actuation. citeturn27search0turn33view1 | | Same Georgia Power backstop used at QTS automatically | **Unresolved and presently indefensible** | QTS's electric supplier is not established by the official public sources located; Georgia Power rules cannot be presumed to govern it. citeturn27search0turn19search1 | | Monthly non-actuating endpoint exercise | **Contractually creatable / technical design** | No cited rule mandates monthly frequency; the frequency is a DCD reliability decision informed by standard secure-operation principles. citeturn12search0turn12search2 | | Immutable audit/event records | **Contractually creatable / technical best practice** | NIST log-management and security guidance strongly support protected, attributable event logging; exact retention is contractual. citeturn12search0turn12search1 | | Automatic binding of successor owner/operator | **Contractually creatable, project-specific** | Requires assignment/assumption language and any required public/utility consents; cannot be presumed from present public materials. | The key legal boundary is consequently **contract jurisdiction rather than geographic jurisdiction**. A DCD switch is defensible when the party whose load is being constrained has previously agreed to the endpoint, triggers, evidence standard, safe operating states, cure rights, verification method, and consequences. The governmental party's authority must likewise come from an actual agreement or independent legal power. DCD's software cannot cure a missing legal predicate. The same discipline applies to Full Stop. The Georgia Power Rules provide the last-mile utility power only when the relevant service-contract/rule conditions exist. The proposed DCD architecture therefore converts a failed operator-side enforcement event into a **defined customer service-contract event**, rather than pretending a county can commandeer a utility. Georgia Power then operates within its own Rule F framework, including due notice and restoration. citeturn4view2turn3view1turn3view0 ## Statewide Architecture and Evidentiary Standard The statewide system should consist of a common **DCD Enforcement Standard** plus project-specific schedules. The standard defines semantics, evidence, records, security, and interfaces. The project schedules define the actual obligations, MW ceilings, flexible workloads, utility, safe-load envelope, cure class, public authorizer, contacts and restoration conditions. That distinction is essential. A statewide document should not guess that 100 MW, 500 MW, or 20% is safe at every site. It should say what a “Throttle” means and require the project's engineers and operator to populate the corresponding value before the agreement becomes effective. The core object model is: ```mermaid flowchart LR C[Community / Monitoring] --> E[Evidence Intake] O[Operator / Project Company] --> E E --> V[DCD Evidence Validation] V --> P[Public Authorizer] P -->|Signed Authorization Certificate| D[DCD] D -->|Bounded Signed Command| X[Site Enforcement Endpoint] X --> T[Independent Telemetry] T --> D O -->|Cure / Safety Evidence| V D -->|Success Certificate| P D -->|Failure Certificate| P P -->|Full Stop Referral if authorized| U[Serving Utility] U -->|Utility Procedure| X2[Utility Service Boundary] R[PSC / Utility Regulator] -. oversight .-> U P -->|Restoration Authorization| D U -->|Utility Reconnection when applicable| X2 ``` **Image-generation prompt — governance architecture:** *Create a clean civic-infrastructure infographic showing a Georgia community, county/development authority, data-center operator, neutral Data Center Direct verification layer, serving electric utility, and Public Service Commission. Show evidence flowing toward a protected authorization chamber, a set of graduated red control states flowing toward the data center, and a separate utility “Full Stop” pathway. Emphasize separation of powers and audit trails, not drama; no exposed passwords, technical endpoint addresses, or generic hacker imagery.* The central separation of duties in that diagram is a deliberate security and governance decision. NIST's control framework emphasizes least privilege, accountability, identity/authentication and protected audit functions; CISA likewise recommends tightly controlled, strongly authenticated and segmented remote access for operational technology. citeturn12search0turn12search2turn12search3 **Stakeholder roles** | Stakeholder | Role inside the DCD framework | Explicit non-role | |---|---|---| | **Community** | Supply concerns/evidence; participate in defined public process; receive nonsecurity public certificates; help define commitments before contracting | Does not possess endpoint credentials or directly order actuation | | **County** | Party/authorizer only to the extent supported by its own contracts or legal authority; public accountability and Full Stop decision where lawfully assigned | Does not acquire technical power merely by hosting the project | | **Development authority** | Principal contractual anchor where it owns/leases/finances the project or is party to economic-development instruments; may designate DCD roles within valid contracts | Does not receive unlimited regulatory authority from its economic-development mission | | **Operator / Project Company** | Engineer safe states; maintain endpoint; cure; provide evidence; invoke bounded safety deferral; execute restoration prerequisites | Cannot silently revoke the agreed control path or unilaterally redefine triggers | | **OpenAI, where contractually applicable** | In Camellia, disclosed project/development/customer party; can bind project commitments and accountability structures within its agreements | Should not be assumed to be the ultimate facility operator because OpenAI says the operating model still has work remaining. citeturn28search2 | | **DCD** | Validate authorization package; execute allowed command; verify observable state; maintain record; certify success/failure | Does not judge political desirability, motive, electrical safety or underlying law | | **Serving utility** | Own utility-side service relationship, due notice, safety and any Full Stop procedure | DCD does not operate utility infrastructure unless utility itself explicitly designs such an interface | | **PSC** | For Georgia Power, regulatory oversight of company rules and large-load contracting; limited role for EMC/municipal systems | Not the routine switch dispatcher. citeturn27search0turn33view1 | **RACI matrix** `A` = accountable; `R` = performs; `C` = consulted; `I` = informed. “Public Authorizer” means whichever County or development-authority actor is actually empowered by the controlling instrument. | Activity | Community | Public Authorizer | Development Authority | Operator / Project Co. | DCD | Utility | PSC | |---|---:|---:|---:|---:|---:|---:|---:| | Define enforceable project commitments before closing | C | A | R/A where agreement party | C | C | C for utility terms | C for Georgia Power terms where required | | Submit concern/evidence | R | I | I | I | R intake | I | I | | Determine evidence completeness | I | I | I | C | R/A | I | I | | Cure alleged breach | I | I | I | R/A | C/verify | C if utility issue | I | | Make legal/contractual breach finding | I | A | A if DA instrument | C | C only | I | I | | Issue Public Authorization Certificate | I | R/A | R/A if designated | I | C | I | I | | Execute Kill Switch | I | A as authorization owner | I | C | R | I | I | | Verify resulting state | I | I | I | C | R/A | C if its telemetry used | I | | Invoke site-safety deferral | I | C | I | R/A through designated safety officer | Verify record only | C | I | | Issue DCD Failure Certificate | I | I | I | C | R/A | I | I | | Decide Full Stop referral | C/public process | R/A | R/A if agreement requires | C | I | C | I | | Provide utility due notice and execute utility backstop | I | I | I | C | I | R/A | Oversight as applicable | | Verify cure | I | C | C | R | R technical | C | I | | Authorize local restoration | I | A | A where relevant | C | R verify | I | I | | Restore utility service after Full Stop | I | I | I | R prerequisites | C | R/A | Oversight as applicable | | Annual accountability audit | I/public recipient | A for public delivery | C | R information | R/C | C | I | **Exact evidentiary standard** A super-defensible process should avoid making operational consequences depend on adjectives such as “serious concern” or “reasonable belief.” The agreement should use defined evidence states. | Evidence state | Exact threshold | Permitted consequence | |---|---|---| | **E0 — Intake** | Identifies a specific enumerated obligation, approximate event/time, source and requested review | Investigation only | | **E1 — Prima Facie Record** | Either one authenticated primary/system-of-record item or two independent attributable observations which, if accurate, would establish noncompliance | Formal Notice & Cure only | | **E2 — Verified Breach** | The contractual threshold is objectively met; source provenance is documented; evidence is authenticated; operator response is attached; and either two independent evidentiary channels corroborate the event **or** one dispositive official/documentary record establishes a purely documentary obligation | Public breach finding and movement toward enforcement | | **E3 — Enforcement Ready** | E2 plus applicable cure period has expired; no unresolved material contradiction remains; all contractual prerequisites are checked; and the proper public actor has signed the Authorization Certificate | A specified Kill Switch may be actuated | | **E4 — Backstop Ready** | E3 plus a DCD Failure Certificate establishes that the authorized Kill Switch did not produce a verifiable required state within the Technical Cure Window, followed by the contractually required Full Stop public process | Utility Backstop referral | This evidence architecture is a **contractual design**, not a Georgia statutory evidence code. Its purpose is to prevent community allegations, political pressure, or one ambiguous sensor from directly actuating infrastructure. Evidence should also be typed: **Technical evidence** includes meter readings, aggregate load, endpoint acknowledgments, timestamps and control-plane telemetry. It normally requires independent corroboration. **Documentary evidence** includes an executed obligation, missed filing, unpaid funded obligation, required audit, permit, report or other objectively ascertainable document. A single authoritative record can be dispositive when the fact is inherently documentary. **Observational/community evidence** can initiate E0/E1 but cannot by itself authorize a Kill Switch. It has to be converted into authenticated inspection, measurement or documentary evidence before E2. **Material contradiction rule:** if two comparably authoritative sources disagree about the fact needed for actuation, the record does not advance to E3. The existing state is preserved, an independent measurement/reconciliation process begins, and the contradiction is recorded rather than averaged away. That rule is particularly well justified by the Fayette QTS experience. Fayette County publicly reported that, during conversion to new advanced meters, some meters remained connected to the old system and were not linked into the new digital billing/usage system; the County and QTS corrected the problem, all meters were linked, and the parties now meet monthly. That is an actual local example in which “the number in the system” and the physical state were temporarily not the same thing. citeturn18search2 **Default cure classes** These are proposed contractual defaults, not statutory deadlines. | Cure class | Example | Default cure period | |---|---|---:| | **Documentary** | Missing report, audit, certification, payment or required filing | 10 business days | | **Operational** | Measurable ongoing departure that can be corrected without outage | 72 hours | | **Resource/threshold** | Water, noise, traffic, load or other repeatedly measurable threshold | 24 hours after authoritative confirmation unless the project schedule specifies a necessary measurement interval | | **Repeated material breach** | Same verified obligation breached after prior cure | 24 hours | | **Emergency** | Only a separately enumerated condition involving immediate threat for which existing law/agreement authorizes immediate action | No ordinary cure before the authorized protective action; post-action review required | An emergency category must not become “we are angry and do not want to wait.” It needs a separate enumerated predicate and an actor who actually has emergency authority. The authorization clock and the actuation clock are intentionally different: ```mermaid sequenceDiagram participant C as Community / Monitor participant P as Public Authorizer participant O as Operator participant D as DCD participant U as Utility C->>D: E0 evidence submission D->>O: Evidence notice O-->>D: Response / cure evidence D->>P: E2 record when verified P->>O: Formal cure notice O-->>P: Cure or contest alt Cure verified D-->>P: Cure certificate P-->>O: Matter closed else Cure expires and E3 satisfied P->>D: Signed Authorization Certificate D->>O: Kill Switch command immediately D->>D: Independent effect verification alt Required state verified D-->>P: Success Certificate else Required state not verified D->>O: Technical Failure Notice Note over O,D: 12-hour Technical Cure Window alt State becomes verifiable D-->>P: Delayed Success Certificate else Still unverified D-->>P: Failure Certificate P->>P: Full Stop public process P->>U: Full Stop Referral if authorized end end end ``` **Image-generation prompt — evidence and authorization:** *Design a high-clarity process illustration showing evidence entering a verification chamber, a data-center company receiving a meaningful opportunity to cure, a public authority issuing a digitally signed authorization only after the record is complete, and DCD instantly actuating a bounded control after authorization. Visually emphasize that the long deliberative process occurs before the red control is pressed, while actuation after approval is immediate.* ## Enforcement, Full Stop, and Restoration The recommended system has **four real Kill Switch states plus Full Stop**. The values are intentionally semantic statewide and numeric locally. A statewide standard should never say “Throttle means 25%.” It should say “Throttle means the value in Site Schedule KS-B,” and the site agreement cannot become effective until qualified engineers, the operator, and any relevant utility have filled in that value and identified the loads capable of reaching it safely. | Level | Public name | Exact statewide meaning | What must be populated locally | Typical authorization threshold | |---|---|---|---|---| | Normal | Normal Operation | No DCD enforcement limit | Contracted normal/ramp profile | None | | KS-A | **Hold** | The enforcement endpoint prevents aggregate controlled load from increasing above the pre-event permitted ceiling | MW ceiling; measurement source; exclusions | E3 after ordinary cure | | KS-B | **Throttle** | Reduce controlled flexible load to Site Schedule B ceiling | MW ceiling, ramp rate, excluded safe loads | E3; verified material breach | | KS-C | **Deep Throttle** | Reduce controlled flexible load to lowest pre-engineered sustainable enforcement state | Minimum flexible-load envelope; safe-transition rate | E3; repeated/severe breach and explicit higher-level authorization | | KS-D | **Compute Stop** | All contractually interruptible compute in the DCD-controlled envelope stops; only Safe Shutdown Loads remain | Exact definition of interruptible compute and Safe Shutdown Loads | Highest project-side threshold; written high-impact authorization | | UBE | **Full Stop** | Serving utility initiates its negotiated backstop and operator enters the contractually defined Full Stop Operational State | Utility procedure; due notice; meter/service points; backup-power no-run rule; restoration | E4 plus Full Stop public process | ```mermaid stateDiagram-v2 [*] --> Normal Normal --> Hold: E3 authorization Hold --> Normal: cure + restoration Hold --> Throttle: higher authorized state Throttle --> Hold: partial restoration Throttle --> DeepThrottle: higher authorized state DeepThrottle --> Throttle: restoration DeepThrottle --> ComputeStop: higher authorized state ComputeStop --> DeepThrottle: restoration Hold --> Failure: state not verified Throttle --> Failure: state not verified DeepThrottle --> Failure: state not verified ComputeStop --> Failure: state not verified Failure --> TechnicalCure: operator notified TechnicalCure --> RequestedState: verified within 12 h RequestedState --> Hold RequestedState --> Throttle RequestedState --> DeepThrottle RequestedState --> ComputeStop TechnicalCure --> FailureCertificate: still unverified FailureCertificate --> FullStopHearing FullStopHearing --> ExistingSwitch: referral denied FullStopHearing --> UtilityBackstop: referral authorized UtilityBackstop --> FullStopOperationalState: utility executes FullStopOperationalState --> RestorationReview: cure package RestorationReview --> DeepThrottle: staged restart ``` **Image-generation prompt — Kill Switch ladder:** *Create an engineering-style vertical ladder labeled Normal, Hold, Throttle, Deep Throttle, Compute Stop, and Full Stop. Show progressively narrower power/compute envelopes, but preserve a visible protected strip for life safety and safe shutdown through the operator-side levels. Make Full Stop visually separate and owned by the serving utility, with a public-authority gate between Compute Stop and Full Stop.* The phrase **Full Stop** should have two components. This resolves a major loophole. First, the serving utility performs its agreed utility-side action. For Georgia Power that action must operate through the service contract and Georgia Power's Rules; Rule F.2 provides existing discretionary authority to discontinue service after due notice for customer default. citeturn4view2turn3view1 Second, the operator enters a **Full Stop Operational State** under its own agreement. That state should prohibit non-safety compute from continuing from batteries, generators, microgrids or other behind-the-meter sources. This second component is a design inference: disconnecting a utility service boundary is not logically equivalent to forbidding operation from another source. The operator contract therefore has to close that gap. **Failure-to-comply protocol** At `T0`, DCD validates that the Public Authorization Certificate is genuine, unexpired, applicable to the correct site, and authorizes exactly the requested Kill Switch level. DCD then issues one signed, idempotent command. If the endpoint does not produce a valid acknowledgment, DCD retransmits the **same command identifier**, rather than creating a second enforcement event, at approximately `T+60 seconds` and `T+180 seconds`. Independent state verification continues through `T+5 minutes`. At five minutes, if the required state is not independently verifiable, DCD opens an Enforcement Verification Incident and immediately contacts the operator through the primary and secondary agreed channels. DCD provides its command receipt and its evidence that its own system operated normally. The operator then receives the agreed **12-hour Technical Cure Window**. This is not a new political cure of the underlying violation. It is time to repair an endpoint, reconcile telemetry, complete safe execution, or demonstrate that the state was actually achieved. A safety deferral may operate inside this window, but **safety deferral is not cure**. The original authorization remains in the record. At expiration, DCD makes one of only three determinations: | DCD technical determination | Meaning | |---|---| | **Verified Success** | Required state is independently observable | | **Verification Inconclusive** | Reliable sources remain materially contradictory; escalation is paused pending independent reconciliation unless the agreement provides a separate safety rule | | **Enforcement Verification Failure** | DCD can establish valid authorization and valid DCD execution attempts, but the required state remains unverified after the cure window | DCD should **not** label the third result “operator refusal” without independent evidence of refusal. Misconfiguration, hardware failure, revoked credentials, a deliberate refusal, or an unforeseen safety condition may look identical from the outside. The Failure Certificate does not need motive to have contractual significance. **Full Stop / Utility Backstop procedure** The final branch should be deliberately slower and more public than an ordinary switch. The statewide default should be: `Failure Certificate → public record package → five-business-day Full Stop hearing notice → hearing and written finding → Full Stop Referral → utility's own due-notice procedure → utility execution`. The five-business-day hearing period is a proposed contractual due-process protection, not an existing statutory requirement. Any longer statutory/local notice applies. An emergency bypass should exist only when a separate source of emergency authority independently authorizes it; DCD itself never creates an emergency power. A Full Stop hearing should answer only defined questions: 1. Is the underlying obligation enumerated in the executed agreement? 2. Was E3 validly reached? 3. Was the Kill Switch authorization valid? 4. Does the DCD Failure Certificate satisfy its required form? 5. Has the 12-hour Technical Cure Window expired? 6. Is a safety or verification dispute still genuinely unresolved? 7. Does the executed utility agreement make this event eligible for the Utility Backstop? 8. Is Full Stop still proportionate and contractually permitted? 9. What are the predetermined restoration conditions? Georgia's Open Meetings framework supplies the broader transparency environment for covered public bodies, but the research did not identify an existing law specifically called a “Full Stop hearing.” That hearing is therefore a deliberately self-imposed protection, not a claim about current Georgia statutory procedure. citeturn11search0turn11search4 For a Georgia Power project, the negotiated utility rider should not say “DCD may disconnect Customer.” It should say, in substance: > **Utility Backstop Event.** Customer acknowledges and agrees that a Valid Full Stop Referral issued pursuant to the DCD Enforcement Schedule following an uncured Enforcement Verification Failure constitutes a specified event under this Contract for Service. Upon receipt, Company shall initiate the Utility Backstop Procedure set forth in Exhibit [__], including all notice, safety, system-reliability, and regulatory requirements applicable to Company. Nothing in this provision authorizes DCD or a local governmental party to operate Company facilities. **Status: contractually creatable in concept; Georgia Power and PSC treatment unresolved.** Georgia Power's existing Rules permit discontinuance for service-contract/rule default after due notice, and the large-load framework permits specialized contracting, but nothing publicly reviewed makes a DCD certificate such a default today. citeturn4view1turn4view2turn33view1 For maximum enforceability rather than mere discretion, the negotiating target would go one step further: > Upon a Valid Full Stop Referral, Company shall, subject to applicable law, Commission requirements, system reliability, electrical safety, and the terms of this Agreement, initiate the defined Utility Backstop Procedure. If Company determines that the specified action cannot lawfully or safely be completed, Company shall issue the Public Authorizer and Customer a written Backstop Exception Notice stating the legal, regulatory, safety, or system condition preventing execution and, if temporary, the earliest permissible execution condition. That clause cannot be presented publicly as existing Georgia Power policy. It is an insertion to negotiate. **Restoration is the reverse of escalation, not a reset button.** The operator first files a Cure Package identifying the original obligation, corrective action, supporting records, current endpoint health, safety state and any recurrence-control measures. DCD verifies only the technical portions assigned to it. It issues a Cure Verification Record but not the legal restoration decision. The same public actor that owns the relevant authorization then issues a Restoration Authorization. Where utility service was curtailed/disconnected, the utility controls utility reconnection in accordance with its own rules and agreement. Georgia Power Rule F.3 supplies an existing restoration/reconnection framework after discontinuance under its Rules. citeturn3view1 Restoration then proceeds through the pre-engineered states in reverse unless the Site Schedule allows a faster path: `Safe Shutdown State → KS-C envelope → KS-B envelope → KS-A/Hold → Normal`. Each site must have its own required stability period, because there is no defensible statewide number for the time a particular electrical/cooling/computing system should remain at each level. ```mermaid flowchart LR A[Full Stop or Kill Switch State] --> B[Operator Cure Package] B --> C[DCD Technical Verification] C -->|Incomplete| B C -->|Verified| D[Public Restoration Authorization] D --> E{Utility disconnected?} E -->|Yes| F[Utility Reconnection Procedure] E -->|No| G[Staged Restore] F --> G G --> H[Deep Throttle State] H --> I[Throttle State] I --> J[Hold State] J --> K[Normal Operation] K --> L[Post-event Review and Public Certificate] ``` **Image-generation prompt — restoration:** *Create a reassuring technical illustration of a data center returning from a protected stopped state through clearly gated stages—safe shutdown power, deep throttle, throttle, hold, normal operation. Show DCD verifying each technical state, the public authority authorizing restoration, and the utility separately reconnecting service when relevant. The visual should communicate that enforcement has a designed path home.* **Complete branch tree** ```mermaid flowchart TD A[Concern or automated finding] --> B{Enumerated obligation?} B -->|No| B1[Reject as non-enforceable intake] B -->|Yes| C{E1 evidence?} C -->|No| C1[Request more evidence / close] C -->|Yes| D[Notify operator and open cure] D --> E{Operator response} E -->|Cure proven| E1[DCD verifies cure] E1 --> E2[Close and publish permitted cure status] E -->|Disputes evidence| F{Material contradiction?} F -->|Yes| F1[Independent reconciliation] F1 -->|Breach not established| E2 F1 -->|Breach established| G F -->|No| G[E2 Verified Breach] E -->|No cure| G G --> H{Applicable cure expired?} H -->|No| D H -->|Yes| I{Public authorization valid?} I -->|No| I1[No actuation] I -->|Yes| J[E3 Enforcement Ready] J --> K[DCD validates signatures, scope, expiry] K --> L{DCD security healthy?} L -->|Compromise suspected| L1[Freeze commands and invoke alternate-verifier procedure] L1 --> L2{Alternate verifier validly appointed?} L2 -->|No| L3[Remain at current safe state; public process] L2 -->|Yes| K2[Alternate executes validated authorization] L -->|Healthy| M[DCD sends idempotent Kill Switch command] K2 --> M M --> N{Required state verified within 5 min?} N -->|Yes| N1[Success Certificate] N1 --> N2[Maintain state until restoration] N -->|Ambiguous telemetry| O[Reconcile independent measurements] O -->|Verified success| N1 O -->|Verified no effect| P[Technical Failure Notice] O -->|Still ambiguous| O1[Verification Inconclusive: no higher escalation solely from ambiguity] N -->|No| P P --> Q[Immediate operator contact + 12 h Technical Cure Window] Q --> R{Operator claims safety impediment?} R -->|Yes| R1[Signed Safety Deferral Record] R1 --> R2{Claim substantiated under Site Schedule?} R2 -->|No| S R2 -->|Yes| R3[Safe execution plan within allowed window] R3 -->|State achieved| N1 R3 -->|Not achieved| S R -->|No| S{Required state verified by cure deadline?} S -->|Yes| N1 S -->|No| T[DCD Failure Certificate] T --> U[Return to Public Authorizer] U --> V[Full Stop public process] V --> W{Full Stop authorized?} W -->|No| W1[Remain at authorized lower state / negotiated resolution] W -->|Yes| X{Utility rider actually exists?} X -->|No| X1[Backstop structurally unavailable: public unresolved status] X -->|Yes| Y[Full Stop Referral to serving utility] Y --> Z{Utility accepts referral?} Z -->|Disputes validity| Z1[Contract/utility dispute process; no DCD bypass] Z -->|Safety/system deferral| Z2[Utility Backstop Exception Notice] Z2 --> Z3[Execute when utility condition permits or return unresolved] Z -->|Yes| AA[Utility due notice and backstop procedure] AA --> AB{Utility-side action succeeds?} AB -->|No| AB1[Utility incident process; DCD records no independent workaround] AB -->|Yes| AC[Operator Full Stop Operational State] AC --> AD{Operator running prohibited compute on backup power?} AD -->|Yes| AD1[Separate operator-contract default] AD -->|No| AE[Full Stop verified] AE --> AF[Operator Cure Package] N2 --> AF AF --> AG{Ownership/operator changed?} AG -->|Yes, assumption incomplete| AG1[No restoration beyond safe state until assignment/assumption complete] AG -->|No or completed| AH[DCD Cure Verification] AH --> AI{Public Restoration Authorization?} AI -->|No| AI1[Maintain current state] AI -->|Yes| AJ{Utility reconnection required?} AJ -->|Yes| AK[Utility reconnection process] AJ -->|No| AL[Staged restoration] AK --> AL AL --> AM[Normal operation] AM --> AN[Post-event audit and public nonsecurity report] ``` **Image-generation prompt — failure and Full Stop:** *Create a decision-tree infographic centered on a failed data-center enforcement command. Show three possible explanations—technical failure, ambiguous measurement, or validated safety deferral—being sorted before escalation. After a 12-hour technical cure window, show DCD issuing a factual failure certificate, then stepping completely out of the decision role while a public hearing gates a separately owned utility Full Stop process.* ## Security, Verification, Audit, and Contingencies A real Kill Switch deserves stronger security than a monitoring dashboard because an authenticated command produces a real operational state change. The safest architecture is therefore **dual-domain authorization**. A valid command requires: `valid Public Authorization Certificate + valid DCD execution signature + correct site/level + unexpired command window + permitted endpoint state transition`. Neither DCD nor the public authority alone has enough information/credential material to produce an accepted command. The operator endpoint should not expose a general-purpose administrative interface to DCD. It should accept a very small state vocabulary: for example `HOLD`, `THROTTLE_B`, `THROTTLE_C`, `COMPUTE_STOP`, and restoration states expressly enabled by a separate Restoration Authorization. The command object should include a unique identifier, site identifier, requested state, authorization-record hash, issuance/expiration times and nonce. Repeated delivery of the same command ID must be idempotent so retries cannot compound the action. Execution signing keys should be hardware-backed and non-exportable; operators should authenticate endpoints mutually; credentials should be rotated under documented change control; and command access should use the least privilege necessary. These are design implementations of NIST identity/security principles and CISA's recommendation to strongly authenticate and tightly bound OT remote access. citeturn12search0turn12search3turn12search2 **The operator must retain a physical/site safety override.** The important contractual decision is that using it cannot silently erase enforcement. Invocation creates a signed Safety Override Event and immediately enters the safety-deferral/failure branch. A DCD compromise should work the same way in the other direction. Suspected compromise freezes DCD execution credentials. Existing physical state remains unchanged; DCD does not issue “protective” emergency commands merely because it has lost trust in itself. A contractually named Alternate Verifier can take over only after a separate appointment/credential procedure. That prevents the cure for a DCD cyber incident from becoming an unreviewed infrastructure action. The security relationship can be represented as follows: ```mermaid erDiagram PUBLIC_AUTHORIZATION ||--|| ENFORCEMENT_COMMAND : authorizes DCD_EXECUTION_SIGNATURE ||--|| ENFORCEMENT_COMMAND : signs SITE_ENDPOINT ||--o{ ENFORCEMENT_COMMAND : receives ENFORCEMENT_COMMAND ||--o{ COMMAND_RECEIPT : produces SITE_ENDPOINT ||--o{ TELEMETRY_RECORD : emits ENFORCEMENT_COMMAND ||--|| VERIFICATION_EVENT : evaluated_by TELEMETRY_RECORD ||--o{ VERIFICATION_EVENT : supports VERIFICATION_EVENT ||--o| SUCCESS_CERTIFICATE : may_create VERIFICATION_EVENT ||--o| FAILURE_CERTIFICATE : may_create FAILURE_CERTIFICATE ||--o| FULL_STOP_REFERRAL : may_support RESTORATION_AUTHORIZATION ||--o{ RESTORATION_COMMAND : authorizes AUDIT_MANIFEST ||--o{ ENFORCEMENT_COMMAND : indexes AUDIT_MANIFEST ||--o{ TELEMETRY_RECORD : indexes ``` **Image-generation prompt — security and custody:** *Create a sober cybersecurity architecture visual with two independent physical keys—one held by the authorized public decision-maker and one by Data Center Direct—both required to open a narrow command gateway. Beyond the gateway show only four pre-approved operating states, never a generic admin console. Add independent telemetry and an immutable evidence vault. Avoid hacker clichés; make it look like safety-critical industrial control governance.* **Audit record** Every event should create a signed Event Manifest containing at minimum: | Field | Purpose | |---|---| | Contract/Site ID | Prevent cross-site command confusion | | Obligation ID and clause version | Proves which commitment was invoked | | Evidence Packet hash | Freezes the factual record at authorization | | Public Authorization Certificate ID/hash | Proves upstream authority | | DCD verifier/executor identity | Accountability | | Command ID and requested state | Precise action | | Dispatch/retry times | Reconstruct execution | | Endpoint acknowledgment | Distinguish transport from state effect | | Independent telemetry source IDs | Effect verification | | Clock-health record | Establish timestamp quality | | Operator notifications | Cure/fairness evidence | | Safety-deferral records | Preserve any safety claim | | Verification disposition | Success / inconclusive / failure | | Failure Certificate hash if applicable | Full Stop chain | | Restoration records | Complete lifecycle | | Software/configuration version | Forensics | | Key/certificate identifiers, not secret key material | Cryptographic provenance | NIST's log-management guidance emphasizes collecting and managing logs to support operational troubleshooting, security monitoring and incident investigation, while NIST's broader controls address audit accountability and protection of audit information. citeturn12search0turn12search1 The proposed retention rule is **the longer of seven years after the event, the controlling agreement's record-retention period, or any applicable litigation/investigation hold**. Seven years is a DCD contract design choice, not a NIST-mandated duration. There should be at least three logically separate copies of material enforcement records: DCD's protected evidence store; the operator's record; and a public-authority/independent escrow copy. Public disclosures should expose the event and outcome but not endpoint addresses, trust-store material, detailed network topology, keys, or security-sensitive implementation data. **Monthly Endpoint Exercise Protocol** The monthly test should **never be a production Kill Switch actuation**. Its purpose is to exercise the actual communication and trust path far enough to prove readiness without changing operational load. ```mermaid sequenceDiagram participant D as DCD participant P as Public Test Credential participant E as Site Endpoint participant T as Independent Telemetry participant U as Utility Interface / Contact Path D->>P: Validate monthly test authorization D->>E: Mutual authentication D->>E: Signed non-actuating challenge E-->>D: Signed challenge response D->>E: Read permitted health/status E-->>D: Endpoint health + certificate metadata D->>T: Request independent telemetry freshness check T-->>D: Signed measurement status D->>U: Exercise approved non-operational contact/test path U-->>D: Receipt if utility supports testing D->>D: Verify key expiry, clocks, contacts, config D-->>E: Monthly Exercise Record ``` **Image-generation prompt — monthly exercise:** *Illustrate a monthly “test the pipe, not the switch” procedure. Show DCD and the data-center endpoint exchanging a signed non-actuating challenge, independent telemetry confirming connectivity, certificates and contacts being checked, and a separate utility contact path being exercised without sending any shutdown request. Prominently indicate zero production load change.* A monthly exercise passes only if the site identity authenticates correctly, the endpoint accepts the non-actuating challenge, its signed response is valid, independent telemetry is current, certificates are not unexpectedly revoked/expired, endpoint configuration matches the approved version, and human escalation contacts remain current. If the serving utility exposes a sanctioned test endpoint, portal, REST interface, or acknowledgment mechanism, DCD should use it. **No research source located a Georgia Power DCD-style REST endpoint**, so the architecture must not invent one. Georgia Power should be asked which interface it is willing to support. If its preferred mechanism is a form, portal, control-room telephone procedure, or document in triplicate, the adapter should implement that instead. **Contingency decisions** | Contingency | Required response | Status | |---|---|---| | **DCD compromise suspected** | Freeze DCD command signing; leave physical state unchanged; notify all parties; alternate verifier may act only after its pre-agreed appointment/authentication procedure | Technical/contractual design | | **Public-authority credential compromised** | DCD rejects authorizations from suspended credential; no unilateral substitute; use alternate signer procedure | Technical/contractual design | | **Operator safety claim** | No automatic cancellation. Designated safety officer signs Safety Deferral Record with condition, evidence and proposed safe execution path; DCD verifies record, not safety judgment | Contractually creatable | | **Operator invokes emergency override** | Preserve safe condition; create immediate logged event; start Technical Cure / Failure branch | Contractually creatable | | **Ambiguous telemetry** | No higher-level actuation based solely on ambiguity; preserve current authorized state; obtain independent measurement | Technical/contractual design | | **Operator revokes DCD trust credential without authorized change control** | Endpoint-readiness breach; restore credential path; if during live enforcement, record in Failure Certificate | Contractually creatable | | **Endpoint unavailable before any live dispute** | Monthly exercise failure; maintenance cure, not punitive Kill Switch | Contractually creatable | | **Endpoint unavailable during authorized event** | Five-minute retry/verification protocol, then 12-hour Technical Cure Window | Contractually creatable | | **Utility refuses because no contractual authority exists** | No technical bypass. Classify Full Stop Backstop Unavailable; return to public body and contract/legal remedies | Existing limitation / unresolved | | **Utility disputes DCD certificate** | Apply utility-rider dispute procedure; DCD supplies record but cannot compel utility equipment | Contractually creatable | | **Utility cites system/safety impediment** | Utility issues Backstop Exception Notice and any permissible future execution window; no DCD override | Contractually creatable if utility accepts | | **Ownership/operator change** | Require executed assumption agreement, fresh key issuance, contact refresh and endpoint exercise before uncontrolled ramp/normal restoration | Contractually creatable | | **Change in serving utility** | Existing Full Stop rider terminates or suspends until replacement utility adapter is executed | Contractually creatable | | **DCD ceases business / cannot serve** | Named successor-verifier mechanism; credentials do not automatically transfer to purchaser | Contractually creatable | | **PSC or law changes** | Regulatory-change clause triggers review; no automatic expansion of DCD power | Contractually creatable; underlying legal change controls | | **Public authorizer reverses authorization before execution** | Valid signed revocation cancels any unexecuted authorization; after execution, restoration process applies | Contractually creatable | | **Public authorizer changes its mind after Full Stop referral** | Utility rider defines whether referral can be withdrawn before utility execution; after disconnection, restoration procedure controls | Unresolved until utility agreement | | **Operator continues compute on backup after Full Stop** | Treat as separate no-run covenant default rather than pretending utility disconnection failed | Contractually creatable | ## Worked Cases, Contract Packet, and Stakeholder Redlines **Project Camellia — Effingham County** Camellia is the easier utility case but the harder confidentiality case. The public record establishes OpenAI's approximately 3.2 GW phased project, Georgia Power service, an approximately 25-year power agreement, up to 1,000 MW of flexible demand response, an existing Georgia Power ability to reduce energy delivered in defined grid circumstances, an annual independent public audit commitment, and OpenAI's proposed Georgia Community Compact. citeturn28search1turn28search2 The PSC record establishes a 3,210 MW large-load contract that was reviewed before being deemed approved in August 2026. But the contract was filed as trade secret “in its entirety.” Therefore, nobody relying on public material can responsibly state whether Camellia's contract already contains the cross-default, third-party verifier, assignment, restoration or shutdown language DCD would need. citeturn29view0turn29view1 Camellia's worked implementation should therefore use five independent attachment points: | Camellia instrument | DCD purpose | Current status | |---|---|---| | **Georgia Community Compact / accountability instrument** | Enumerated community commitments, evidence sources, annual audit, cure/reporting | OpenAI says the Compact will translate priorities into specific commitments; exact final terms unresolved. citeturn28search2 | | **Local development/authority agreement** | Public-party authority, remedies, DCD appointment, public process | Underlying project-local instruments need collection/review | | **Operator Control Addendum** | Endpoint, safe states, no-run covenant, technical cure, safety deferral, restoration | Must be negotiated | | **DCD Verification Schedule** | Evidence rules, certificates, logs, security, monthly testing | Must be negotiated | | **Georgia Power Utility Backstop Rider** | Treat qualifying failure/referral as service-contract event and define utility procedure | Must be negotiated; PSC/Georgia Power acceptance unresolved | Camellia has a major practical advantage: **load flexibility is already part of the public deal**. That does not grant DCD any access to it, but it means the parties are not beginning from the proposition that a 3.2 GW AI campus is technically incapable of planned curtailment. Georgia Power and OpenAI already publicly describe up to 1,000 MW of flexible demand response. citeturn28search1 The best Camellia negotiation is therefore not “install a mysterious new shutdown mechanism.” It is: **define an independent authorization and verification layer around site-approved flexible states, while keeping Georgia Power's existing grid-control rights separate.** The operator/OpenAI redline is obvious and legitimate: a community-enforcement trigger cannot silently hijack the same control pathway Georgia Power needs for grid reliability. Commands need distinct authorization domains, priority rules, and conflict behavior. **QTS Fayetteville — Fayette County** QTS is the better demonstration of why the framework must be utility-neutral. The City of Fayetteville ordinance approving the project incorporates a QTS Development Agreement and makes substantial compliance with its covenants, warranties, duties and obligations a continuing zoning condition. That is a significant potential local enforcement anchor, but the ordinance says the underlying agreement is on file with the City Clerk; the full agreement was not present in the public ordinance packet reviewed here. Exact remedies are therefore unresolved until that instrument is obtained. citeturn10view0 Fayette County also has an unusually relevant real-world verification incident. During smart-meter conversion, it discovered meters that were not correctly linked to the new system; the County and QTS corrected tracking/billing, and the County says its teams now meet monthly with QTS. This supports DCD's proposed principles of independent verification, recurring connectivity checks and cure before punishment. citeturn18search2 County procurement records also show an interest in independent audit/verification around the campus's taxable property, reinforcing that third-party verification is not conceptually foreign to the local project structure. citeturn7search5 What cannot presently be said is “Georgia Power will be QTS's Full Stop provider.” The PSC says qualifying ≥900 kW commercial/industrial customers can choose an electric supplier, and Coweta-Fayette EMC actively markets service to customer-choice projects in Fayette and offers demand-shedding/load-management programs. I did not locate an official record conclusively establishing which utility QTS selected. citeturn27search0turn19search1 Accordingly: | QTS instrument | DCD action | |---|---| | Fayetteville Development Agreement | Obtain actual executed agreement first; map every existing covenant/remedy | | FCDA lease/economic-development instruments | Obtain executed lease, bond/economic-development documents and amendments; identify assignment/default/cure provisions | | County water agreement/service terms | Consider only obligations actually appropriate to water; do not use a water dispute to manufacture electric authority | | Operator Control Addendum | Negotiate DCD endpoint independently of local utility identity | | Utility Backstop Rider | **Do not draft utility-specific final language until supplier is verified** | | DCD monthly exercise | Leverage the already demonstrated value of monthly coordination but keep enforcement telemetry independent | This distinction is exactly why Camellia and QTS should remain independent cases. Camellia teaches the Georgia Power/PSC branch. QTS teaches the development-agreement, verification, and utility-adapter branch. **Master contractual packet** The statewide packet should be a short core agreement plus schedules rather than one sprawling instrument. **DCD Enforcement Master Schedule — proposed operative language** > **Enumerated Trigger Limitation.** No DCD enforcement action may be authorized for conduct unless the applicable obligation, objective trigger, evidence source, cure class, maximum enforcement state, and restoration condition are expressly identified in the executed Obligation Register. No implied, analogous, retroactive, or public-pressure-based trigger shall be sufficient. > **Non-Adjudicatory Role of DCD.** DCD shall not determine the legal validity, public desirability, motive, or culpability associated with an alleged breach. DCD's role is limited to verifying completion and authenticity of required process records; executing an otherwise valid Authorization Certificate through the agreed endpoint; observing defined technical indicators; and issuing technical certificates required by this Schedule. > **Bounded Command Set.** Operator shall maintain the Enforcement Endpoint capable only of entering the states expressly described in the Site Enforcement Schedule. DCD shall have no remote administrative shell, unrestricted building-management access, or other general operational authority by virtue of this Agreement. > **No Operator Veto by Endpoint Disablement.** Operator shall not revoke, disable, materially alter, or prevent authentication of an approved Enforcement Endpoint except under the Change-Control or Safety-Override procedures. Unauthorized disablement does not establish intent, but shall be recorded as an Endpoint Availability Failure and treated in accordance with the Technical Failure procedure. > **Safety Deferral.** Nothing in this Schedule requires execution of a state transition that the Designated Site Safety Officer determines in good faith would create an immediate and material risk to human life, fire protection, electrical equipment integrity, or safe shutdown. Any such determination shall be contemporaneously signed, identify the specific condition and evidence, state the safe alternative or required delay, and shall not constitute cure of the underlying enforcement event. > **Failure Certification.** If, following the required DCD transmission attempts and expiration of the Technical Cure Window, DCD cannot verify the Required State, DCD shall issue an Enforcement Verification Failure Certificate. Such certificate shall state technical facts only and shall make no finding of intent, willfulness, legal liability, or entitlement to utility action. > **Full Stop No-Run Covenant.** Upon a valid Full Stop Operational State becoming effective, Operator shall cease all non-safety compute identified in the Site Schedule regardless of whether such load is supplied from utility service, standby generation, battery storage, microgrid resources or another on-site source. Safe Shutdown Loads identified in the Site Schedule may remain energized. > **Restoration First Principle.** Each enforceable obligation shall contain an objectively determinable restoration condition before the obligation becomes eligible for DCD enforcement. No enforcement state shall be designed without a corresponding route to restoration. > **Assignment and Assumption.** No transfer of control, ownership, operational responsibility, leasehold interest, or other interest identified in the Project Schedule shall release the affected project from this Schedule. Where an assignment is permitted, the successor shall execute an assumption instrument, establish replacement credentials, complete an Endpoint Exercise, and satisfy any utility/public-party consent requirements before ordinary ramp rights resume. **Utility Backstop Rider — Georgia Power negotiating draft** > Customer and Company acknowledge that the DCD Enforcement Schedule is an associated project agreement governing specified operating obligations of Customer. A Valid Full Stop Referral shall have effect under this Contract for Service only to the extent expressly stated in this Rider. > Upon receipt of a Valid Full Stop Referral, Company shall authenticate the referral using the procedure in Exhibit U-1 and shall initiate the Utility Backstop Procedure, subject at all times to applicable law, Commission orders and rules, electric-system reliability, electrical safety, and Company's operational control of its facilities. > Customer acknowledges that an uncured Enforcement Verification Failure meeting all conditions of Exhibit U-2 constitutes a specified contractual default/event for purposes of this Rider. > Any discontinuance, curtailment or restoration of utility service shall be performed exclusively by Company or its authorized agents. Nothing in the DCD Enforcement Schedule grants DCD, County, Development Authority or any other third party access to Company operational facilities or controls. > If Company cannot execute the requested Utility Backstop action, Company shall provide the designated parties a Backstop Exception Notice identifying whether the impediment is legal, regulatory, operational, safety-related, evidentiary, or temporary and, where applicable, the condition required before the procedure can resume. That rider uses Georgia Power's existing F.2 enforcement model as a foundation without falsely claiming F.2 already contains the DCD trigger. Georgia Power's actual approval and PSC treatment remain unresolved until negotiated. citeturn4view2turn33view1 **Required forms** The system should not rely on free-form emails during a live enforcement event. **Form DCD-E1 — Notice of Potential Enforceable Breach** ```text PROJECT: SITE ID: NOTICE ID: DATE/TIME ISSUED: ENUMERATED OBLIGATION ID: CONTROLLING AGREEMENT / SECTION: ALLEGED EVENT WINDOW: EVIDENCE CLASS: Technical / Documentary / Observational SOURCE RECORDS: HASH / RECORD IDENTIFIERS: APPLICABLE CURE CLASS: CURE DEADLINE: MAXIMUM ENFORCEMENT LEVEL AUTHORIZED BY OBLIGATION: OPERATOR RESPONSE CHANNEL: PUBLIC AUTHORIZER: DCD CASE ID: NOTICE: This document opens the contractual verification and cure process. It is not an authorization to actuate any DCD enforcement state. ``` **Form DCD-E2 — Verified Breach Record** ```text CASE ID: OBLIGATION: OBJECTIVE TRIGGER: TRIGGER VALUE / REQUIRED CONDITION: OBSERVED VALUE / CONDITION: PRIMARY EVIDENCE: INDEPENDENT CORROBORATION: OPERATOR RESPONSE: CONFLICT ANALYSIS: CURE ACTIONS CLAIMED: CURE STATUS: E2 FINDING: AUTHORIZED SIGNATORY OF PUBLIC PARTY: DATE/TIME: CERTIFICATION: The undersigned determines, solely under the controlling agreement, that the record satisfies the defined E2 Verified Breach standard. No DCD actuation is authorized by this form. ``` **Form DCD-A1 — Public Authorization Certificate** ```text AUTHORIZATION ID: PROJECT / SITE: EVIDENCE RECORD HASH: OBLIGATION ID: AUTHORIZED ENFORCEMENT STATE: EARLIEST EXECUTION TIME: EXPIRATION TIME: CURE DEADLINE SATISFIED: Yes / No REQUIRED PUBLIC ACTION / VOTE ID: SAFETY PREREQUISITES CONFIRMED AS REQUIRED BY AGREEMENT: RESTORATION CONDITION REFERENCE: PUBLIC AUTHORIZER: SIGNING CREDENTIAL ID: DIGITAL SIGNATURE: CERTIFICATION: The Public Authorizer certifies that the contractual prerequisites assigned to the Public Authorizer have been satisfied and authorizes DCD to execute only the Enforcement State stated above. ``` **Form DCD-T1 — Technical Failure Notice** ```text CASE / AUTHORIZATION ID: COMMAND ID: REQUIRED STATE: INITIAL DISPATCH: RETRY 1: RETRY 2: DCD CONTROL-PLANE HEALTH: Pass / Fail ENDPOINT ACKNOWLEDGMENT: Yes / No / Invalid INDEPENDENT STATE VERIFICATION: RESULT: Required State Not Yet Verifiable OPERATOR CONTACT TIME: TECHNICAL CURE WINDOW BEGINS: TECHNICAL CURE WINDOW EXPIRES: SAFETY-DEFERRAL PROCEDURE AVAILABLE: Yes / No NOTICE: DCD has not verified the required operational state. This notice does not determine cause or intent. ``` **Form DCD-F1 — Enforcement Verification Failure Certificate** ```text DATA CENTER DIRECT ENFORCEMENT VERIFICATION FAILURE CERTIFICATE Certificate ID: Project / Site: Public Authorization ID: Authorized Enforcement State: Obligation ID: Evidence Packet Hash: I, [AUTHORIZED DCD VERIFIER], certify solely as to the technical and procedural facts assigned to DCD under the DCD Enforcement Schedule: 1. DCD received Public Authorization Certificate [ID] at [timestamp]. 2. DCD validated the certificate's signature, scope, site identity, enforcement state, and validity period. 3. DCD's execution systems passed required pre-dispatch health checks. 4. DCD transmitted Command [ID] at [timestamp]. 5. The same idempotent Command [ID] was retransmitted at [timestamp] and [timestamp] in accordance with the retry procedure. 6. DCD attempted independent verification using: [verification sources]. 7. At [timestamp], DCD notified Operator that the Required State had not been verified. 8. The Technical Cure Window expired at [timestamp]. 9. As of issuance of this Certificate, DCD cannot verify that Required State [state] has been achieved. DCD DOES NOT, BY THIS CERTIFICATE: - determine whether Operator acted intentionally or willfully; - determine legal liability or breach beyond DCD's assigned technical role; - determine electrical or personnel safety; - order any utility to discontinue service; or - determine whether the Public Authorizer should invoke the Utility Backstop. Disposition: ENFORCEMENT VERIFICATION FAILURE Signed: Name / Role: DCD signing credential: Timestamp: Certificate hash: ``` That wording is deliberately stronger because it is narrower. “I cannot verify that it happened, and here is exactly why” is more defensible than “they refused.” **Form PUB-FS1 — Full Stop Referral** ```text FULL STOP / UTILITY BACKSTOP REFERRAL Project / Site: Public Body: Date of duly authorized action: Meeting / Resolution ID: Failure Certificate ID: Underlying Obligation: Current Enforcement State: Technical Cure Window expiration: Utility Backstop Rider / Section: Required Utility Procedure: Restoration Conditions: Authorized Utility Contacts: The Public Body hereby transmits this Referral pursuant to the executed Utility Backstop Rider. This Referral does not itself operate utility equipment and shall have only the effect provided by the applicable utility agreement, law, rules, and utility procedures. ``` **Form DCD-R1 — Restoration Certificate** ```text PROJECT / SITE: ORIGINAL ENFORCEMENT EVENT: CURE PACKAGE ID: CURE CONDITION: DCD TECHNICAL VERIFICATION: ENDPOINT EXERCISE: Pass / Fail SECURITY / CREDENTIAL HEALTH: Pass / Fail CURRENT SAFE STATE: PUBLIC RESTORATION AUTHORIZATION: UTILITY RESTORATION REQUIRED: Yes / No UTILITY RESTORATION RECORD: AUTHORIZED NEXT STATE: STABILITY CONDITION / OBSERVATION REQUIREMENT: FINAL NORMAL-OPERATION AUTHORIZATION: PUBLIC REPORT ID: ``` **Form DCD-M1 — Monthly Endpoint Exercise Record** ```text SITE: MONTH: TEST AUTHORIZATION: ENDPOINT ID: MUTUAL AUTHENTICATION: Pass / Fail NON-ACTUATING CHALLENGE: Pass / Fail SIGNED RESPONSE: Pass / Fail INDEPENDENT TELEMETRY FRESHNESS: Pass / Fail CLOCK SYNCHRONIZATION: Pass / Fail CERTIFICATE / KEY EXPIRY CHECK: Pass / Fail CONFIGURATION VERSION: Pass / Fail PRIMARY CONTACT: Verified / Update Required SECONDARY CONTACT: Verified / Update Required UTILITY BACKSTOP CONTACT / TEST PATH: Verified / Not Available PRODUCTION LOAD CHANGED: NO EXCEPTIONS: CORRECTIVE DEADLINE: DCD VERIFIER: ``` **Stakeholder redline posture** | Stakeholder | Legitimate redline | DCD answer | |---|---|---| | **Community** | “Can the operator simply ignore the switch?” | No. Endpoint availability is contractual; an unverified result enters a documented 12-hour technical cure and then a Failure Certificate / Full Stop branch. | | **Community** | “Can they cure privately and pretend nothing happened?” | Cure can restore operations, but the nonsecurity status/certificate should remain in the public accountability record. | | **Community** | “Is Full Stop fake?” | It is real only where the serving utility has actually signed the backstop rider. Until then, public materials must label it unavailable/proposed rather than imply it exists. | | **County / DA** | “Are you making us electrical engineers?” | No. Public body decides only contractual/governmental questions; DCD verifies assigned technical facts; operator/utility own safety engineering. | | **County / DA** | “Are we exceeding authority?” | No assumption is permitted. Each obligation must identify the agreement/statute providing the public party's hook. | | **Operator / OpenAI** | “Can one angry official shut down billions of dollars of infrastructure?” | Not under this design. Enumerated triggers, evidence gates, cure, signed authorization, bounded switches, public Full Stop process and restoration are predetermined. | | **Operator / OpenAI** | “What about a false sensor?” | Two-channel verification or dispositive documentary evidence; unresolved material contradictions block higher escalation. | | **Operator / OpenAI** | “What if compliance would damage equipment or endanger people?” | Signed safety deferral protects immediate safety without erasing the underlying event. | | **Operator / OpenAI** | “Can DCD roam our BMS/SCADA?” | No. Narrow allowlisted endpoint only. | | **Operator / OpenAI** | “Can the rules change after we invest?” | No retroactive implied trigger; amendments follow agreed change control. Changes in law are separately handled. | | **Georgia Power / utility** | “Does DCD tell us how to operate our grid?” | No. Utility defines and owns its backstop procedure, due notice, safety and interface. | | **Georgia Power** | “Will local enforcement interfere with grid demand response?” | Utility curtailment and community enforcement are separate authorization domains with documented priority/conflict rules. Camellia already has a separate grid-flexibility arrangement. citeturn28search1 | | **PSC** | “Has a private intermediary acquired utility authority?” | No. DCD acts only on the customer/project endpoint; utility action remains utility action under approved rules/contracts. | | **DCD** | “Are we deciding breach or accepting unlimited liability?” | DCD factually certifies its assigned technical process. Legal breach, public authorization, electrical safety and utility action remain elsewhere. | | **DCD** | “Can somebody compromise us and stop a site?” | Not if the endpoint requires both valid public authorization and DCD execution credentials. | | **Successor owner** | “Did we inherit a secret system?” | No transfer without disclosure, assumption agreement, credential replacement and witnessed endpoint exercise. | The most important negotiation principle is **not equal pain; it is real commitment**. The community gives up the idea that anger alone should stop a lawful project. The operator gives up the ability to make accountability purely voluntary. Government gives up ad hoc improvisation. DCD accepts auditable responsibility for what it certifies. The utility accepts only the backstop obligations it has deliberately signed. Each party receives defined protection precisely because each party also accepts a binding constraint. ## Public-Facing Summary and Negotiation Checklist **Public-facing summary** ### Data Center Direct Kill Switches and Full Stop Data Center Direct's proposed Georgia framework is designed around a simple principle: **a community promise should be enforceable, and enforcement should still be fair to the company that made the promise.** A community complaint cannot press a button. A county official cannot invent a violation. Data Center Direct cannot decide that a company deserves to be shut down. A utility does not surrender control of its electric system. Instead, every enforceable commitment is written down in advance with the evidence that proves it, the time allowed to correct it, the consequence if it is not corrected, and the exact path back to normal operation. When a concern is raised, the evidence is tested against the written agreement. The data-center company receives the evidence and a defined opportunity to correct the problem. If the issue is corrected, the process stops. If an enforceable breach remains, the legally designated public authority—not DCD—may authorize one of several graduated **Kill Switches**. **Hold** prevents further load growth. **Throttle** reduces the site's agreed flexible workload. **Deep Throttle** reduces it further. **Compute Stop** stops the designated interruptible compute while preserving the power needed to shut down safely. Once a valid authorization reaches DCD, the authorized switch is real and immediate. DCD verifies whether the agreed state actually occurred. If it did not, DCD does not argue with the data center or guess why. DCD proves what it sent, shows that its own systems worked, immediately notifies the operator, and provides the agreed technical cure period. If the required state still cannot be verified, DCD signs an **Enforcement Verification Failure Certificate** and returns the matter to the public authority. At that point, a separate final protection may become available: **Full Stop**. Full Stop is not DCD reaching into the electric grid. It is a separately negotiated utility backstop. The public authority holds a final transparent proceeding, confirms that the required conditions were met, and—if it decides to proceed—sends the agreed referral to the site's electric utility. The utility then acts through its own contract, safety requirements, notice obligations, operating procedures and applicable regulation. For a Georgia Power project, Georgia Power already has rules allowing it, after due notice, to discontinue service when a customer violates its service contract or Georgia Power's rules. A DCD Full Stop would work only if the parties first negotiate language making the defined DCD failure event part of that contractual framework. citeturn4view2turn33view1 No public source presently establishes that this DCD trigger has been added to Project Camellia's Georgia Power contract. The actual 3,210 MW contract is confidential. What is public is that the project already includes substantial flexible demand response and that OpenAI has committed to independent annual accountability reporting and further community commitments. citeturn29view0turn28search1turn28search2 For QTS Fayetteville, the local development agreement and existing verification relationships offer possible attachment points, but the serving electric utility and the complete operative agreements must be verified before anyone claims a utility Full Stop exists. citeturn10view0turn18search2turn27search0 The framework therefore makes the same promise to residents and companies: > **Nobody gets surprised. Nobody gets to improvise. Nobody gets an unreviewable veto. And nobody loses the right to fix the problem and come back.** **Negotiation sequence** The first action should be documentary, not political: build a verified closing binder for each worked case. For **Camellia**, obtain under NDA or through the relevant parties the executed large-load service contract and attachments, development-authority/local instruments, final Community Compact when available, operating-party structure, load-flexibility technical schedule, and assignment/default/restoration provisions. Publicly, only the 3,210 MW filing and summary are available; the executed contract's substantive clauses remain confidential. citeturn29view0turn29view1 For **QTS**, obtain the complete Fayetteville Development Agreement referenced by the ordinance, FCDA lease/economic-development/bond instruments and amendments, utility-service documentation identifying the actual electric provider, and relevant water/monitoring agreements. Until the electric provider is proven, the Full Stop column should literally read **“Utility Backstop: Not Yet Established.”** citeturn10view0turn27search0 Then negotiate the project stack in this order: **Obligations first.** No enforcement architecture until the parties know exactly what promise is being enforced and how it is measured. **Restoration second.** Write the cure and return-to-normal condition before deciding the consequence. **Safe load states third.** Operator engineers define Hold, Throttle, Deep Throttle, Compute Stop and Safe Shutdown Loads. **Evidence fourth.** Assign every obligation a primary data source, corroborator, cure class and public disclosure rule. **DCD role fifth.** Add the verifier/endpoint schedules only after the preceding facts exist. **Utility backstop sixth.** Ask the actual serving utility to design the interface it is willing to own. **Security seventh.** Generate credentials only after the legal parties and command states are final. **Exercises last.** A witnessed commissioning test proves that the legal and technical chain actually works before enforcement is represented to the public as real. For Georgia Power specifically, the negotiating question should be precise: > **Will Georgia Power agree, subject to its safety, regulatory and system obligations, that a Valid Full Stop Referral following a contractually defined and independently verified DCD Enforcement Failure is a specified customer-contract event that initiates a predetermined Utility Backstop Procedure?** That question is materially narrower—and more defensible—than asking whether Georgia Power will “give counties a kill switch.” The PSC's existing large-load framework already contemplates specialized contractual terms, Staff visibility into those terms, complete contract filings, and continuing Commission jurisdiction. citeturn4view0turn4view1turn33view1 **Negotiation checklist** - [ ] Identify the **actual legal entity** owning, leasing, developing and operating each campus; do not collapse OpenAI, Project Company, operator, QTS, owner and tenant into one actor. - [ ] Identify the **actual serving electric utility** for every site from executed records. - [ ] Obtain every operative development, lease, economic-development, utility, zoning, water, bond and community-accountability agreement. - [ ] For every proposed DCD obligation, write beside it: **Existing Authority / Contractually Creatable / Technical Design / Unresolved**. - [ ] Delete any provision whose only justification is “this would be useful.” - [ ] Populate the Obligation Register with objective trigger, evidence, cure class, maximum Kill Switch and restoration condition. - [ ] Require that raw community allegations can begin review but cannot directly actuate infrastructure. - [ ] Require independent corroboration for technical triggers and a material-contradiction stop rule. - [ ] Define the public actor authorized to issue each level of Authorization Certificate. - [ ] Have Georgia counsel confirm whether that actor may exercise/delegate the assigned authority under the actual project instrument. - [ ] Define Hold, Throttle, Deep Throttle, Compute Stop and Safe Shutdown Loads in MW/operational terms for each site. - [ ] Obtain operator engineering sign-off on allowable transitions and ramp rates. - [ ] Keep grid-demand-response authority distinct from DCD community-enforcement authority. - [ ] Implement two-domain cryptographic authorization so neither DCD nor the public party can actuate alone. - [ ] Prohibit general-purpose DCD access to the operator's control network. - [ ] Define the physical/site safety override and signed Safety Deferral process. - [ ] Define exactly three idempotent transmission attempts over the five-minute live verification window. - [ ] Adopt the 12-hour Technical Cure Window after an unverified live command. - [ ] Adopt the factual Failure Certificate language and prohibit DCD from certifying intent it cannot observe. - [ ] Create the Full Stop public process and five-business-day default hearing notice. - [ ] Identify any statutory/open-meeting notice that is longer and make the longer requirement control. - [ ] Negotiate the actual serving utility's Utility Backstop Rider. - [ ] For Georgia Power, pre-engage regulatory counsel and PSC Staff rather than presenting a completed rider after signature, consistent with the Commission's large-load review framework. citeturn33view1 - [ ] Ask the utility to specify whether its accepted interface is API, portal, signed electronic form, telephone/control-room protocol, physical filing, or another process; do not invent an interface. - [ ] Define what happens when the utility says **no**, says **not yet**, or says **unsafe**. - [ ] Add the Full Stop no-run covenant so utility disconnection is not defeated by continued prohibited compute behind the meter. - [ ] Define utility and operator restoration before commissioning enforcement. - [ ] Add successor/assignment/assumption language and mandatory key replacement on change of control. - [ ] Establish protected audit replication, evidence hashes, timestamp integrity, retention and litigation-hold rules consistent with the security program. citeturn12search0turn12search1 - [ ] Define a public certificate format that reveals obligations, actions and outcomes without exposing control-system security data. - [ ] Run the non-actuating Endpoint Exercise every month. - [ ] Run a full workflow tabletop at least annually and after material ownership, utility, endpoint or credential change. - [ ] Commission the system with a witnessed end-to-end test before publicly claiming that any Kill Switch or Full Stop is operational. - [ ] For Camellia, do **not** represent the public 1,000 MW grid-flexibility commitment as DCD authority; negotiate DCD rights separately. citeturn28search1 - [ ] For QTS, do **not** insert Georgia Power Rule F.2 into the worked case until the actual serving utility is proven. - [ ] Publish the final statewide DCD standard so a third Georgia project can adopt the same evidence, certificate, security and branch semantics without inheriting Camellia's or QTS's project-specific legal assumptions. - [ ] Have counsel conduct a final “red-line from every chair” review: **community, county, development authority, operator/project owner, DCD, serving utility and regulator**. - [ ] Do not launch until every path in the branch tree terminates in one of four explicit conditions: **cured, enforced, unresolved with identified legal/technical blocker, or restored**. The resulting architecture is not defensible because it makes everyone comfortable. It is defensible because **every party knows in advance what it can do, what it cannot do, what evidence controls, what happens when technology fails, who owns the next decision, and how the project comes back afterward**.