A behavioral protocol for any edge device to provide engineered inertia at the boundary between variable energy sources and legacy AC grids.
GII defines how an inertia-providing device must behave so that renewables can appear turbine-like to the legacy grid.
Grid instability in renewable-heavy systems frequently arises not from insufficient energy, but from mismatched time constants.
- GPU workloads fluctuate at millisecond scale
- Grid frequency stabilizes at electromechanical timescales (seconds)
- Synchronous generators bridged this gap via spinning mass — passively, for free
Removing that mass without replacing the function introduces a stability deficit. GII defines a behavioral protocol to fill that gap at the grid boundary.
For 120 years, grid stability was a byproduct of spinning steel. Turbines provided four things simultaneously — raw energy, physical inertia, proportional load-sharing (droop), and sustained output. We got all four for free from the same machine.
Renewables break that bundle. Solar and wind produce electrons without spinning mass. The grid loses:
- Inertia — no physical resistance to frequency change
- Droop — no automatic proportional load-sharing
- Signal integrity — frequency becomes noisy without spinning mass to smooth it
Storage addresses energy availability. It does not, by default, address inertia. A battery can store MWh. Without explicit control configuration, it cannot resist frequency change the way a synchronous rotor does.
GII treats inertia as a first-class, protocol-defined grid service — independent of the hardware that provides it.
This matters as much as what it is.
- Not a battery optimization tool. Batteries are one possible implementation. The protocol is hardware-agnostic.
- Not a replacement for synchronous condensers. GII is complementary. It extends the principle to distributed edge hardware.
- Not a new invention. Virtual synchronous machines, grid-forming inverters, and droop control all exist. GII names a behavioral contract that unifies them.
- Not a product. This is a specification framework — closer to TCP/IP than to a router.
- Not a magic bullet. Inertia provision is one layer of grid stability. GII addresses that layer only.
If you are looking for a storage sizing tool, a power electronics product, or a grid planning model — this is not that. If you are looking for a behavioral protocol that tells any inertia-capable device how to act at the grid boundary — this is exactly that.
| This IS | Notes |
|---|---|
| A behavioral protocol | Defines states, transitions, droop curves |
| Physical-implementation agnostic | Flywheel, BESS, synchronous condenser, hybrid — all compliant if they implement the states. See Implementation Boundary below. |
| A structured decoupling architecture | Buffer Layer + Inertia Layer + shared DC Bus |
| A framework for multi-party coordination | Nodes self-organize via shared medium, no messaging required |
| A framework for grid engineers and DC architects | Spec is written for implementers, not theorists |
GII is a behavioral protocol implemented within a power-electronic interface. It does not prescribe:
- Battery chemistry or cell technology
- Flywheel design or bearing type
- DC bus voltage or topology
- Inverter vendor or hardware platform
- Renewable energy source type
However, GII does require:
- A controllable energy reservoir (e.g., BESS, flywheel, hybrid storage, or equivalent)
- An inverter or power converter capable of grid-forming or grid-following operation
- Access to frequency, RoCoF, and voltage measurements at the point of interconnection
GII does not create physical inertia. It shapes active power injection to emulate inertial response through managed control logic at the inverter layer.
The distinction between "hardware agnostic" and "physically unconstrained" matters: GII cannot exist without a reservoir and a controllable interface. What it does not constrain is the physical embodiment of that reservoir. A BESS, a flywheel, a synchronous condenser, or a hybrid system can all be GII-compliant if the control layer implements the behavioral states defined in /spec/.
The turbine era accidentally bundled four roles into one machine. Modern deployments must explicitly re-implement each:
| Turbine Function | 1900s Hardware | 2026 Equivalent |
|---|---|---|
| Raw energy | Water / steam | Solar / grid / BESS |
| Inertia | Steel rotor | GII Inertia Layer |
| Droop / load sharing | Mechanical governor | Droop control logic |
| Sustained supply | Dam / boiler | BESS + reservoir + grid mix |
GII defines the behavioral contract for the inertia role. Everything else is an implementation choice.
For grid-interactive data centers — the primary deployment target — the recommended architecture is:
Grid ←→ [Inertia Layer] ←→ [DC Bus] ←→ [Buffer Layer] ←→ GPU Load
The Inertia Layer is a grid-forming bidirectional inverter — not a rectifier. It converts AC ↔ DC in both directions: absorbing from the grid to charge the reservoir, and injecting back to the grid to provide inertial response. The DC bus sits behind this inverter, not at the grid connection point.
This diagram represents a DC-bus-centric deployment, typical of hyperscale data centers that already operate large DC distribution architectures. In conventional grid interconnections, GII may alternatively be implemented as an AC-coupled grid-forming inverter at the Point of Common Coupling (PCC), without a shared DC bus architecture. The behavioral protocol is identical in both cases; only the physical coupling changes.
The Buffer Layer senses only the load. The Inertia Layer senses only the grid. Neither senses the other's domain.
This single constraint eliminates control-loop instability. The two layers interact only through clean power flow on the shared DC bus — never through control signals.
| Layer | Senses | Ignores | Job |
|---|---|---|---|
| Buffer (inward-facing) | GPU current / load spikes | Grid frequency | Hide millisecond load chaos from the grid |
| Inertia (outward-facing) | Grid frequency / RoCoF / voltage | GPU spikes | Behave like a turbine to the grid |
| DC Bus | Voltage level | Everything else | Shared energy pool + physics-enforced priority |
When a simultaneous event occurs — cloud hits the solar farm while a training job kicks off — both layers draw from the shared DC bus. Bus voltage drops. Physics resolves priority without a control decision:
DC Bus Voltage < threshold → throttle compute load.
Rationale: A training run can pause for 500ms. Grid frequency cannot.
The core spec is designed to apply wherever inertia-providing hardware sits at a grid boundary. The primary documented deployment contexts are:
Hyperscale AI / GPU data centers — the architectural origin. Large dynamic loads with existing BESS and inverter infrastructure. Primary modification is control configuration; hardware upgrades may still be required depending on existing inverter capability.
Renewable-heavy regional grids — areas where solar and wind penetration has reduced mechanical inertia below stability thresholds. GII-compliant nodes act as distributed synthetic inertia.
India-specific deployment context — documented separately in /india. The Indian grid presents distinct conditions: 50 Hz nominal, weak interstate transmission, monsoon-driven solar variability, diesel genset dependency, and POSOCO/Grid Code 2022 compliance requirements. These warrant their own parameter set and scenario library.
See /impl-notes/grid_code_mapping.md for standards alignment across regions.
/gii-protocol
│
├── README.md ← You are here
│
├── /spec
│ ├── 01_states_and_droop.md ← Behavioral states, droop curves, triggers
│ ├── 02_graceful_degradation.md ← Failure behavior, "tired node" signaling
│ ├── 03_island_detection_resync.md ← Islanding reflex + phased re-synchronization
│ └── 04_validation_suite.md ← Red-team test cases
│
├── /sim
│ ├── README.md ← Simulation setup guide
│ ├── grid_noise_generator.py ← Chaos injector for testing
│ └── test_cases.md ← Parameterized versions of validation suite
│
├── /src
│ ├── main_loop.py ← Reference control loop (behavioral skeleton)
│ ├── droop_calc.py ← Droop curve calculations
│ └── island_manager.py ← Island detection + re-sync state machine
│
├── /impl-notes
│ ├── dc_topology.md ← Dual-layer topology for data center deployments
│ ├── grid_code_mapping.md ← Alignment with IEEE 1547, EN 50549, G99, AEMO
│ ├── economics.md ← Ancillary service revenue models
│ └── open_questions.md ← Known hard problems + engineering constraints
│
├── /india ← Region-specific extension (in progress)
│ ├── grid_context.md ← 50 Hz baseline, weak grid params, POSOCO path
│ ├── monsoon_scenarios.md ← India-specific stress test cases
│ └── adani_vizag_case.md ← Illustrative pilot framing (marked speculative)
│
└── /docs
├── concept_origin.md ← Intellectual lineage, multi-model attribution
├── concept_note.md ← 3–5 page portable distillation (coming)
├── turbine_mapping.md ← Old roles → new equivalents
└── CONTRIBUTING.md ← How to contribute topology variants
- Grid engineers evaluating synthetic inertia options for renewable-heavy regions
- Data center power architects designing grid-interactive facilities
- Researchers working on grid-forming inverters, virtual synchronous machines, or inertia markets
- Utilities and grid operators exploring distributed inertia procurement
- Regional developers deploying AI infrastructure in grids with weak inertia (India, Southeast Asia, parts of Africa and Latin America)
GII behavioral states are designed to map to existing interconnection standards. See /impl-notes/grid_code_mapping.md for explicit alignment with:
- IEEE 1547-2020 (US interconnection)
- EN 50549 (EU)
- G99 (UK)
- AS/NZS 4777 + AEMO (Australia/NZ)
- CEA Grid Code 2022 / POSOCO (India) — documented in
/india
v0.1 — Conceptual Framework
This is a protocol specification, not a production implementation. The behavioral spec is complete enough to simulate, discuss, and build toward. Reference implementations in /src are behavioral skeletons — not production code.
Contributions welcome, especially:
- Topology-specific implementations (flywheel-first, BESS-first, hybrid)
- Regional grid code mapping and parameter sets
- Hardware-in-the-Loop test results
- Sizing models for specific deployment scenarios
GII addresses inertia provision at the grid boundary. It does not address:
- Energy capacity planning (storage sizing)
- Generation dispatch
- Transmission planning
- Demand forecasting
Grid instability events attributable to inertia deficits are within scope. Events attributable to energy insufficiency are not.
Status: v0.1 — Initial framework (2025–2026). Open source. See /docs/background/ for development history.