# Grid 2.0 Standards Documentation

> Normative reference for the Grid 2 overlay plane: G2P, GCAP, and DESP, plus member behaviors, allocation domains, failsafe rules, and the G2TF comment cycle. For implementers, utilities, and editors working from the living specs and RFC #1.

## Context Links

- [Agent index](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/llms.txt)
- [Human interactive docs](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff)
- [GitHub repository](https://github.com/g2tf-org/g2tf-standards)

## Repository Metadata

- Repository: g2tf-org/g2tf-standards

- Generated: 2026-08-17T18:32:21.451Z
- Updated: 2026-08-17T22:20:19.265Z
- Runtime: Grok CLI
- Format: Documentation
- Pages: 23

## Page Index

- 01. [Overview](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/01-overview.md) - What the Grid 2 overlay plane is, who implements or comments on it, the three-protocol stack, and the first docs routes after RFC #1.
- 02. [How to read the specs](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/02-how-to-read-the-specs.md) - Status headers, RFC 2119 keywords, living files versus immutable RFCs, independent 26.x lines, and what Draft seeking input still leaves open.
- 03. [Minimum viable domain](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/03-minimum-viable-domain.md) - Smallest Grid 2 domain: one host utility plus one flexible load, transmission-owner constraint provisioning, and the connect-and-manage on-ramp.
- 04. [Overlay and Grid 1](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/04-overlay-and-grid-1.md) - Overlay membership without a perimeter, NERC/FERC/TSO non-interference, coordination without prices, and v26.0 energy-in-the-interval scope.
- 05. [One-minute window](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/05-one-minute-window.md) - One-minute interval clock between ~5-minute market dispatch and sub-second ancillaries, commit-before-open, and the Grid 1-prevails conflict rule.
- 06. [Allocation domains](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/06-allocation-domains.md) - Nested constraint domains, transmission-owner authority, voluntary membership by spec compliance, and commercial terms that stay outside the protocol.
- 07. [Service classes](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/07-service-classes.md) - DESP classes A, B, and C above Grid 1 Firm, curtailment order C then B then A, Firm/Semi-Firm/Flex aliases, and per-interval reclassification.
- 08. [Failsafe model](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/08-failsafe-model.md) - No-surprises fallbacks per element, interval-only commitments, pool ramp limits, and fallback that is locally determinable without a remote peer.
- 09. [Federation](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/09-federation.md) - Allocator announce-and-listen, nested local-to-regional domains, missing-announcement conservative clearing, and partition that does not trip unrelated members.
- 10. [Run Phase 0 shadow mode](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/10-run-phase-0-shadow-mode.md) - Phase 0 dry-run: exchange and track commitments, execute only the Grid 1 baseline, then graduate to Phase 1 local integration and Phase 2 federation.
- 11. [Map workloads to classes](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/11-map-workloads-to-classes.md) - Informative Flex 0–3 and ERCOT CLR/PCLR mappings onto DESP A/B/C, plus what the Allocator never sees inside a facility.
- 12. [Provision constraint inputs](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/12-provision-constraint-inputs.md) - Required Grid 1 constraint set, optional DLR and distribution-factor inputs, input digests, and the rule that peer announcements must not relax local limits.
- 13. [Comment, review, and file errata](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/13-comment-review-and-file-errata.md) - Discussions versus Issues versus PRs, RFC #1 errata label, two-editor review, RFC 2119 and compatibility statements, and decision-log recording.
- 14. [G2P reference](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/14-g2p-reference.md) - Element identity, four message families, one-minute timing, authenticated descriptors and commitments, stale-commitment faults, and unspecified wire format.
- 15. [GCAP reference](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/15-gcap-reference.md) - Clearing inputs, headroom-then-buffers-then-tiered-curtailment, per-class commit outputs, identical-input determinism, and pool and ramp-safety bounds.
- 16. [DESP reference](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/16-desp-reference.md) - Class table and semantics, mandatory C-B-A curtailment order, domain class-policy limits, and open naming, extensibility, and SLA items.
- 17. [Use Member](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/17-use-member.md) - Per-class consume positions, commit-% listen, edge workload mapping, self-dispatch and telemetry MUSTS, ramp limits, and firm-limit fallback.
- 18. [Buffer Member](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/18-buffer-member.md) - Signed charge and discharge offers, committed dispatch before any load curtailment, verified self-dispatch, SoC open items, and standalone Grid 1 schedule fallback.
- 19. [Source Member](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/19-source-member.md) - Supply offers over a forward vector, committed take, forecast-error open items, v26.0 single-class supply, and Grid 1 interconnection fallback.
- 20. [Allocator](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/20-allocator.md) - No-discretion deterministic clearing, constraint-authority inputs, federation announcements, withhold-on-stale, and whole-pool ramp sizing.
- 21. [Document lifecycle](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/21-document-lifecycle.md) - Draft to Proposed to Stable to RFC, YY.N protocol versions, required compatibility statements, and the GOVERNANCE.md decision log.
- 22. [Contributing](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/22-contributing.md) - Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions, and implementation reports from Phase 0 onward.
- 23. [Governance and licenses](https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/23-governance-and-licenses.md) - Editor, contributor, and Task Force roles; rough consensus; CC BY 4.0 spec text and Apache-2.0 code; trademarks; and Grid 1 regulator relationship.

## Source File Index

- `architecture/allocation-domains.md`
- `architecture/design-principles.md`
- `architecture/failsafe-model.md`
- `architecture/federation.md`
- `architecture/overview.md`
- `architecture/temporal-position.md`
- `CONTRIBUTING.md`
- `GOVERNANCE.md`
- `LICENSE`
- `LICENSE-CODE`
- `members/allocator.md`
- `members/buffer.md`
- `members/source.md`
- `members/use.md`
- `NOTICE.md`
- `README.md`
- `rfcs/grid-2-rfc-1.pdf`
- `rfcs/README.md`
- `specs/desp/spec.md`
- `specs/g2p/spec.md`
- `specs/gcap/spec.md`

---

## 01. Overview

> What the Grid 2 overlay plane is, who implements or comments on it, the three-protocol stack, and the first docs routes after RFC #1.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/01-overview.md
- Generated: 2026-08-17T18:26:25.788Z

### Source Files

- `README.md`
- `architecture/overview.md`
- `architecture/design-principles.md`
- `specs/g2p/spec.md`
- `specs/gcap/spec.md`
- `specs/desp/spec.md`
- `rfcs/grid-2-rfc-1.pdf`

---
title: "Overview"
description: "What the Grid 2 overlay plane is, who implements or comments on it, the three-protocol stack, and the first docs routes after RFC #1."
---

`g2tf-org/g2tf-standards` is the Grid 2.0 Task Force (G2TF) canonical standards tree. Grid 2 is a voluntary orchestration overlay on the existing physical grid (**Grid 1**): Member Elements and Allocators exchange authenticated, one-minute messages so surplus transmission and generation headroom can be allocated without replacing NERC, FERC, utility, or TSO/ISO mechanisms. RFC #1 (`rfcs/grid-2-rfc-1.pdf`, August 2026) is the immutable launch snapshot. Normative work after that RFC lives in `architecture/`, `specs/`, and `members/` as independently versioned **26.0-draft** documents with status **Draft — seeking input**.

<Info>
Living specs use RFC 2119 / RFC 8174 keywords. RFCs in `rfcs/` are never edited after publication. Corrections to RFC #1 are Issues labeled `errata` and land in the living files.
</Info>

## Overlay plane

Grid 2 is an overlay network: coordinated by protocol, embedded throughout Grid 1, verified by its aggregate footprint, with **no perimeter** and **no central operator**.

The plane has two element kinds:

- **Member Elements** — digital representatives of real assets: **Use** (flexible load), **Buffer** (storage), **Source** (clean-energy supply).
- **Allocators** — deterministic clearing agents for a constraint domain. Intelligence and discretion live at the edge, not in the Allocator.

Each minute, Members broadcast signed Service Descriptors (per-class consume requests, charge/discharge offers, supply offers). Allocators clear those against Grid 1 constraints provisioned by the transmission owner (and optionally a regional system operator) and return interval-only commitments. Members **self-dispatch** within parameters agreed with the host utility and report verified actuals.

```mermaid
flowchart TB
  subgraph g1["Grid 1 — physical assets and custodians"]
    Load["Load"]
    Stor["Storage"]
    Sup["Supply"]
    TO["Transmission owner / TSO constraint set"]
  end
  subgraph g2["Grid 2 — orchestration plane"]
    Use["Use Member"]
    Buf["Buffer Member"]
    Src["Source Member"]
    Alloc["Allocator"]
  end
  Load --- Use
  Stor --- Buf
  Sup --- Src
  TO -->|"MUST provision local and regional limits"| Alloc
  Use -->|"Service Descriptor (+ consume)"| Alloc
  Buf -->|"Service Descriptor (− discharge / + charge)"| Alloc
  Src -->|"Service Descriptor (− supply)"| Alloc
  Alloc -->|"commit-%"| Use
  Alloc -->|"committed dispatch"| Buf
  Alloc -->|"committed take"| Src
  Alloc <-->|"Federation Announcement"| Alloc
```

Membership is **spec compliance at a provisioned point of interconnection**, not an admission process. Commercial terms (class mix limits, charging, flex-capability enforcement) stay in the domain agreement. The protocol does not create authority; it carries constraints whose authority comes from Grid 1 custodians.

Grid 2 does not replace, modify, or bypass Grid 1:

- Participating assets continue to meet all NERC, FERC, utility, and TSO/ISO requirements.
- Commercial settlements stay on Grid 1’s slower clock (**coordination without prices**).
- On fault, partition, or a missing/stale Commitment, each element reverts to a locally determinable Grid 1 baseline.

### Stated objectives

| Objective | How the overlay approaches it |
|---|---|
| Faster connections | Transmission-owner “connect and manage” on-ramp; smallest domain is one host utility plus one flexible load |
| Higher utilization | Allocate surplus headroom each minute above Traditional Firm (Grid 1) |
| Equal or better reliability | Commit only above Grid 1 primary-control timescales; failsafe to status-quo Grid 1 |
| Cost neutrality for participants | Protocol coordinates operation; prices stay on Grid 1 settlements |
| Downward pressure on non-participant rates | Stated design objective; rate treatment is a Commercial-terms Discussion, not a protocol output |

### v26.0 scope

Version **26.0** is limited to **units of energy consumed and provided inside the one-minute window** on the bulk power system. Sub-minute response, voltage support, IEEE 2030.5 distribution-scale devices, and routing through SSTs / HVDC are out of this line.

## Who implements and who comments

G2TF (`g2tf.org`) maintains this repository in the IETF RFC style. RFC #1 authors are J. Chris Shelton, Brett Galura, AJ Hall, Varun Joshi, and Gregory Phillips. Contact listed in RFC #1 is `aj@g2tf.org`. Living-document **Editors** are currently **TBD** in every spec and architecture header.

| Actor | What they implement or provision | Repo surface |
|---|---|---|
| **Use** implementer | Map internal workloads to DESP classes; broadcast signed consume positions; self-dispatch to `commit-%`; report telemetry | `members/use.md` |
| **Buffer** implementer | Signed charge/discharge offers; honor committed dispatch **before** any load curtailment | `members/buffer.md` |
| **Source** implementer | Supply offers over a forward vector; self-dispatch to committed take | `members/source.md` |
| **Allocator** implementer | No-discretion GCAP clear; federation announce-and-listen; withhold clearing on stale inputs | `members/allocator.md` |
| **Transmission owner** | MUST provision the Allocator’s local and regional constraint set | `architecture/allocation-domains.md` |
| **Regional system operator** | MAY add capacity constraints to a regional Allocator | same |
| **Host utility** | Commercial terms and agreed ramp / firm-limit parameters | outside the protocol |

There is no reference implementation or wire codec in this repository. G2P leaves encoding, state machines, version negotiation, and conformance vectors unspecified.

### Comment channels

Participation is open to individuals. Organizational affiliation confers no extra standing.

| Channel | Use |
|---|---|
| GitHub Discussions | Design alternatives and RFC #1 open-question areas: Commercial terms, Reliability assurance, Engineering |
| Issues | Defects, ambiguities, missing MUSTs, RFC #1 `errata` |
| Pull requests | Spec text against `specs/`, `members/`, or `architecture/` |
| G2TF WhatsApp Community | Cross-organization news (non-normative) |

Normative PRs require **two spec-editor** reviews, RFC 2119 keywords, and a compatibility statement. Merged decisions go in the `GOVERNANCE.md` decision log. Implementations from **Phase 0 shadow mode** onward report experience in Discussions.

### Roles

- **Editors** — maintain named documents, judge rough consensus, merge PRs.
- **Contributors** — anyone in Discussions, Issues, or PRs; standing by merit.
- **Task Force** — cross-document conflicts, editor appointment, milestones, new RFC publication.

G2TF coordinates with, and does not supersede, NERC, FERC, utility, and TSO/ISO requirements. A trademark policy for describing conformant implementations is forthcoming. Spec text is **CC BY 4.0**; any code is **Apache-2.0**. Marks "Grid 2.0"™, "G2TF"™, "G2P"™, "GCAP"™, and "DESP"™ grant no trademark rights under either license.

## Three-protocol stack

Grid 2 sits between Grid 1’s ~5-minute market dispatch domain and its sub-second / seconds-scale ancillaries (frequency response, AGC, reserves). Allocations apply to **whole one-minute intervals**. Clearing MUST finish so Members receive `commit-%` in time to self-dispatch **before the interval opens**. If a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **Grid 1 prevails**.

```text
Grid 1   Market Dispatch Domain (nodal pricing, forward dispatch)     ~5 minutes
──────────────────────────────────────────────────────────────────────────────
Grid 2   DESP  — service classification and prioritization              1 minute
         GCAP  — fair service allocation and scheduling
         G2P   — addressing, service configuration, and response
──────────────────────────────────────────────────────────────────────────────
Grid 1   Fast Operational Domain (frequency, AGC, reserves)             seconds
```

| Protocol | File | Role | v26.0-draft MUST-level surface |
|---|---|---|---|
| **DESP** | `specs/desp/spec.md` | Taxonomy and curtailment order used by GCAP and carried in G2P | Classes **A Assured**, **B Preferred**, **C Best Efforts** above Traditional Firm (Grid 1). Curtailment order **C → B → A**. Firm is never curtailed by GCAP. Dynamic reclassification each interval. |
| **GCAP** | `specs/gcap/spec.md` | Deterministic Allocator clear | Identical inputs → identical allocations. Order: **headroom → Buffers → tiered Use curtailment**. Outputs: Use `commit-%`, Buffer committed dispatch, Source committed take. Stale constraints → **no clear**. |
| **G2P** | `specs/g2p/spec.md` | Identity, messages, staleness | Stable element ID bound to a POI. Four families: Service Descriptor, Commitment, Federation Announcement, Response/Telemetry. Descriptors and Commitments MUST be authenticated. Wire format **unspecified**. |

G2P, GCAP, and DESP version independently on a **YY.N** scheme (26.0 = first 2026 line). README says a compatibility matrix will appear there when the lines diverge; it is not published yet.

### Interval message contract (G2P)

| Family | Direction | Payload |
|---|---|---|
| Service Descriptor | Member → Allocator | Signed positions in interval energy units, over a forward vector (length open) |
| Commitment | Allocator → Member | Interval, domain, clearing-inputs version; missing/stale → failsafe |
| Federation Announcement | Allocator ↔ Allocator | Announcing domain, interval, coupled-boundary quantities |
| Response / Telemetry | Member → Allocator | Actual per-class dispatch vs Commitment |

Peer announcements MAY add boundary headroom and **MUST NOT** relax local constraints. A missing peer announcement is treated as **zero extra headroom**. Partition between Allocators MUST NOT trip Members in unaffected domains.

## Adoption after RFC #1

RFC #1 §Phased Adoption is the deployment sequence. Living architecture files decompose that narrative; they do not change the RFC.

| Phase | Behavior |
|---|---|
| **0 Shadow mode** | Run the full stack as a dry run: exchange and track commitments; execute only the Grid 1 baseline |
| **1 Local vertical integration** | Large loads, transmission owners, and LSEs prove the solution inside existing rules |
| **2 Regional federation** | Peer Allocators on the same spec announce-and-listen across coupled zones |

The binding growth constraint is **pool ramp sizing**: simultaneous whole-pool fallback MUST stay inside manageable Grid 1 ramp limits.

:::files
g2tf-standards/
├── rfcs/grid-2-rfc-1.pdf          # Published RFC #1 (August 2026), immutable
├── architecture/                  # Draft system model (overview, time, domains, federation, failsafe)
├── specs/{desp,gcap,g2p}/spec.md  # 26.0-draft protocols — seeking input
├── members/{use,buffer,source,allocator}.md
├── GOVERNANCE.md                  # Roles, YY.N lifecycle, decision log
├── CONTRIBUTING.md                # Comment cycle, RFC 2119, one-sentence-per-line
├── LICENSE                        # CC BY 4.0 (spec text)
└── LICENSE-CODE                   # Apache-2.0 (code)
:::

Document lifecycle: **Draft (seeking input) → Proposed → Stable vXX.Y → RFC**. Stable changes require a compatibility statement.

<Warning>
Open items that still block a Stable 26.0 include G2P wire format and intra-interval deadlines, GCAP proportionality formula, DESP naming (A/B/C vs Firm/Semi-Firm/Flex), and certification criteria for “spec compliance.” Treat current MUSTs as draft.
</Warning>

## Next

<CardGroup>
  <Card title="How to read the specs" href="/how-to-read-the-specs">
    Status headers, RFC 2119, living files vs immutable RFCs, independent 26.x lines.
  </Card>
  <Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
    No perimeter, NERC/FERC/TSO non-interference, coordination without prices, v26.0 energy scope.
  </Card>
  <Card title="Minimum viable domain" href="/minimum-viable-domain">
    One host utility plus one flexible load; transmission-owner constraint provisioning.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Four message families, one-minute timing, authenticated descriptors, unspecified wire format.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Headroom then buffers then C-B-A curtailment; identical-input determinism.
  </Card>
  <Card title="DESP reference" href="/desp-reference">
    Class table, mandatory C-B-A order, open naming and SLA items.
  </Card>
  <Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
    Dry-run the stack; execute only the Grid 1 baseline.
  </Card>
  <Card title="Comment, review, and file errata" href="/comment-and-errata">
    Discussions vs Issues vs PRs; RFC #1 errata; two-editor review.
  </Card>
</CardGroup>

---

## 02. How to read the specs

> Status headers, RFC 2119 keywords, living files versus immutable RFCs, independent 26.x lines, and what Draft seeking input still leaves open.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/02-how-to-read-the-specs.md
- Generated: 2026-08-17T18:26:28.160Z

### Source Files

- `README.md`
- `CONTRIBUTING.md`
- `GOVERNANCE.md`
- `rfcs/README.md`
- `specs/g2p/spec.md`
- `architecture/overview.md`

---
title: "How to read the specs"
description: "Status headers, RFC 2119 keywords, living files versus immutable RFCs, independent 26.x lines, and what Draft seeking input still leaves open."
---

Every file under `specs/`, `members/`, and `architecture/` is a living document except `architecture/design-principles.md`, which is marked `Status: Informative`. The only published RFC is `rfcs/grid-2-rfc-1.pdf` (RFC #1, August 2026). That PDF is archival and is never edited. Normative evolution happens in the Markdown files. Protocol files currently carry `Version: 26.0-draft` and `Status: Draft — seeking input`. Member and architecture files carry the same status string (or `Informative`) and do not yet carry a `Version:` line.

## Document surfaces

```text
rfcs/grid-2-rfc-1.pdf          immutable narrative snapshot (Published)
architecture/*.md              system model (Draft, one Informative file)
specs/{g2p,gcap,desp}/spec.md  G2P / GCAP / DESP (26.0-draft)
members/{use,buffer,source,allocator}.md
                               per-element behavior (Draft — seeking input)
CONTRIBUTING.md                keyword and status-header rules
GOVERNANCE.md                  Draft → Proposed → Stable → RFC
```

| Path | What it is | Header status now | RFC 2119 boilerplate |
|---|---|---|---|
| `rfcs/grid-2-rfc-1.pdf` | Immutable RFC #1 | Published (table in `rfcs/README.md`) | N/A — do not edit |
| `specs/g2p/spec.md` | Transport and messages | `26.0-draft` · Draft — seeking input | Present |
| `specs/gcap/spec.md` | Clearing | `26.0-draft` · Draft — seeking input | Present |
| `specs/desp/spec.md` | Service classes | `26.0-draft` · Draft — seeking input | Present |
| `members/*.md` | Use, Buffer, Source, Allocator | Draft — seeking input | Present |
| `architecture/*.md` except design-principles | System model | Draft — seeking input | Present except `overview.md` |
| `architecture/design-principles.md` | Design rationale | `Status: Informative` | Absent (by rule) |

`README.md` summarizes `architecture/` as **Draft** and `specs/` plus `members/` as **Draft — seeking input**. File headers are the authority when those labels differ.

<Note>
`architecture/overview.md` is `Status: Draft — seeking input` but does not include the RFC 2119 / RFC 8174 sentence. Treat its prose as the system model, not as a keyword-normative member or protocol spec.
</Note>

## Status headers

Normative files open with a one-line header. Protocol specs add `Version:` and a stack role.

```markdown
**Version:** 26.0-draft · **Status:** Draft — seeking input · **Editors:** TBD
**Role in stack:** Addressing, service configuration, and response — …
```

```markdown
**Status:** Draft — seeking input · **Editors:** TBD · **Source:** [RFC #1](../rfcs/grid-2-rfc-1.pdf), §…
```

```markdown
**Status:** Informative · **Source:** [RFC #1](../rfcs/grid-2-rfc-1.pdf), §Key Design Principles; …
```

<ParamField body="Status" type="enum" required>
Allowed values on living files: `Draft — seeking input`, `Proposed`, `Stable (vXX.Y)`, or `Informative`. Current normative files all use `Draft — seeking input`.
</ParamField>

<ParamField body="Version" type="YY.N-draft" required>
Present only on `specs/g2p/spec.md`, `specs/gcap/spec.md`, and `specs/desp/spec.md`. Current value is `26.0-draft` on each line independently.
</ParamField>

<ParamField body="Editors" type="string" required>
Each normative document lists its editors here. All current headers say `TBD`.
</ParamField>

<ParamField body="Source" type="RFC #1 section" required>
Architecture and member files point at the RFC #1 section they decompose. Protocol files do not use this field; they declare `Role in stack` instead.
</ParamField>

<ParamField body="Role in stack" type="string">
Protocol-only. G2P is addressing, service configuration, and response. GCAP is fair allocation and scheduling. DESP is service classification and prioritization.
</ParamField>

### Lifecycle states

```mermaid
stateDiagram-v2
    [*] --> Draft: new living file
    Draft --> Proposed: rough consensus on scope and approach
    Proposed --> Stable: implementable YY.N
    Stable --> RFC: Task Force publishes snapshot to rfcs/
    RFC --> [*]: immutable; errata only
    note right of Draft
        Status: Draft — seeking input
        current state of specs/, members/,
        and most of architecture/
    end note
    note right of Stable
        Status: Stable (vXX.Y)
        changes require a compatibility statement
    end note
    note right of RFC
        rfcs/*.pdf never modified
        living files keep evolving
    end note
```

| Status | Meaning | What you may treat as frozen |
|---|---|---|
| `Draft — seeking input` | Scope and approach are open. Open items and `*(Open: …)*` markers are first-class. | Nothing. Normative `MUST`s still bind a reader of that file, but they can change without a compatibility statement. |
| `Proposed` | Rough consensus on scope and approach. Not yet an implementable `YY.N`. | Scope and approach, unless the responsible editor records otherwise. |
| `Stable (vXX.Y)` | Implementable. Further changes require a compatibility statement on the PR. | The `vXX.Y` contract until a new version is published. |
| `Informative` | Rationale only. Must not use RFC 2119 keywords. | No conformance claim. |
| RFC in `rfcs/` | Immutable snapshot. | The PDF text. Fixes land as `errata` Issues, then in living files. |

<Warning>
`GOVERNANCE.md` says the README carries a compatibility matrix. `README.md` only promises that matrix “as the specs diverge in maturity.” No matrix exists yet. Do not infer cross-protocol compatibility from the shared `26.0-draft` string.
</Warning>

## RFC 2119 keywords

Normative documents (`specs/`, `members/`, and any `architecture/` file **not** marked `Status: Informative`) interpret uppercase keywords per [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174):

| Keyword | Spec meaning in this repo |
|---|---|
| `MUST` / `MUST NOT` | Absolute requirement or prohibition for a conformant Member, Allocator, or protocol implementation. |
| `SHOULD` / `SHOULD NOT` | Recommended default. A deviation needs a recorded reason. |
| `MAY` | Optional. Absence of the behavior is still conformant. |

Protocol files restate this immediately under the header:

```text
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be
interpreted as described in RFC 2119 / RFC 8174.
```

<Info>
RFC 8174 restricts special meaning to **uppercase** keywords. Lowercase “must” in narrative is not a requirement. Informative documents, including `architecture/design-principles.md` and the DESP §3 workload-mapping section, must avoid the keywords entirely.
</Info>

A single file can mix layers. `specs/desp/spec.md` is normative overall; **§3 Mapping workloads to classes (informative)** is not a class-assignment requirement. Flex 0–3 and ERCOT CLR/PCLR mappings there do not bind the Allocator.

Pull requests against normative files must use these keywords and must state compatibility impact. Two spec editors review those PRs. Merged decisions go into the `GOVERNANCE.md` decision log.

## Living files versus immutable RFCs

RFC #1 is the August 2026 launch narrative. The repo then decomposes that narrative into commentable surfaces. The 2026-08 decision-log entry is explicit: keep the immutable story in `rfcs/`, put evolving requirements in living Markdown.

```text
                    never rewrite
  rfcs/grid-2-rfc-1.pdf ─────────────► archival citation
           │
           │  decompose / errata Issues labeled `errata`
           ▼
  architecture/  specs/  members/     living text, PRs allowed
           │
           │  Task Force snapshot when a line is Stable
           ▼
  rfcs/grid-2-rfc-N.pdf               next immutable RFC
```

<Steps>
  <Step title="Cite RFC #1 for intent">
    Use the PDF for the proposal, membership story, protocol-interaction table, figures, and phased-adoption framing. Do not patch the PDF.
  </Step>
  <Step title="Implement from living files">
    Implement G2P, GCAP, DESP, and member behavior from `specs/` and `members/`. Architecture files define domains, the one-minute clock, federation, and failsafe.
  </Step>
  <Step title="File RFC mistakes as errata">
    Defects in RFC #1 are GitHub Issues labeled `errata`. The fix is written into the living spec, not into the PDF.
  </Step>
  <Step title="Treat a new RFC as a snapshot, not a branch">
    Publication to `rfcs/` freezes that snapshot. The Markdown files keep their own `Status` and `Version` lines.
  </Step>
</Steps>

New or substantially revised normative text prefers **one sentence per line** so diffs stay reviewable.

## Independent 26.x version lines

Protocol versions use **YY.N** (year of the line, then increment). `26.0` is the first 2026 release. G2P, GCAP, and DESP version **independently**. Sharing `26.0-draft` today is coincidence of launch year, not a lockstep contract.

| Line | Current identifier | 26.0 scope already written into the file |
|---|---|---|
| G2P | `26.0-draft` | Positions are units of energy in the interval. Wire format, state machines, version negotiation, and conformance vectors are unspecified. |
| GCAP | `26.0-draft` | Headroom → Buffers → C-then-B-then-A curtailment. Exact proportionality formula is open. |
| DESP | `26.0-draft` | Classes A / B / C above Grid 1 Firm. Supply class structure may stay single-class in 26.0. |
| Architecture / members | no `Version:` field | Overview states 26.0 is energy in the one-minute window on the bulk power system only. |

Out of 26.0 unless a later `YY.N` says otherwise: voltage-support goal-seeks, distribution-scale devices (IEEE 2030.5), and routing through SSTs / HVDC.

When a line reaches `Stable (vXX.Y)`, a breaking change on that line needs a compatibility statement on the PR. Cross-protocol impact is supposed to land in the README matrix once the three lines diverge. Until that table exists, do not assume G2P `26.n` works with GCAP `26.m`.

## What Draft seeking input still leaves open

`Draft — seeking input` means implementers can code against written `MUST`s, but several surfaces are explicitly unfinished. Treat `*(Open: …)*`, `## Open items`, and `## To be specified` as non-requirements.

<AccordionGroup>
  <Accordion title="G2P — unspecified mechanism">
    Identifier format; forward-vector length, resolution, and revision; verification granularity, metering source of truth, and attestation; intra-interval timing budget and clock sync; PKI / key management, NERC CIP mapping, replay protection; wire format and encoding; per-element state machines; version negotiation; conformance test vectors.
  </Accordion>
  <Accordion title="GCAP — unspecified clearing details">
    Exact proportionality weights (connection size vs. request size); indivisible loads; multi-constraint (nodal) vs. single-zone headroom; whether deferred Class C accrues priority across intervals; mid-interval interaction with market dispatch instructions.
  </Accordion>
  <Accordion title="DESP — naming, extensibility, SLAs">
    Assured/Preferred/Best-Efforts vs. Firm/Semi-Firm/Flex names; whether class count is fixed at three; per-class unmet-frequency envelopes; per-class ramp and snap-back limits; enforcement of declared class behavior.
  </Accordion>
  <Accordion title="Members">
    Use: facility-type class mapping, minimum telemetry, unused-allocation return. Buffer: SoC visibility, multi-Buffer priority, investment framing. Source: forecast-error vs. headroom, same-interval redirect to co-located Buffers, single-class vs. mirrored A/B/C supply. Allocator: active/standby redundancy, input-digest publication, utility vs. third-party hosting.
  </Accordion>
  <Accordion title="Architecture">
    Allocation domains: conformance tests, machine-readable domain descriptors, overlapping-domain membership. Temporal position: federated clock epoch, late-arrival / skew, 15-minute settlement interaction. Failsafe: numeric staleness thresholds, re-entry hysteresis, coincidental-fallback stability, fallback audit. Federation: announcement payload, loop prevention, import policy, Phase 2 milestone criteria.
  </Accordion>
</AccordionGroup>

RFC #1 also parks three Discussion categories that living files point back to rather than close: **Commercial terms**, **Reliability assurance**, and **Engineering**. Those are not protocol knobs. Domain class-mix limits, for example, are commercial-terms matters in the domain agreement, not DESP wire fields.

<Check>
A written `MUST` in a Draft file is still a requirement of that file. An `Open` marker is not. If a behavior you need sits only in an Open item, it is not implementable from the spec yet — raise a Discussion or a PR.
</Check>

## How to apply a Draft requirement

<Steps>
  <Step title="Read the file header first">
    Confirm `Status`, `Version` if present, and whether the file is `Informative`. Skip keyword semantics on Informative files.
  </Step>
  <Step title="Separate MUST from Open">
    Implement uppercase `MUST` / `MUST NOT`. Leave `*(Open: …)*` and `## Open items` unimplemented unless your deployment documents a local choice.
  </Step>
  <Step title="Prefer living text over the PDF on conflict">
    RFC #1 is the source narrative. If living text has already decomposed or tightened a rule, the Markdown wins for implementers. File `errata` if the PDF is wrong.
  </Step>
  <Step title="Do not invent a wire or a compatibility matrix">
    G2P has no specified encoding. G2P, GCAP, and DESP are not version-locked. Interop claims need identical-input GCAP determinism plus whatever local encoding the domain agrees — not a repo-defined packet.
  </Step>
  <Step title="Report Phase 0 experience in Discussions">
    Shadow-mode implementations execute only the Grid 1 baseline. Running-code reports feed the next revision; they do not promote a file out of Draft by themselves.
  </Step>
</Steps>

## Related pages

<CardGroup>
  <Card title="Document lifecycle" href="/document-lifecycle">
    Draft → Proposed → Stable → RFC, YY.N versions, compatibility statements, and the GOVERNANCE.md decision log.
  </Card>
  <Card title="Comment, review, and file errata" href="/comment-and-errata">
    Discussions vs Issues vs PRs, the `errata` label, two-editor review, and RFC 2119 on normative changes.
  </Card>
  <Card title="Contributing" href="/contributing">
    Open participation, comment-cycle steps, one-sentence-per-line, and Phase 0 implementation reports.
  </Card>
  <Card title="Overview" href="/overview">
    Overlay plane, three-protocol stack, and first routes after RFC #1.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Current 26.0-draft message families and the still-unspecified wire format.
  </Card>
  <Card title="Governance and licenses" href="/governance">
    Editors, rough consensus, CC BY 4.0 spec text, Apache-2.0 code, trademarks.
  </Card>
</CardGroup>

---

## 03. Minimum viable domain

> Smallest Grid 2 domain: one host utility plus one flexible load, transmission-owner constraint provisioning, and the connect-and-manage on-ramp.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/03-minimum-viable-domain.md
- Generated: 2026-08-17T18:26:38.216Z

### Source Files

- `architecture/allocation-domains.md`
- `architecture/overview.md`
- `architecture/design-principles.md`
- `members/allocator.md`
- `members/use.md`
- `rfcs/grid-2-rfc-1.pdf`

---
title: "Minimum viable domain"
description: "Smallest Grid 2 domain: one host utility plus one flexible load, transmission-owner constraint provisioning, and the connect-and-manage on-ramp."
---

The smallest Grid 2 **Allocation Domain** is a host utility and a single flexible load customer: one **Use** Member at a point of interconnection, plus an **Allocator** that clears that Member against Grid 1 constraints the **utility transmission owner** MUST provision. The domain needs no Buffer, no Source, no peer Allocator, and no multi-stakeholder consensus. It is the connect-and-manage on-ramp: voluntary, spec-compliant, and legal inside existing Grid 1 rules. Living text is Draft — seeking input (`architecture/allocation-domains.md`, `members/allocator.md`, `members/use.md`); RFC #1 is the immutable August 2026 source.

<Info>
An Allocation Domain is the set of Member Elements cleared by a common Allocator (or Allocator hierarchy) against a common set of Grid 1 constraints. Domains nest later (local congestion zone → utility / balancing authority → regional RTO/ISO). The minimum viable domain is the leaf of that nest, not a different protocol.
</Info>

## What must exist

| Role | Minimum | Out of scope for this domain |
|---|---|---|
| Grid 1 custodian | Utility transmission owner provisions local and regional constraints | Regional system operator MAY add capacity constraints; not required |
| Overlay clearing | One Allocator for the domain; GCAP 26.0-draft; no discretion | Federation announcements, coupled-zone headroom |
| Member | One Use Member (flexible large load / capable datacenter / electrified industry) | Buffer, Source, additional Uses |
| Transport | G2P 26.0-draft: Service Descriptor, Commitment, Response / Telemetry | G2P Federation Announcement |
| Classes | DESP A / B / C above traditional Firm (Grid 1) | Domain class-mix limits (commercial terms, not protocol) |
| Clock | One-minute interval; energy-in-the-interval (v26.0) | Voltage support, IEEE 2030.5 distribution devices |
| Commercial | Terms with the host utility (flex enforcement, class limits, charging) | Protocol-enforced prices or settlements |

```mermaid
flowchart TB
  subgraph g1["Grid 1 custodians"]
    TO["Utility transmission owner\nMUST provision local + regional constraints"]
    RSO["Regional system operator\nMAY add capacity constraints"]
  end

  subgraph plane["Grid 2 overlay — minimum domain"]
    ALLOC["Allocator\nGCAP: headroom → buffers → C-B-A\nMUST NOT clear on stale inputs"]
    USE["Use Member\nG2P Service Descriptor + verified self-dispatch"]
  end

  subgraph phys["Physical interconnection"]
    LOAD["Flexible load at a provisioned POI\nself-dispatch within commit-%"]
    FIRM["Grid 1 firm load limit\nfallback on missed / stale Commitment"]
  end

  TO -->|"constraint inputs"| ALLOC
  RSO -.->|"optional"| ALLOC
  USE -->|"per-class request to consume"| ALLOC
  ALLOC -->|"per-class commit-%"| USE
  USE --> LOAD
  USE -->|"loss of peers / stale commit"| FIRM
```

RFC #1 Figure 5 is a richer utility-level picture (multiple Uses plus a Buffer). The minimum viable domain is smaller: drop every Member except one Use. Figure 6 (federation) is Phase 2, not the on-ramp.

## Connect-and-manage on-ramp

Grid 2 membership is voluntary and can exist distinct from other grid and market requirements, the same way emerging connect-and-manage schemes already do. The design assumes parties are willing to agree on those principles; it does not require universal application.

| On-ramp property | Spec rule |
|---|---|
| Capital | No capital deployment required to stand up the overlay |
| Consensus | No multi-stakeholder consensus process; two parties suffice |
| Rules fit | Transmission-owner connect-and-manage standard inside existing Grid 1 rules |
| Admission | No Grid 2 admission process; membership is spec compliance at a qualifying POI in a provisioned domain |
| Authority | No Grid 2 element derives authority from the protocol; the protocol carries Grid 1 custodian constraints |
| Scale | Serves and sits inside Grid 1 at any scale; start local, federate later |

Technical membership: a conformant protocol implementation at a POI covered by a provisioned domain, under commercial terms with the host utility. Commercial participation terms — enforcement of flex capabilities, class limits, charging for Grid 2-enabled use — stay in the domain agreement. They are not G2P, GCAP, or DESP fields.

<Warning>
Hosting and operational responsibility for the Allocator (utility-operated versus third-party under utility authority) is an open item. Authority still stays with the transmission owner: whoever hosts the process MUST clear only against that owner's provisioned constraints.
</Warning>

## Constraint provisioning

The transmission owner MUST provision the Allocator with the local and regional constraints that bound clearing. A regional system operator MAY additionally provision capacity constraints. Peer announcements MUST NOT appear in a minimum domain; if they later do, they MAY add boundary headroom but MUST NOT relax local limits.

Each interval the Allocator clears against:

<ParamField body="grid_1_constraints" type="custodian-provisioned set" required>
Zone power production capacity, transmission constraints, and target reserves. Optionally power distribution factors and Dynamic Line Rating dynamics.
</ParamField>

<ParamField body="member_service_descriptors" type="G2P §3.1" required>
In-zone signed positions. For the minimum domain this is one Use Member: per-class request to consume (+) over a forward time vector, in units of energy within the interval.
</ParamField>

<ParamField body="peer_allocator_announcements" type="G2P §3.3">
Not required. Omit until Phase 2. An Allocator that later expects a coupled-boundary announcement and does not receive it MUST clear as if that boundary adds no headroom.
</ParamField>

<ParamField body="input_digest" type="Commitment field" required>
Commitments MUST identify the interval, the domain, and the clearing-inputs version they were computed against. Allocators SHOULD publish the input digest inside the domain so any party with the same inputs can reproduce GCAP.
</ParamField>

Which existing transmission-owner signals to use, and how to standardize them, is a headline Engineering open question (RFC #1). The Allocator holds no internal intelligence: identical inputs MUST produce identical allocations.

## Interval loop

Only the Member ↔ Allocator pattern runs. Allocator ↔ Allocator federation is not part of the minimum domain.

```mermaid
sequenceDiagram
  participant TO as Transmission owner
  participant A as Allocator
  participant U as Use Member
  participant G1 as Grid 1 POI

  TO->>A: Provision / refresh Grid 1 constraints
  Note over U,A: One-minute interval; commit before interval opens
  U->>A: Signed Service Descriptor (per-class consume +)
  A->>A: GCAP: headroom, then buffers, then C→B→A
  alt Fresh constraints
    A->>U: Commitment (per-class commit-%, interval, domain, input version)
    U->>G1: Self-dispatch within commit-% and agreed ramp rates
    U->>A: Response / Telemetry (verified self-dispatch)
  else Stale inputs, partition, or missed Commitment
    A--xU: MUST NOT clear
    U->>G1: Revert to firm load limit or manual curtailment
  end
```

Normative Use obligations in this domain:

- MUST self-dispatch within its per-class commit-% for the interval, within parameters agreed with the host utility.
- MUST report verified self-dispatch (G2P §3.4).
- MUST respect agreed ramp rates on all transitions (into allocation, between intervals, into fallback).
- MUST treat a missing or stale Commitment as fallback.

The Allocator never sees internal workloads. The Use Member maps inference, training, batch, and on-site resources onto DESP classes at the edge. Firm (Grid 1) service is outside GCAP and is never curtailed by Grid 2.

<Note>
Grid 2 clearing MUST finish so the Member receives commit-% with time to self-dispatch before the interval opens. Exact descriptor / clearing / publication deadlines are still open. Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, Grid 1 prevails.
</Note>

## Failsafe at one-Member scale

Failure of the overlay MUST NOT leave the physical interconnection worse than the pre-Grid 2 status quo.

| Condition | Required behavior |
|---|---|
| Stale constraint inputs or domain partition | Allocator MUST NOT clear |
| Missed or stale Commitment | Use MUST revert to Grid 1 baseline (firm load limit) or manual curtailment |
| Ramp | Transitions MUST stay inside host-utility ramp rates |
| Pool size | Participating pool MUST be sized so simultaneous fallback stays inside Grid 1 system ramp limits — binding even when the pool is one load |
| Determinism | Fallback MUST be locally determinable from the Member's own state and last-known configuration; it MUST NOT depend on reaching the Allocator |

Transmission-level deployments are expected on private networks. Service Descriptors and Commitments MUST be authenticated. NERC CIP mapping and key management remain open.

## Stand up the domain

<Steps>
  <Step title="Anchor authority and commercial terms">
    The host utility transmission owner agrees connect-and-manage principles with the single flexible load. Put flex enforcement, any class-mix limits (for example a minimum Class C share for expedited interconnection), charging, and ramp rates in the domain agreement — not in protocol messages.
  </Step>
  <Step title="Provision the Allocator">
    Feed the Allocator the required Grid 1 set: zone production capacity, transmission constraints, target reserves. Optionally add DLR and distribution factors. Decide who hosts the process; keep constraint authority with the transmission owner. Do not wait for a regional Allocator or peer announcements.
  </Step>
  <Step title="Bind the Use Member">
    Give the Member a stable element identifier at the physical POI inside the provisioned domain. Implement G2P Service Descriptor, Commitment listen, and Response / Telemetry. Map facility workloads onto DESP A / B / C locally. Keep traditional Firm load on the Grid 1 path.
  </Step>
  <Step title="Run Phase 0 shadow mode">
    Exchange and track the full stack each minute. Execute only the Grid 1 baseline (what would have happened anyway). Confirm: Commitments carry interval, domain, and input version; identical inputs reproduce GCAP; a withheld clearing drives the Use Member to its firm-limit fallback without a remote call.
  </Step>
  <Step title="Graduate only after the dry run">
    Phase 1 Local Vertical Integration: execute commit-% at the POI inside existing rules (RFC #1 cites ERCOT PCLR and PJM IRAS/PRD as the operational layer this stack is meant to automate). Phase 2 Regional Federation is later: announce-and-listen with peer Allocators. Partition between peers MUST NOT trip this Member if local constraints remain fresh.
  </Step>
</Steps>

<Check>
Phase 0 verification: the Use Member can reproduce the Allocator's commit-% from the published input digest; injecting stale constraints causes no-clear plus firm-limit fallback; no physical flex is taken until Phase 1.
</Check>

## What this domain does not do

- It does not replace NERC, FERC, utility, or TSO/ISO obligations. All assets continue to meet their Grid 1 requirements.
- It does not settle energy or publish prices. Coordination is protocol-based; commercial settlements stay on Grid 1's slower clock.
- It does not require Buffer or Source Members. GCAP still orders Buffers before load curtailment when they exist; with none present, clearing is headroom then C → B → A.
- It does not need to be universally applied in the utility territory.
- It does not certify conformance. Certification / test criteria for "spec compliance" are open, as is whether domains publish a machine-readable descriptor (constraint scope, class policy, ramp limits).

## Open items that bind a first domain

| Item | Where it lives |
|---|---|
| Certification / conformance tests for spec compliance | `architecture/allocation-domains.md` |
| Machine-readable domain descriptor | same |
| Member present in overlapping local + regional domains | same |
| Standardize transmission-owner constraint signals | RFC #1 Engineering; `members/allocator.md` |
| Allocator hosting (utility vs third-party under utility authority) | `members/allocator.md` |
| Input-digest publication and intra-interval timing budget | GCAP §5, G2P §4 |
| Minimum telemetry for commit-% compliance | `members/use.md` |
| Pool-sizing methodology for whole-pool fallback | `architecture/failsafe-model.md` |
| Commercial terms: flex enforcement, class limits, charging | RFC #1; DESP §4 |

Report Phase 0 implementation experience in GitHub Discussions. Proposed normative text goes to PRs on `architecture/`, `members/`, or `specs/`. RFC #1 corrections are Issues labeled `errata`.

## Next

<CardGroup>
  <Card title="Allocation domains" href="/allocation-domains">
    Nesting, transmission-owner authority, voluntary membership, commercial terms outside the protocol.
  </Card>
  <Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
    Dry-run the stack, execute only the Grid 1 baseline, then Phase 1 and Phase 2.
  </Card>
  <Card title="Provision constraint inputs" href="/provision-constraint-inputs">
    Required Grid 1 set, optional DLR and distribution factors, digests, no peer relaxation of local limits.
  </Card>
  <Card title="Use Member" href="/use-member">
    Per-class consume positions, commit-% listen, edge mapping, self-dispatch MUSTS, firm-limit fallback.
  </Card>
  <Card title="Allocator" href="/allocator">
    No-discretion GCAP clearing, custodian inputs, withhold-on-stale, whole-pool ramp sizing.
  </Card>
  <Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
    Membership without a perimeter, NERC/FERC/TSO non-interference, coordination without prices.
  </Card>
</CardGroup>

---

## 04. Overlay and Grid 1

> Overlay membership without a perimeter, NERC/FERC/TSO non-interference, coordination without prices, and v26.0 energy-in-the-interval scope.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/04-overlay-and-grid-1.md
- Generated: 2026-08-17T18:27:16.738Z

### Source Files

- `architecture/overview.md`
- `architecture/design-principles.md`
- `architecture/temporal-position.md`
- `architecture/failsafe-model.md`
- `README.md`

---
title: "Overlay and Grid 1"
description: "Overlay membership without a perimeter, NERC/FERC/TSO non-interference, coordination without prices, and v26.0 energy-in-the-interval scope."
---

Grid 2 is a voluntary **orchestration plane** on the existing physical grid (**Grid 1**). The plane is an **overlay network**: coordinated by protocol, embedded throughout Grid 1, verified by aggregate footprint, with **no perimeter** and **no central operator**. Living architecture is `architecture/overview.md` (Draft — seeking input). The design table is `architecture/design-principles.md` (Informative). The immutable narrative is [RFC #1](https://github.com/g2tf-org/g2tf-standards/blob/main/rfcs/grid-2-rfc-1.pdf) (August 2026). G2P, GCAP, and DESP each version independently on the **26.x** line; current drafts are **26.0-draft**.

<Info>
Grid 2 does not replace, modify, or bypass any Grid 1 mechanism. Participating assets continue to meet all **NERC**, **FERC**, utility, and **TSO/ISO** requirements in their existing Grid 1 context. The G2TF coordinates with those bodies; it does not supersede them (`GOVERNANCE.md`).
</Info>

## Overlay model

The overlay is digital, not a second physical grid. Members sit at ordinary Grid 1 points of interconnection. They are **not** topologically separate.

Two element kinds implement the plane:

| Element | Role | Grid 1 binding |
|---|---|---|
| **Member Elements** | Digital representatives of Use (flexible load), Buffer (storage), and Source (clean-energy supply) | Bound to a physical POI; self-dispatch inside host-utility parameters |
| **Allocators** | Deterministic clearing agents for a constraint domain | Informed only by Grid 1 capabilities and constraints from the transmission owner and, optionally, the regional system operator |

Each one-minute interval:

1. Members broadcast Service Descriptors (per-class consume positions, Buffer charge/discharge offers, Source supply offers) via **G2P**.
2. Allocators clear those descriptors against provisioned Grid 1 constraints via **GCAP**, using **DESP** class order.
3. Members **self-dispatch** the resulting commit-% / committed dispatch / committed take.
4. Members report **verified self-dispatch** so the overlay’s aggregate footprint is measurable.

Equitable dispatch is proportional to connection size and differential request size. The Allocator holds **no internal intelligence or discretion**.

```mermaid
flowchart TB
  subgraph market["Grid 1 — Market Dispatch Domain ~5 min"]
    MKT["Nodal pricing and forward dispatch"]
  end
  subgraph overlay["Grid 2 — Overlay orchestration plane 1 min"]
    DESP["DESP — classification and priority"]
    GCAP["GCAP — deterministic allocation"]
    G2P["G2P — identity, messages, staleness"]
  end
  subgraph fast["Grid 1 — Fast Operational Domain seconds"]
    FAST["Governor response, AGC, reserves, protection"]
  end
  market -->|"Grid 1 instruction prevails on conflict"| overlay
  overlay -->|"MUST NOT interfere, substitute, or assume"| fast
```

Grid 2 commits only **above** the timescales where Grid 1 primary controls operate and **below** the market-clearing domain. Sub-minute response is out of scope for the orchestration plane.

## Membership without a perimeter

Grid 2 has **no admission process**. Anyone running a conformant implementation at a qualifying point of interconnection, inside a domain whose transmission-owner constraints are provisioned to an Allocator, **is** a member.

| Rule | Specification |
|---|---|
| Technical membership | **Spec compliance**, not registration |
| Growth | Vendors build to the published spec; the overlay grows by deployment, not central permission |
| Domain membership | **Voluntary**; can exist distinct from other grid and market requirements |
| Commercial terms | Enforcement of flex capabilities, class limits, and charging for Grid 2-enabled use stay in the domain agreement — **outside the protocol** |
| Authority | No Grid 2 element derives authority from the protocol. The protocol carries constraints whose authority comes from **Grid 1 custodians** |

The smallest Allocation Domain is one **host utility** plus one **flexible load**. That on-ramp is the transmission-owner **connect-and-manage** path: no capital deployment and no multi-stakeholder consensus. Grid 2 does not need to be universally applied. It sits inside the Grid 1 context at any scale.

<Note>
Certification and conformance-test criteria for “spec compliance” are still open (`architecture/allocation-domains.md`). Commercial participation is not the same as technical membership.
</Note>

## Non-interference with NERC, FERC, TSO/ISO, and Grid 1 controls

### Regulatory posture

| Body | Overlay relationship |
|---|---|
| **NERC** | Assets remain under existing reliability obligations. **CPS1/BAL** stay the balancing measures. Ancillary-service *sizing* can be tuned over time to observed need; the overlay does not rewrite the measures. **NERC CIP** applicability, key management, and replay protection are open Engineering discussion items and will be specified in G2P. |
| **FERC** | Adoption is voluntary inside existing rules. Broader FERC-level recognition is a later, post-proof step (RFC #1 §Phased Adoption). |
| **Utility / TSO / ISO** | Host-utility interconnection and ramp parameters remain binding. The transmission owner **MUST** provision Allocator constraints. A regional system operator **MAY** add capacity constraints to a regional Allocator. |

G2TF alignment work with **IEEE 2030.5** and related standards is tracked in Discussions. A companion regulatory/engineering document is in development; it is not a living spec in this repository.

### Operational MUST NOTs

From `architecture/temporal-position.md` and the failsafe model:

- Grid 2 elements **MUST NOT** interfere with, substitute for, or assume the function of sub-second primary controls (governor response, AGC, protection).
- Grid 2 **SHOULD** consume, not contradict, forward information from the market dispatch domain.
- Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, the **Grid 1 instruction prevails**.
- On stale constraint inputs or partition, the Allocator **MUST NOT** clear. Members fall back to Grid 1 baseline.
- Peer Allocator announcements **MAY** add boundary headroom but **MUST NOT** relax local Grid 1 constraints.

Traditional **Firm (Grid 1)** service sits **outside** DESP. GCAP never curtails it. Classes **A / B / C** (Assured / Preferred / Best Efforts) stratify non-firm demand **above** that firm layer.

## Coordination without prices

Real-time coordination is protocol-only. Commercial settlements stay on Grid 1’s slower clock.

| Surface | What it does | What it does not do |
|---|---|---|
| **G2P** | Carries signed energy positions, commitments, federation announcements, telemetry | Does not price or settle |
| **GCAP** | Deterministic headroom → buffers → C-then-B-then-A curtailment | Holds no discretion and no bid stack |
| **DESP** | Class taxonomy and mandatory curtailment order | Does not define tariffs or SLAs (per-class performance envelopes are open) |
| **Domain agreement** | Charging for Grid 2-enabled use, class-mix limits, flex enforcement | Not encoded as protocol messages |

This is the Informative principle **Coordination without prices**: technical protocols handle the one-minute plane; current commercial settlements remain decoupled.

## v26.0 energy-in-the-interval scope

Version **26.0** is focused on **units of energy consumed and provided within the one-minute window** on the **bulk power system**. G2P requires every Service Descriptor position to be expressed in those units.

| In 26.0 | Not in 26.0 |
|---|---|
| Energy in the interval (consume / charge / discharge / supply) | Other goal-seeks (e.g. **voltage support**) |
| Bulk-power Use, Buffer, Source, Allocator | Distribution-scale devices (future work building on **IEEE 2030.5**) |
| Whole one-minute allocations | Sub-minute orchestration |
| DESP A/B/C above Grid 1 Firm | Routing through advanced power electronics (**SSTs**, **HVDC**) |
| Source offers as a single supply class (mirroring A/B/C is an open item) | Protocol-native prices or market settlement |

<Warning>
Wire format, encoding, state machines, version negotiation, and conformance test vectors are **unspecified** in G2P §7. Do not treat 26.0-draft as an implementable on-the-wire contract.
</Warning>

## Verification without inspecting internals

Reliability is not a promise from a central operator. It is three properties together (`architecture/overview.md`):

1. **Local good-citizenship** — each asset, at its POI, follows the protocol and responds to locally observable conditions.
2. **Protocol-ensured consistency** — every member runs the same algorithm against the same observable signals.
3. **Aggregate observability** — Grid 1 measures system-wide effects and verifies the overlay is collectively net-positive.

Grid 1 custodians verify by **footprint**, not internals: frequency stability, ACE excursions, transmission flows, peak shaving. The Allocator never sees or directs workloads inside a facility; it clears class-level positions only.

G2P **MUST** authenticate Service Descriptors and Commitments. Transmission-level deployments are expected on **private networks**. Failure of the orchestration plane **MUST** leave the physical grid no worse than the pre-Grid 2 status quo: Use reverts to firm load limit or manual curtailment; Buffer reverts to its standalone Grid 1 schedule with **no** Grid 2 support commitment; Source reverts to Grid 1 interconnection behavior. All transitions follow agreed ramp rates.

## Open items that affect the overlay–Grid 1 boundary

These remain Draft — seeking input. They change interoperability, not the overlay definition:

- Intra-interval timing budget and clock-sync (G2P / temporal position)
- NERC CIP mapping, PKI, replay protection (G2P §6)
- Standardization of transmission-owner constraint signals (Allocator / Engineering discussion)
- Interaction with 15-minute settlement intervals and mid-interval market dispatch (GCAP / temporal position)
- Conformance tests for “spec compliance”
- Source class structure beyond single-class 26.0 supply

## Next

<CardGroup>
  <Card title="One-minute window" href="/one-minute-window">
    Interval clock, commit-before-open, and the Grid 1-prevails conflict rule.
  </Card>
  <Card title="Allocation domains" href="/allocation-domains">
    Nested constraint domains, transmission-owner authority, and commercial terms outside the protocol.
  </Card>
  <Card title="Failsafe model" href="/failsafe-model">
    Per-element Grid 1 baselines, interval-only commitments, and locally determinable fallback.
  </Card>
  <Card title="Provision constraint inputs" href="/provision-constraint-inputs">
    Required Grid 1 constraint set and the rule that peer announcements must not relax local limits.
  </Card>
  <Card title="Service classes" href="/service-classes">
    DESP A/B/C above Grid 1 Firm and mandatory C-then-B-then-A curtailment.
  </Card>
  <Card title="Governance and licenses" href="/governance">
    G2TF roles and the explicit non-supersession of NERC, FERC, utility, and TSO/ISO requirements.
  </Card>
</CardGroup>

---

## 05. One-minute window

> One-minute interval clock between ~5-minute market dispatch and sub-second ancillaries, commit-before-open, and the Grid 1-prevails conflict rule.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/05-one-minute-window.md
- Generated: 2026-08-17T18:28:32.503Z

### Source Files

- `architecture/temporal-position.md`
- `architecture/overview.md`
- `specs/g2p/spec.md`
- `specs/gcap/spec.md`
- `README.md`

---
title: "One-minute window"
description: "One-minute interval clock between ~5-minute market dispatch and sub-second ancillaries, commit-before-open, and the Grid 1-prevails conflict rule."
---

Grid 2 allocations **MUST** apply to whole one-minute intervals. G2P binds all four message families to that clock; GCAP clears once per interval and expires the resulting commitments with it; DESP lets a Member reclassify request buckets on the same cadence. Version **26.0-draft** measures only units of energy consumed and provided inside that window on the bulk power system. Sub-minute response is out of scope for the orchestration plane.

<Callout type="info">
Living specs (`architecture/temporal-position.md`, G2P §4, GCAP §4) are **Draft — seeking input**. RFC 2119 keywords below are as written in those files. Intra-interval deadlines and clock-sync requirements are still open.
</Callout>

## Position on the Grid 1 clocks

Grid 2 sits **below** the market dispatch domain and **above** Grid 1 primary controls. RFC #1 and `architecture/temporal-position.md` place the stack as:

| Clock | Plane | What runs |
|---|---|---|
| ~5 minutes | Grid 1 — Market Dispatch Domain | Nodal pricing, forward dispatch scheduling |
| **1 minute** | **Grid 2 overlay** | DESP (classification), GCAP (clearing), G2P (identity, messages, staleness) |
| Seconds / sub-second | Grid 1 — Fast Operational Domain | Frequency response, AGC, reserves, protection |

Normative non-interference:

- Grid 2 elements **MUST NOT** interfere with, substitute for, or assume governor response, AGC, or protection.
- Grid 1 ancillary services absorb overlay error without modification. NERC **CPS1/BAL** remain the balancing-performance measures; ancillary sizing can be tuned later against observed need.
- Commercial settlements stay on Grid 1's slower clock. Grid 2 coordinates operation, not prices.

Voluntary adoption does not require a market-rule change: the overlay occupies the minutes band already used for ERCOT PCLR and PJM IRAS/PRD flex compliance.

## Commit-before-open

GCAP outputs apply to the **coming** interval only. Clearing **MUST** finish early enough that Members receive `commit-%` (and Buffer/Source equivalents) with time to self-dispatch **before the interval opens**.

<Steps>
<Step title="Describe the next window">
Members publish a signed G2P **Service Descriptor** for a forward time vector: Use per-class request to consume (`+`); Buffer offer to charge (`+`) or discharge (`−`); Source offer to supply (`−`). Positions are energy **within the interval**. A descriptor **MAY** be reissued each interval; DESP classes **MAY** change each interval.
</Step>
<Step title="Clear once">
The domain Allocator runs GCAP against (1) Grid 1 constraints provisioned by the transmission owner / RSO, (2) in-zone descriptors, (3) peer-Allocator announcements. Peer announcements **MAY** add boundary headroom and **MUST NOT** relax local constraints. Order is fixed: headroom, then Buffer committed dispatch, then C→B→A curtailment. Traditional Firm (Grid 1) is never curtailed by GCAP.
</Step>
<Step title="Publish commitments">
The Allocator emits a G2P **Commitment** that **MUST** identify the interval, the domain, and the clearing-inputs version. Payloads: per-class `commit-%` (Use), **committed dispatch** (Buffer), **committed take** (Source).
</Step>
<Step title="Self-dispatch, then report">
Members **MUST** self-dispatch within the committed amounts and agreed host-utility ramp rates, then **MUST** report verified self-dispatch (G2P §3.4). Per-member allocation deltas between consecutive intervals **MUST** respect those ramp rates.
</Step>
</Steps>

The exact intra-interval budget — descriptor deadline, clearing deadline, commitment publication deadline, clock sync — is **not** specified. Track it as Discussion: Engineering.

## Grid 1-prevails conflict rule

<Callout type="warning">
Grid 2 **SHOULD** consume, not contradict, forward information from the market dispatch domain. Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **the Grid 1 instruction prevails**.
</Callout>

GCAP still lists **interaction with market dispatch instructions mid-interval** as unspecified. Until that interaction is written, implementers treat Grid 1 instructions as binding even after a Grid 2 Commitment has been published for the same minute.

## Interval-bound messages

G2P §3: all four families are per-interval (one minute) unless a later note says otherwise.

| Family | Direction | Interval binding |
|---|---|---|
| Service Descriptor | Member → Allocator | Requests/offers for a forward vector; energy units = this interval (v26.0) |
| Commitment | Allocator → Member | Names the interval, domain, and inputs version; missing or stale → fallback |
| Federation Announcement | Allocator ↔ Allocator | Names announcing domain, interval, and coupled-boundary quantities |
| Response / Telemetry | Member → Allocator | Actual per-class dispatch vs. that interval's Commitment |

Wire format, state machines, version negotiation, and conformance vectors are unspecified.

## Expiry, staleness, and ramps

<ParamField path="allocation lifetime" type="one interval">
GCAP: allocations apply to the coming interval only and expire with it. Failsafe: a Member that has not received a `commit-%` for the **current** interval **MUST** treat itself as in fallback.
</ParamField>

<ParamField path="stale or invalid inputs" type="no clear">
On stale constraint inputs or partition, the Allocator **MUST NOT** clear. Members detecting a missed clearing fall back locally. Explicit staleness timers are still TBD in G2P.
</ParamField>

<ParamField path="fallback locality" type="local state only">
Fallback **MUST** be determinable from the Member's own state and last-known configuration. It **MUST NOT** depend on reaching a remote peer.
</ParamField>

<ParamField path="ramp discipline" type="agreed host-utility rates">
All transitions — into fallback, out of fallback, and between interval allocations — **MUST** respect agreed ramp rates. The participating pool **MUST** be sized so simultaneous whole-pool fallback stays inside manageable Grid 1 ramp limits.
</ParamField>

Per-element fallback (Use → firm load limit or manual curtailment; Buffer → standalone Grid 1 schedule with no Grid 2 support commitment; Source → Grid 1 interconnection behavior) is defined on the failsafe page, not here.

Federation does not change the clock: a missing peer announcement causes **conservative** local clearing (treat the boundary as adding no headroom). Partition between Allocators **MUST NOT** prevent local clearing and **MUST NOT** trip Members in unaffected domains.

## Open timing items

<AccordionGroup>
<Accordion title="Intra-interval budget and clocks">
Descriptor / clearing / commitment deadlines and clock-sync requirements (G2P §4). Late-arrival and clock-skew tolerances for Member broadcasts. Interval phase alignment across federated domains (common epoch vs. per-domain clocks).
</Accordion>
<Accordion title="Adjacent Grid 1 clocks">
Interaction with 15-minute settlement intervals in some markets. Mid-interval market dispatch vs. an already-published Commitment (GCAP §7).
</Accordion>
<Accordion title="Staleness and mid-interval unused energy">
Quantitative missed-interval count before fallback; re-entry hysteresis. Whether unused Use allocation returns to the pool mid-interval. Verification granularity and metering source of truth for G2P §3.4.
</Accordion>
</AccordionGroup>

## Related pages

<CardGroup cols={2}>
  <Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
    Non-interference, coordination without prices, v26.0 energy-in-the-interval scope.
  </Card>
  <Card title="Failsafe model" href="/failsafe-model">
    Interval-only commitments, local fallback, pool ramp limits.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Four message families, one-minute timing, stale-commitment faults.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Per-interval clearing, commit outputs, consecutive-interval ramp bounds.
  </Card>
  <Card title="Federation" href="/federation">
    Interval-tagged announce-and-listen; missing announcement does not trip local Members.
  </Card>
  <Card title="Use Member" href="/use-member">
    Listen for coming-interval commit-%; self-dispatch and telemetry MUSTS.
  </Card>
</CardGroup>

---

## 06. Allocation domains

> Nested constraint domains, transmission-owner authority, voluntary membership by spec compliance, and commercial terms that stay outside the protocol.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/06-allocation-domains.md
- Generated: 2026-08-17T18:26:21.514Z

### Source Files

- `architecture/allocation-domains.md`
- `architecture/federation.md`
- `architecture/overview.md`
- `members/allocator.md`
- `rfcs/grid-2-rfc-1.pdf`

---
title: "Allocation domains"
description: "Nested constraint domains, transmission-owner authority, voluntary membership by spec compliance, and commercial terms that stay outside the protocol."
---

A **Grid 2 Allocation Domain** is the set of Member Elements cleared by a common Allocator (or Allocator hierarchy) against a common set of Grid 1 constraints. The living definition is `architecture/allocation-domains.md` (`Status: Draft — seeking input`), sourced from RFC #1 §Grid 2.0 Membership and Basis of Authority. RFC 2119 / RFC 8174 keywords in that file and in `specs/` / `members/` are normative.

<Note>
No Grid 2 element derives authority from the protocol. G2P, GCAP, and DESP carry and enforce constraints whose authority comes from Grid 1 custodians.
</Note>

## Definition

| Field | Value |
|---|---|
| Cleared set | Member Elements (Use, Buffer, Source) plus the domain Allocator(s) |
| Common bound | One provisioned Grid 1 constraint set |
| Nesting | Local transmission congestion zone → utility / balancing authority → regional RTO/ISO |
| Smallest domain | One host utility and one flexible load customer |
| On-ramp | Transmission-owner "connect and manage"; no capital deployment and no multi-stakeholder consensus required |
| Status | Draft — seeking input (living file). RFC #1 is immutable; errata go to Issues labeled `errata` |

Every Member Element and Allocator MUST hold a stable element identifier bound to a physical point of interconnection inside a **provisioned** Allocation Domain (`specs/g2p/spec.md` §2). Identifier format is open; the recommended direction is a domain-scoped hierarchical ID that mirrors constraint-domain nesting.

## Nested constraint domains

Allocator associated scope is any level of the hierarchy: transmission line → utility load zone → RTO region (`members/allocator.md`). Domains do not command one another. Federation is announce-and-listen; each Allocator clears only against constraints provisioned by its own Grid 1 custodians.

```mermaid
flowchart TB
  subgraph Regional["Regional Constraint Domain"]
    RA["Allocator(s)"]
    SM["Source Member"]
    RBM["Buffer Member"]
    subgraph UtilA["Utility A Constraint Domain"]
      UA["Allocator(s)"]
      subgraph LocalA["Local Constraint Domain"]
        LA["Allocator(s)"]
        U1["Use Member A1"]
        U2["Use Member A2"]
        B1["Buffer Member A1"]
      end
    end
    subgraph UtilB["Utility B Constraint Domain"]
      UB["Allocator(s)"]
      subgraph LocalB["Local Constraint Domain"]
        LB["Allocator(s)"]
        U3["Use Member B1"]
        B2["Buffer Member B1"]
      end
    end
  end
  TO["Utility transmission owner"] -->|"MUST provision local and regional constraints"| UA
  TO -->|"MUST provision local and regional constraints"| UB
  RSO["Regional system operator"] -.->|"MAY add capacity constraints"| RA
```

This is the RFC #1 Figure 6 / `architecture/federation.md` tree. Regional Source and Buffer Members can sit on the regional domain; local Use and Buffer Members sit on the innermost domain that covers their point of interconnection.

### Two interaction patterns

| Pattern | Direction | What happens |
|---|---|---|
| Member ↔ Allocator | In-domain | Members advertise Service Descriptors; the Allocator clears; Members perform verified self-dispatch |
| Allocator ↔ Allocator | Coupled zones | Peer Allocators exchange G2P Federation Announcements; each still clears from its own Grid 1 inputs |

<Warning>
Treatment of a Member present in overlapping domains (local + regional) is an open item in `architecture/allocation-domains.md`. Do not assume a specified multi-domain commit rule.
</Warning>

## Basis of authority

Authority is **anchored in the utility transmission owner**.

| Actor | Normative role |
|---|---|
| Utility transmission owner | MUST provision the Allocator with the local and regional constraints that bound clearing for Member Elements in its domain |
| Regional system operator | MAY additionally provision capacity constraints to a regional Allocator |
| Protocol stack | Carries and enforces those constraints; does not originate them |
| Allocator | Holds no internal intelligence or discretion; deterministic GCAP only |

RFC #1 Figure 5 is the single-domain picture: the transmission owner feeds **transmission constraints**, the regional system operator feeds **capacity constraints**, and Allocator(s) clear every minute under GCAP.

Hosting and operational responsibility (utility-operated vs. third-party under utility authority) is an Allocator open item. Redundancy (active/standby Allocators per domain) is also unspecified.

## Constraint inputs the domain must provision

Each interval, GCAP clears against three input classes (`specs/gcap/spec.md` §2):

<ParamField body="Grid 1 constraints" type="custodian-provisioned set" required>
Zone power production capacity, transmission constraints, and target reserves. Optional: power distribution factors and dynamics from Dynamic Line Ratings. Which existing transmission-owner signals to standardize is a headline Engineering discussion item.
</ParamField>

<ParamField body="Member Service Descriptors" type="G2P §3.1" required>
In-zone signed requests/offers for the forward time vector. Positions are energy-in-the-interval (v26.0).
</ParamField>

<ParamField body="Peer-Allocator announcements" type="G2P §3.3">
Across coupled zones. MAY add boundary headroom. MUST NOT relax local constraints. Missing required announcements: clear conservatively as if the boundary contributes no additional headroom.
</ParamField>

<ParamField body="Clearing inputs version" type="digest on Commitment" required>
A Commitment MUST identify the interval, the **domain**, and the clearing-inputs version it was computed against. Allocators SHOULD publish (within the domain) the input digest. Publication of that digest is still listed as an Allocator open item.
</ParamField>

An Allocator MUST NOT clear on stale constraint inputs. On staleness or partition it MUST withhold clearing; Members fall back to Grid 1 baseline.

## Membership

Grid 2 has **no admission process** and **no perimeter** (`architecture/overview.md`, Membership without a perimeter).

A Member is any asset running a conformant protocol implementation at a point of interconnection covered by a provisioned domain, under commercial terms with its host utility.

| Layer | What defines it | What does not |
|---|---|---|
| Technical membership | Spec compliance at a qualifying POI whose transmission-owner constraints are provisioned to an Allocator | Registration, a central operator, or a universal rollout |
| Commercial participation | Domain-level agreements with the host utility | G2P / GCAP / DESP message semantics |
| Voluntariness | Distinct from other grid and market requirements; same class of arrangement as emerging connect-and-manage schemes | A requirement that Grid 2 be universally applied |

The design assumes willingness of parties to agree on connect-and-manage principles. Grid 2 does not need to be universally applied; it sits inside the Grid 1 context at any scale.

Certification / conformance test criteria for "spec compliance" are **not specified**. Wire format, state machines, version negotiation, and conformance test vectors remain "to be specified" in G2P.

### Member kinds in a domain

| Kind | Physical asset | Broadcasts | Listens for |
|---|---|---|---|
| Use | Flexible large load | Per-class request to consume (+) | Per-class commit-% |
| Buffer | Storage | Signed charge (+) / discharge (−) offer | Committed dispatch (cleared before any load curtailment) |
| Source | Clean-energy supply | Offer to supply (−) over a forward vector | Committed take |
| Allocator | Domain constraint set | Per-class commit-% to Members; Federation Announcements to peers | In-zone descriptors; peer announcements |

The Allocator never sees internal facility workloads. A Use Member maps workloads to classes at the edge; GCAP clears class-level positions only.

## Commercial terms stay outside the protocol

Commercial participation terms are **domain-level agreements**, not protocol fields. `architecture/allocation-domains.md` and DESP §4 both point at Discussion: Commercial terms.

A domain MAY constrain the mix of classes a Member can declare (example: a minimum Class C share for expedited interconnection). Those limits live in the domain agreement. Class ordering C → B → A remains mandatory in GCAP regardless of commercial policy.

Settlements stay on Grid 1's slower clock. Grid 2 coordinates operation, not prices.

RFC #1 Open Questions that stay off the wire:

| Topic | Open question (RFC #1) |
|---|---|
| Enforcement | What commercial terms look like, especially enforcement of flexible capabilities |
| Class policy | Whether the standard should give guidance or limits on differential service classes |
| Congestion investment | How participating organizations solve direct congestion needs; who decides a new battery |
| Rates | How broader rate structures are impacted; how Grid 2-enabled use is charged |
| Planning | How Grid 2 connections enter IRP / RTO interconnection processes |

<Info>
GitHub Discussions category **Commercial terms** is the comment channel for those items (`CONTRIBUTING.md`). Do not encode prices, SLAs, or class-mix mandates into G2P messages.
</Info>

Whether domains publish a machine-readable **domain descriptor** (constraint scope, class policy, ramp limits) is an open item. Until that exists, implementers treat class-policy and ramp limits as configuration agreed with the host utility, not as a specified object.

## What the Allocator does inside a domain

GCAP is deterministic: identical inputs MUST produce identical allocations. Clearing order:

1. **Headroom** — surplus network capability for the interval
2. **Buffers** — committed dispatch before any load is curtailed
3. **Tiered ramp-down** — DESP order C → B → A, proportional within class; never touching traditional Firm (Grid 1)

Outputs apply to the coming interval only and expire with it. Per-class commit-% / committed dispatch / committed take are the only Allocator-to-Member control surface.

The total participating pool MUST be sized so simultaneous fallback of all Members stays within manageable Grid 1 aggregate ramp limits. That pool bound is the binding constraint on domain growth; sizing methodology is open.

## Failsafe inside a domain

| Condition | Allocator | Members |
|---|---|---|
| Stale constraint inputs | MUST NOT clear | Missed/stale Commitment → fallback |
| Partition of this domain | MUST NOT clear | Element-specific Grid 1 baseline |
| Partition of a peer Allocator | Local clearing continues | MUST NOT trigger fallback in unaffected domains |

Fallback MUST be locally determinable from the Member's own state and last-known configuration. It MUST NOT depend on reaching a remote peer. Ramp rates agreed with the host utility apply on every transition.

## Open items that change implementers

| Item | Owner file | Effect if you implement now |
|---|---|---|
| Conformance / certification criteria | `architecture/allocation-domains.md` | Spec compliance is declared, not certified |
| Machine-readable domain descriptor | `architecture/allocation-domains.md` | Class policy and ramp limits stay in the utility agreement |
| Overlapping local + regional membership | `architecture/allocation-domains.md` | Do not invent a dual-commit rule |
| Hierarchical element IDs | `specs/g2p/spec.md` §2 | Bind a stable ID to POI + provisioned domain; format is open |
| Federation announcement schema | `architecture/federation.md`, G2P §3.3 | Identify announcing domain, interval, coupled-boundary quantities; fields TBD |
| Transmission-owner input standardization | `members/allocator.md`, RFC #1 Engineering | Provision the required constraint set; signal catalog is open |
| Allocator hosting / redundancy | `members/allocator.md` | Authority stays with the transmission owner either way |

## Related pages

<CardGroup>
  <Card title="Minimum viable domain" href="/minimum-viable-domain">
    Host utility plus one flexible load, transmission-owner constraint provisioning, and the connect-and-manage on-ramp.
  </Card>
  <Card title="Federation" href="/federation">
    Announce-and-listen across nested local-to-regional domains; missing announcements do not trip unrelated members.
  </Card>
  <Card title="Allocator" href="/allocator">
    No-discretion deterministic clearing, constraint-authority inputs, withhold-on-stale, and whole-pool ramp sizing.
  </Card>
  <Card title="Provision constraint inputs" href="/provision-constraint-inputs">
    Required Grid 1 constraint set, optional DLR and distribution factors, and the no-relax rule for peer announcements.
  </Card>
  <Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
    Membership without a perimeter, NERC/FERC/TSO non-interference, and coordination without prices.
  </Card>
  <Card title="Service classes" href="/service-classes">
    DESP A/B/C above Firm, mandatory C-B-A curtailment, and domain class-policy limits that stay in the agreement.
  </Card>
</CardGroup>

---

## 07. Service classes

> DESP classes A, B, and C above Grid 1 Firm, curtailment order C then B then A, Firm/Semi-Firm/Flex aliases, and per-interval reclassification.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/07-service-classes.md
- Generated: 2026-08-17T18:26:13.466Z

### Source Files

- `specs/desp/spec.md`
- `specs/gcap/spec.md`
- `specs/g2p/spec.md`
- `members/use.md`
- `rfcs/grid-2-rfc-1.pdf`

---
title: "Service classes"
description: "DESP classes A, B, and C above Grid 1 Firm, curtailment order C then B then A, Firm/Semi-Firm/Flex aliases, and per-interval reclassification."
---

DESP (`specs/desp/spec.md`, version **26.0-draft**) is the Grid 2 service-class taxonomy. Use Members advertise one signed consume position per class in a G2P Service Descriptor; GCAP Allocators MUST honor class order when constraints bind; Traditional Firm (Grid 1) sits outside the overlay and is never cut by GCAP.

## Class stack

Grid 2 stratifies demand **above** the existing firm layer. Classes **A**, **B**, and **C** together are traditional non-firm demand (RFC #1, Figure 2).

```text
 Grid 1  Traditional Firm          served under existing firm service
         ────────────────────────────────────────────────────────────
 Grid 2  A  Assured      highest non-firm   curtailed last
         B  Preferred    middle             curtailed after C, before A
         C  Best Efforts lowest             curtailed first
         ────────────────────────────────────────────────────────────
         Buffer committed dispatch clears BEFORE any A/B/C cut
```

| Class | Canonical name | Position | Semantics |
|---|---|---|---|
| — | Traditional Firm (Grid 1) | Base | Outside Grid 2. Served per existing firm service. **Never curtailed by GCAP.** |
| **A** | Assured | Highest non-firm | Curtailed last among Grid 2 classes. Latency-sensitive, hard-to-defer demand. |
| **B** | Preferred | Middle | Curtailed after C, before A. Deferrable-with-constraints demand. |
| **C** | Best Efforts | Lowest | Curtailed first. Unmet or deferred most often. Statistical-multiplexing tier. |

<Warning>
Naming is not closed. RFC #1 Protocol Interactions uses **Firm / Semi-Firm / Flex** for the three Use positions. DESP maps those aliases to **A / B / C**. Reconciliation of Assured/Preferred/Best-Efforts vs. Firm/Semi-Firm/Flex is an explicit DESP open item. Implement against letter codes **A**, **B**, **C** until the living spec settles names.
</Warning>

| RFC #1 / interaction-table alias | DESP letter | DESP name |
|---|---|---|
| Firm | A | Assured |
| Semi-Firm | B | Preferred |
| Flex | C | Best Efforts |

Do not confuse the **Firm** alias for Class A with **Traditional Firm (Grid 1)**. The latter is not a DESP class and is not a G2P Use position.

## Normative ordering

When GCAP still needs relief after headroom and Buffer dispatch, it ramps down Use allocations in this order only:

1. **C** Best Efforts first
2. **B** Preferred next
3. **A** Assured last
4. **Traditional Firm (Grid 1)** is never touched

Additional MUSTS from DESP §2 and GCAP §3:

- Class ordering for curtailment MUST be **C → B → A**.
- Buffer **committed dispatch** MUST clear **before any class is curtailed**.
- Within a class, curtailment MUST be **proportional** (connection size and differential request size). The exact weighting formula is still open in GCAP §7.
- Allocations apply to the **coming one-minute interval only** and expire with it.

<Info>
Buffers are not A/B/C. A Buffer offers signed charge (+) / discharge (−) and receives **committed dispatch**, not per-class commit-%. Sources in v26.0 offer a single **committed take**; mirrored A/B/C on supply is an open item on the Source Member spec.
</Info>

## What travels on the wire (logical)

G2P carries the taxonomy; it does not define it. Wire format is unspecified.

**Use → Allocator** — Service Descriptor (`G2P` §3.1)

<ParamField body="request to consume" type="signed position per class (+)" required>
One signed position per DESP class over a forward time vector. Units are energy in the interval (v26.0 scope).
</ParamField>

<ParamField body="class set" type="A | B | C" required>
Positions MAY change when the descriptor is reissued. Classes MAY change per interval (DESP dynamic reclassification).
</ParamField>

**Allocator → Use** — Commitment (`G2P` §3.2)

<ResponseField name="commit-%" type="per-class percentage">
Per-class allocation for the coming interval. Identifies interval, domain, and clearing-inputs version.
</ResponseField>

<ResponseField name="committed dispatch / committed take" type="Buffer / Source">
Not classed A/B/C in v26.0. Buffer dispatch is step 2 of GCAP, before any load cut.
</ResponseField>

**Use → Allocator** — Response / Telemetry (`G2P` §3.4)

Members MUST report **actual per-class dispatch** against the Commitment (verified self-dispatch).

```mermaid
sequenceDiagram
  participant Use as Use Member
  participant G2P as G2P
  participant Alloc as Allocator (GCAP)
  Use->>G2P: Service Descriptor<br/>signed +A +B +C (energy / interval)
  G2P->>Alloc: in-zone descriptors
  Note over Alloc: 1 headroom<br/>2 Buffer dispatch<br/>3 cut C then B then A<br/>never Grid 1 Firm
  Alloc->>G2P: Commitment<br/>per-class commit-%
  G2P->>Use: commit-% for coming minute
  Use->>G2P: per-class verified self-dispatch
```

## Per-interval reclassification

Classification is **dynamic**. A Member MAY reclassify request buckets **each interval**.

<Steps>
  <Step title="Map workloads at the edge">
    The Use Member owns how internal workloads land on A/B/C. The Allocator never sees or directs facility internals; it clears **class-level positions only**.
  </Step>
  <Step title="Sign one consume position per class">
    Broadcast a G2P Service Descriptor: one signed `request to consume (+)` per class over the forward time vector. Reissue the descriptor if the mix changes.
  </Step>
  <Step title="Listen for per-class commit-%">
    Self-dispatch within that interval's commit-% and agreed host-utility ramp rates. Report verified per-class dispatch.
  </Step>
  <Step title="Treat missing or stale commit as fallback">
    Revert to the Grid 1 baseline (firm load limit) or manual curtailment. Fallback is locally determinable; it MUST NOT depend on a remote peer.
  </Step>
</Steps>

<Note>
Reclassification does not change GCAP order. Moving energy from C into A raises that bucket's protection only for intervals where the new descriptor is cleared. There is no specified carry of unmet Class C into later intervals (GCAP open: does deferred Class C accrue priority?).
</Note>

## Domain class policy

A domain **MAY** constrain the mix a Member can declare (for example a minimum Class C share for expedited interconnection). Those limits are **commercial-terms** in the domain agreement, not protocol fields. Whether the standard itself should give guidance or limits on differential classes is an RFC #1 open question (Discussion: Commercial terms).

Technical membership is spec compliance at a provisioned point of interconnection. Class caps, enforcement of flex capability, and charging for Grid 2-enabled use stay outside DESP/GCAP/G2P.

## Allocator behavior (class-relevant)

The Allocator has **no discretion**. Given identical inputs, any conformant GCAP implementation MUST emit identical per-class allocations.

| GCAP step | Class effect |
|---|---|
| 1. Headroom | Surplus network capability for the interval, before any cut |
| 2. Buffers | Absorb shortfall or surplus; **before any load curtailment** |
| 3. Tiered ramp-down | Reduce Use allocations **C, then B, then A** |
| Within class | Proportional to connection size and differential request size |
| Stale / partition | Allocator MUST NOT clear; Members fall back |
| Ramp safety | Consecutive-interval allocation deltas MUST respect each member's agreed ramp rates |

Federation announcements MAY add boundary headroom but MUST NOT relax local constraints. Whether announcements carry **per-class aggregates** or only boundary headroom is open.

## What is not specified yet

Treat these as unimplemented, not implied:

| Open item | Owner |
|---|---|
| Assured/Preferred/Best-Efforts vs. Firm/Semi-Firm/Flex names | DESP §5 |
| Fixed three classes vs. domain-extensible class count | DESP §5 |
| Per-class unmet-frequency envelopes (SLA-like) | DESP §5 |
| Per-class ramp-rate and snap-back limits (research cites 15-minute ramp discipline) | DESP §5 |
| Enforcement of declared class behavior beyond G2P §3.4 telemetry | DESP §5 |
| Exact intra-class proportionality formula | GCAP §7 |
| Fairness across intervals for deferred Class C | GCAP §7 |
| Standard workload→class mapping per facility type | Use Member; DESP §3 is informative only |
| Mid-interval return of unused committed allocation | Use Member open items |
| A/B/C structure for Source offers | Source Member (single class in v26.0) |

Informative Flex 0–3 and ERCOT CLR/PCLR alignments belong on the mapping page, not in the Allocator.

## Failure and fallback vs. class cuts

Class cuts are **normal GCAP output** (a commit-% below 100% on C, then B, then A). Failsafe is different: missing or stale Commitment, lost peers, or an Allocator that withholds clearing.

| Event | Use Member |
|---|---|
| Cleared commit-% &lt; 100% on a class | Self-dispatch that class to the committed share |
| No fresh Commitment for the interval | MUST revert to Grid 1 firm load limit or manual curtailment; follow allowed ramps |
| Overlay plane down | Same Grid 1 baseline; orchestration failure MUST NOT leave the grid worse than pre-Grid 2 |

## Next

<CardGroup>
  <Card title="DESP reference" href="/desp-reference">
    Class table, mandatory C-B-A order, domain class-policy limits, and remaining naming/SLA items.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Headroom, then buffers, then tiered curtailment; per-class commit outputs; determinism.
  </Card>
  <Card title="Map workloads to classes" href="/map-workloads-to-classes">
    Informative Flex 0–3 and ERCOT CLR/PCLR mappings; what the Allocator never sees.
  </Card>
  <Card title="Use Member" href="/use-member">
    Per-class consume positions, commit-% listen, self-dispatch MUSTS, firm-limit fallback.
  </Card>
</CardGroup>

---

## 08. Failsafe model

> No-surprises fallbacks per element, interval-only commitments, pool ramp limits, and fallback that is locally determinable without a remote peer.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/08-failsafe-model.md
- Generated: 2026-08-17T18:27:02.181Z

### Source Files

- `architecture/failsafe-model.md`
- `members/use.md`
- `members/buffer.md`
- `members/source.md`
- `members/allocator.md`
- `specs/g2p/spec.md`

---
title: "Failsafe model"
description: "No-surprises fallbacks per element, interval-only commitments, pool ramp limits, and fallback that is locally determinable without a remote peer."
---

`architecture/failsafe-model.md` is the living **no surprises** contract for Grid 2 v26.0-draft. Every Member Element and Allocator that loses peers, fresh context, or a current-interval Commitment MUST revert to a Grid 1 baseline that is locally determinable from its own state and last-known configuration. Failure of the orchestration plane MUST NOT leave the physical grid worse off than the pre-Grid 2 status quo.

The file is **Draft — seeking input**. RFC #1's Protocol Interactions table is the archival source; G2P §3.2 / §5 and GCAP §5 / §6 make the same fallbacks normative on the wire and in clearing.

<Warning>
A Member MUST NOT wait for a remote peer to authorize fallback. Missing or stale Commitment for the current one-minute interval is itself the trigger.
</Warning>

## Principle

Grid 2 is an overlay. On any Member↔Allocator fault, stale Commitment, invalid clearing inputs, or lost context, the element behaves as it would have under prior Grid 1 curtailment and interconnection regimes, inside agreed ramp rates.

RFC 2119 / RFC 8174 keywords in `architecture/failsafe-model.md` and the member files apply.

| Property | Normative rule |
|---|---|
| Objective | No surprises versus pre-Grid 2 Grid 1 behavior |
| Commitment lifetime | Valid for the identified interval only; expires with that interval |
| Detection | Local: own state + last-known configuration. MUST NOT depend on reaching any remote element |
| Transition | Into fallback, out of fallback, and between interval allocations MUST honor host-utility ramp rates |
| Pool bound | Simultaneous fallback of all Members MUST stay inside manageable Grid 1 system ramp limits |

This is the **No surprises** row of `architecture/design-principles.md`: failsafe defaults with status quo Grid 1, managed to local and regional ramp limits.

## What triggers fallback

Treat the element as in fallback when any of the following is true.

| Trigger | Who detects it | Required action |
|---|---|---|
| No `commit-%` / committed dispatch / committed take for the **current** interval | Member | Enter element-specific Grid 1 fallback |
| Commitment present but stale for this interval | Member | Same as missing Commitment |
| Loss of peers or context | Member | Same as missing Commitment |
| Loss of connectivity | Member (G2P §5) | Element-specific fallback |
| Missed Commitments beyond the (still unspecified) staleness threshold | Member (G2P §5) | Element-specific fallback |
| Stale or invalid local Grid 1 constraint inputs | Allocator | MUST NOT clear; Members then miss a Commitment and fall back |
| Domain partition that prevents a fresh local clear | Allocator | MUST NOT clear; Members fall back |
| Grid 1 dispatch instruction conflicts with a Grid 2 allocation | Member (`architecture/temporal-position.md`) | Grid 1 instruction prevails (even outside fallback) |

<Info>
G2P still owes explicit staleness timers (missed-interval count). Until those land, the living failsafe rule is stricter on interval identity: a Member that has not received a Commitment **for the current interval** MUST treat itself as in fallback. Do not invent a grace window.
</Info>

G2P Commitments MUST identify the **interval**, the **domain**, and the **clearing inputs version** they were computed against. Members match on those fields; they do not reuse last interval's `commit-%`.

## Per-element fallback

Normative rows from `architecture/failsafe-model.md`, restated in `members/use.md`, `members/buffer.md`, `members/source.md`, and `members/allocator.md`.

| Element | On loss of Allocator / peers / fresh context |
|---|---|
| **Use** (load) | MUST revert to its Grid 1 baseline (**firm load limit**) or **manual curtailment**; MUST follow allowed ramp rates while transitioning |
| **Buffer** (storage) | MUST revert to its **standalone Grid 1 schedule**; carries **no Grid 2 support commitment** while in fallback; MUST follow allowed ramp rates |
| **Source** (supply) | MUST revert to **Grid 1 baseline interconnection behavior**; MUST follow allowed ramp rates |
| **Allocator** | If constraint inputs are stale or the **domain** is partitioned, MUST NOT clear. Members that detect a missed clearing fall back per the rows above |

### Use

Listens for per-class `commit-%`. On stale Commitment or lost peers: Grid 1 firm load limit or manual curtailment, on the agreed ramp. Self-dispatch and G2P §3.4 verified telemetry remain Member obligations while the overlay is live; fallback-compliance audit telemetry is still an open item.

### Buffer

Listens for **committed dispatch**, which GCAP clears **before any load is curtailed**. In fallback the Buffer is not a shock absorber for the overlay. It MUST NOT keep a Grid 2 support commitment after it loses the Allocator.

### Source

Listens for **committed take**. Fallback is interconnection behavior already allowed under Grid 1, on the agreed ramp — not a continued Grid 2 take schedule.

### Allocator

Holds no discretion. On stale inputs or a partition of **its own domain**, it withholds the entire clear rather than publishing a partial or last-known Commitment. Whole-pool participation MUST stay sized so that if every Member falls back at once, aggregate ramps remain manageable.

## Interval-only commitments

GCAP §4: allocations apply to the **coming interval only** and expire with it. G2P messages are per-interval (one minute) unless noted.

<ParamField body="interval" type="one-minute clock id" required>
Commitment validity key. A Commitment for interval *n* MUST NOT be executed as the allocation for interval *n+1*.
</ParamField>

<ParamField body="domain" type="allocation-domain id" required>
Domain the Allocator cleared. Members MUST NOT apply a Commitment from another domain.
</ParamField>

<ParamField body="clearing inputs version" type="digest / version id" required>
Inputs the Allocator used. GCAP SHOULD publish this digest in-domain so any party can reproduce the clear.
</ParamField>

Wire format, intra-interval deadlines (descriptor, clear, publish), and clock-sync requirements are unspecified in G2P §4 / §7.

## Allocator withhold vs federation partition

Do not collapse these two "partition" cases. Living federation text is more precise than the one-line Allocator failsafe row.

```mermaid
flowchart TD
  subgraph member [Member Element]
    Mq{Commitment for this interval present and fresh?}
    Mop[Self-dispatch to commit-% / dispatch / take]
    Mfb[Local Grid 1 fallback on agreed ramp]
    Mq -->|yes| Mop
    Mq -->|missing, stale, or lost peers| Mfb
  end

  subgraph alloc [Allocator local domain]
    Aq{Local Grid 1 constraint inputs fresh and valid?}
    Acl[Run GCAP and publish Commitment]
    Ahold[MUST NOT clear]
    Aq -->|yes| Acl
    Aq -->|stale, invalid, or domain partition| Ahold
  end

  subgraph fed [Allocator federation]
    Fmiss[Required peer announcement missing]
    Fcons[Clear locally as if boundary adds no headroom]
    Fpart[Partition between peer Allocators]
    Flocal[Local clear continues; do not trip unrelated Members]
    Fmiss --> Fcons
    Fpart --> Flocal
  end

  Ahold --> Mfb
  Acl --> Mq
```

| Fault | Allocator | Members in this domain | Members in an unrelated domain |
|---|---|---|---|
| Stale / invalid **local** constraint inputs | MUST NOT clear (GCAP §5) | Missed Commitment → fallback | Unaffected |
| Partition that blocks **this** domain's local context or publish | MUST NOT clear | Fallback | Unaffected |
| Missing **peer** federation announcement | MUST still clear **conservatively** (boundary contributes no extra headroom) | Stay on the local clear | Unaffected |
| Partition **between peer Allocators** | MUST NOT be prevented from local clearing | MUST NOT be forced into fallback | MUST NOT be tripped |

Peer announcements MAY add boundary headroom and MUST NOT relax local limits. Conservative federation degrade is independent local operation, not a domain-wide trip.

## Pool sizing and ramp discipline

Two separate bounds, both MUST:

1. **Whole-pool fallback (domain growth cap).** The participating pool in a domain MUST be sized so simultaneous fallback of **all** Members produces aggregate ramps inside manageable Grid 1 system ramp limits. `architecture/failsafe-model.md` calls this the binding constraint on domain growth. Sizing methodology is an open engineering question.
2. **Per-transition ramp.** All transitions — into fallback, out of fallback, and between consecutive interval allocations — MUST respect ramp rates agreed with the host utility. GCAP §6: per-member allocation deltas between consecutive intervals MUST respect each member's agreed rates. Use, Buffer, and Source member files all MUST self-dispatch / honor dispatch inside those rates.

<Note>
DESP lists per-class ramp-rate and snap-back limits as **open**. Research cited there suggests 15-minute ramp discipline; that figure is not a v26.0 protocol constant. Implement against the host-utility agreement, not a DESP default.
</Note>

Domain descriptors that would publish ramp limits in machine-readable form are also open (`architecture/allocation-domains.md`).

## Local determinism

Fallback MUST be computable from:

- the Member's own operating state
- last-known configuration (firm load limit, standalone Grid 1 schedule, interconnection baseline, agreed ramp rates)

It MUST NOT require:

- a live Allocator
- a peer Member
- a federation announcement
- a remote "enter fallback" message

That is the same edge-intelligence rule as clearing: every asset runs the same algorithm against locally observable signals. The Allocator's corresponding rule is withhold-on-stale — it does not invent a last-good clear when inputs are untrustworthy.

## Security posture

Transmission-level deployments are expected on **private networks**. G2P: all Service Descriptors and Commitments MUST be authenticated; integrity MUST be verifiable end-to-end.

NERC CIP applicability, key management, PKI, replay protection, and message-authentication details are open (Discussion: Engineering; G2P §6). Isolation of the comms plane is a **fallback trigger**, not a reason to hold the last Grid 2 set-point.

## Apply fallback

<Steps>
<Step title="Bind the clock">
Operate on the one-minute interval in `architecture/temporal-position.md`. Grid 2 allocations apply to whole minutes. Sub-second primary controls stay Grid 1.
</Step>
<Step title="Accept only a current Commitment">
Use Members apply per-class `commit-%`. Buffers apply committed dispatch. Sources apply committed take. Reject a Commitment whose interval, domain, or inputs version does not match this interval.
</Step>
<Step title="Enter fallback locally if the Commitment is absent">
No current Commitment, stale Commitment, lost peers/context, or G2P connectivity loss → execute the element row above. Do not query a remote element first.
</Step>
<Step title="Ramp, then sit on Grid 1">
Transition on the agreed ramp to firm load limit / manual curtailment (Use), standalone Grid 1 schedule with **no** Grid 2 support (Buffer), or Grid 1 interconnection behavior (Source).
</Step>
<Step title="Allocator: withhold rather than guess">
If local constraint inputs are stale or invalid, publish nothing. Do not replay the previous interval. Members will fail closed on the missed Commitment.
</Step>
<Step title="Allocator: keep local clearing across federation loss">
Missing peer announcements → conservative local clear (no extra boundary headroom). Peer partition MUST NOT trip Members in unaffected domains.
</Step>
</Steps>

## Open items

Still unspecified in the living failsafe file and adjacent specs:

- Quantitative staleness thresholds (how many missed intervals before fallback, versus the current-interval rule)
- Re-entry procedure and hysteresis after fallback
- Coincidental-fallback stability analysis (Discussion: Reliability assurance)
- Audit / telemetry to verify fallback compliance (distinct from G2P §3.4 verified self-dispatch)
- Allocator redundancy (active/standby per domain)
- Pool-sizing methodology for the whole-pool ramp bound

Allocator hosting (utility-operated vs third-party under utility authority) is an Allocator open item, not a change to withhold-on-stale.

## Related pages

<CardGroup>
<Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
Overlay membership, NERC/FERC/TSO non-interference, and why fallback is the Grid 1 baseline.
</Card>
<Card title="One-minute window" href="/one-minute-window">
Interval clock, commit-before-open, and Grid 1-prevails on conflicting dispatch.
</Card>
<Card title="G2P reference" href="/g2p-reference">
Commitment fields, authenticated descriptors, and stale-commitment faults.
</Card>
<Card title="GCAP reference" href="/gcap-reference">
Withhold-on-stale, identical-input determinism, and pool / ramp-safety bounds.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing and whole-pool ramp sizing.
</Card>
<Card title="Federation" href="/federation">
Missing-announcement conservative clear and partition that does not trip unrelated Members.
</Card>
<Card title="Use Member" href="/use-member">
Firm-limit fallback, commit-% listen, and ramp MUSTS.
</Card>
<Card title="Buffer Member" href="/buffer-member">
Standalone Grid 1 schedule and no Grid 2 support while in fallback.
</Card>
<Card title="Source Member" href="/source-member">
Grid 1 interconnection fallback and committed take.
</Card>
</CardGroup>

---

## 09. Federation

> Allocator announce-and-listen, nested local-to-regional domains, missing-announcement conservative clearing, and partition that does not trip unrelated members.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/09-federation.md
- Generated: 2026-08-17T18:28:41.738Z

### Source Files

- `architecture/federation.md`
- `architecture/allocation-domains.md`
- `architecture/failsafe-model.md`
- `specs/g2p/spec.md`
- `specs/gcap/spec.md`
- `members/allocator.md`

---
title: "Federation"
description: "Allocator announce-and-listen, nested local-to-regional domains, missing-announcement conservative clearing, and partition that does not trip unrelated members."
---

Grid 2 federation is the **Allocator ↔ Allocator** pattern in `architecture/federation.md`: peer Allocators exchange G2P **Federation Announcements** across coupled zones, then each runs local GCAP against **its own domain’s Grid 1 custodian constraints**. Domains do not command one another. The living files (`architecture/federation.md`, `specs/g2p/spec.md` §3.3, `specs/gcap/spec.md` §2, `members/allocator.md`) are **26.0-draft / Draft — seeking input**; the announcement **message schema is not specified**.

RFC #1 (`rfcs/grid-2-rfc-1.pdf`, Protocol Interactions and §Extensible System-Wide Architecture) is the archival source. Evolution happens in the living specs, not in the RFC.

<Warning>
Two “partition” rules coexist and must not be collapsed. Missing **peer** announcements force **conservative local clearing**. Stale **Grid 1 constraint inputs** or a **partition of the Allocator from its own Members** force **no clearing** and Member fallback. See [Failsafe model](/failsafe-model).
</Warning>

## Two interaction patterns

Every protocol interaction is one of these two. There is no third control plane.

| Pattern | Direction | What is exchanged | Who decides |
|---|---|---|---|
| **Member ↔ Allocator** | In-zone | Service Descriptors in; per-class `commit-%`, Buffer committed dispatch, Source committed take out | Local GCAP |
| **Allocator ↔ Allocator** | Coupled zones | Federation Announcements (announce-and-listen) | Each Allocator, from **its** Grid 1 custodians |

Member ↔ Allocator is specified in G2P §3.1–3.2 / §3.4 and GCAP. Allocator ↔ Allocator is G2P §3.3 plus the federation MUST/MUST NOT set below. Allocation decisions stay anchored in Grid 1 inputs (zone capacity, transmission constraints, target reserves, optional DLR / distribution factors). Peer announcements **inform**; they never become the authority.

Design style in the living architecture: autonomous domains with BGP-style cross-awareness. Domains announce, listen, and clear locally.

## Nested constraint domains

A **Grid 2 Allocation Domain** is the set of Member Elements cleared by a common Allocator (or Allocator hierarchy) against a common Grid 1 constraint set. Nesting is:

`local transmission congestion zone → utility / balancing authority → regional RTO/ISO`

An Allocator’s associated scope is a constraint domain at **any** level: transmission line → utility load zone → RTO region. A regional system operator MAY additionally provision capacity constraints to a regional Allocator. Authority remains with Grid 1 custodians; the protocol does not mint authority.

```text
Regional Constraint Domain ──────────────── Allocator(s)
├── Utility "A" Constraint Domain ───────── Allocator(s)
│   └── Local Constraint Domain ─────────── Allocator(s)
│       ├── Large Load A1 (Use Member)
│       ├── Large Load A2 (Use Member)
│       └── Storage A1 (Buffer Member)
├── Utility "B" Constraint Domain ───────── Allocator(s)
│   └── Local Constraint Domain ─────────── Allocator(s)
│       ├── Large Load B1 (Use Member)
│       └── Storage B1 (Buffer Member)
├── Supply (Source Member, regional)
└── Storage (Buffer Member, regional)
```

The smallest on-ramp is **one host utility + one flexible load**. Federation is how that local domain later couples to sister utility and regional domains. Commercial terms stay outside the protocol. A Member present in overlapping local + regional domains is an **open item**.

```mermaid
flowchart TB
  subgraph regional["Regional constraint domain"]
    RA["Regional Allocator(s)"]
    RS["Regional Source / Buffer Members"]
    subgraph utilA["Utility A domain"]
      AA["Utility A Allocator(s)"]
      subgraph locA["Local constraint domain"]
        LA["Local Allocator(s)"]
        U1["Use A1"]
        U2["Use A2"]
        B1["Buffer A1"]
      end
    end
    subgraph utilB["Utility B domain"]
      AB["Utility B Allocator(s)"]
      subgraph locB["Local constraint domain"]
        LB["Local Allocator(s)"]
        U3["Use B1"]
        B2["Buffer B1"]
      end
    end
  end
  TO["Grid 1 custodians\nTO constraints; RSO MAY add regional capacity"]
  TO --> LA
  TO --> LB
  TO --> AA
  TO --> AB
  TO --> RA
  LA <-->|"G2P §3.3 Federation Announcement"| AA
  LB <-->|"G2P §3.3 Federation Announcement"| AB
  AA <-->|"G2P §3.3"| RA
  AB <-->|"G2P §3.3"| RA
```

## G2P Federation Announcement

G2P v26.0-draft defines **four** per-interval message families. Federation is family **3.3**.

| Family | Path | Role in federation |
|---|---|---|
| §3.1 Service Descriptor | Member → Allocator | In-zone requests/offers only |
| §3.2 Commitment | Allocator → Member | Local clearing output; missing/stale → Member fallback |
| **§3.3 Federation Announcement** | **Allocator ↔ Allocator** | Coupled-zone announce-and-listen |
| §3.4 Response / Telemetry | Member → Allocator | Verified self-dispatch; not an inter-Allocator control |

Required announcement identity (schema still TBD in G2P):

<ParamField body="announcing domain" type="identifier" required>
Domain that originated the announcement. Element IDs are open; G2P recommends a domain-scoped hierarchical ID mirroring this nesting.
</ParamField>

<ParamField body="interval" type="one-minute interval id" required>
All G2P families are bound to the one-minute clock unless noted. Interval phase alignment across federated domains (common epoch vs per-domain clocks) is open.
</ParamField>

<ParamField body="coupled-boundary quantities" type="quantity set" required>
Quantities at the coupled boundary. Whether this is **boundary headroom only** or **per-class aggregates** is an open item.
</ParamField>

G2P §6 currently requires authentication on **Service Descriptors and Commitments**. Federation Announcement authentication, replay protection, PKI, and NERC CIP mapping are **not** specified. Transmission-level deployments are expected on private networks. Wire format, encoding, version negotiation, and conformance vectors are listed under G2P “To be specified.”

<Note>
G2P §3.2 Commitments MUST identify interval, domain, and the **clearing-inputs version**. GCAP SHOULD publish (in-domain) the input digest each Commitment was computed against. Peer announcements are a GCAP input; they MUST NOT appear as a way to rewrite local Grid 1 limits.
</Note>

## GCAP: how a peer announcement is used

Each interval, GCAP clears against exactly three input classes:

1. **Grid 1 constraints** from the domain’s custodians (required): zone production capacity, transmission constraints, target reserves; optionally distribution factors and DLR dynamics.
2. **Member Service Descriptors** in-zone (G2P §3.1).
3. **Peer-Allocator announcements** across coupled zones (G2P §3.3).

<Warning>
Peer announcements **MAY add boundary headroom** and **MUST NOT relax local constraints**. An Allocator MUST clear only against constraints provisioned by **its own** domain’s Grid 1 custodians.
</Warning>

Clearing order is unchanged by federation: headroom → Buffers (before any load curtailment) → DESP C → B → A, proportional within class. Outputs remain per-class `commit-%`, Buffer committed dispatch, and Source committed take for **the coming interval only**.

## Normative federation rules

| Rule | Binding text | Implementer consequence |
|---|---|---|
| Local authority | MUST clear only against own-domain Grid 1 custodian constraints | Peer data is advisory capacity at the boundary, not a substitute limit |
| Carry path | Federation announcements MUST be carried via G2P | No out-of-band Allocator-to-Allocator control channel is specified |
| Identity | MUST identify announcing domain, interval, and coupled-boundary quantities | Drop or reject announcements that cannot be bound to those three |
| Missing peer announcement | MUST clear **conservatively** as if the coupled boundary contributes **no additional headroom** | Do not invent imported capacity; do not stall the local interval |
| Peer partition | MUST degrade to independent local operation | Partition between peer Allocators MUST NOT prevent local clearing |
| Unrelated members | MUST NOT trigger Member fallback in **unaffected** domains | A sister-domain outage is not a local failsafe event |
| Stale Grid 1 inputs / domain partition | Allocator MUST NOT clear | Members that miss a Commitment fall back per element (Use / Buffer / Source) |

```mermaid
sequenceDiagram
  participant MA as Domain A Members
  participant AA as Allocator A
  participant G1A as Domain A Grid 1 custodians
  participant AB as Allocator B
  participant MB as Domain B Members

  Note over MA,MB: One-minute interval N
  G1A->>AA: Provision local and regional constraints
  MA->>AA: G2P 3.1 Service Descriptors
  AB-->>AA: G2P 3.3 Federation Announcement
  alt Announcement present and usable
    AA->>AA: GCAP: MAY add boundary headroom; MUST NOT relax local limits
  else Required peer announcement missing
    AA->>AA: Conservative clear: boundary headroom = none
  end
  AA->>MA: G2P 3.2 Commitment for interval N
  AA-->>AB: G2P 3.3 Federation Announcement
  Note over MB: Domain B continues independently if A is partitioned
```

## Partition and failsafe (do not trip unrelated members)

Treat these as different faults.

### Peer-Allocator partition (federation plane)

- Required §3.3 announcements for a coupled boundary do not arrive.
- Allocator A still has fresh **local** Grid 1 inputs and in-zone descriptors.
- A **MUST** still clear, treating imported boundary headroom as **zero**.
- Members in A that receive a timely Commitment **MUST NOT** be pushed into fallback solely because B is unreachable.
- Members in B follow B’s own local rules. Partition at the A–B coupling does not cascade.

### Domain partition or stale constraint inputs (Allocator failsafe)

From `members/allocator.md`, GCAP §5, and `architecture/failsafe-model.md`:

- If the Allocator’s **constraint inputs are stale**, or **the domain is partitioned** from the conditions needed to clear, the Allocator **MUST NOT clear**.
- Members that do not receive a current-interval Commitment MUST treat themselves as in fallback (Use → Grid 1 firm limit / manual curtailment; Buffer → standalone Grid 1 schedule, no Grid 2 support commitment; Source → Grid 1 interconnection baseline). All transitions MUST honor agreed ramp rates.
- Fallback MUST be locally determinable. It MUST NOT require reaching a remote peer.

RFC #1’s Protocol Interactions table states Allocator failsafe as “Stale/partitioned → no clearing.” The living federation file **narrows** that for **peer** loss: missing announcements are conservative clearing, not a domain-wide withhold.

<Info>
Whole-pool fallback ramp sizing still binds **each** domain independently. Federation does not move that obligation to the regional parent. Active/standby Allocator redundancy per domain is an open item.
</Info>

## Adopt locally, then federate

RFC #1 §Phased Adoption and `architecture/design-principles.md`:

| Phase | Name | Federation surface |
|---|---|---|
| **0** | Shadow Mode | Run the stack as a dry run; track commitments; execute only the Grid 1 baseline |
| **1** | Local Vertical Integration | Groups of large loads, transmission owners, and LSEs prove the domain inside existing rules |
| **2** | Regional Federation | Peer entities running the same spec interoperate; inter-domain advertisements and policy |

Phase 2 **milestone criteria** are explicitly open in `architecture/federation.md`.

<Steps>
  <Step title="Stand up one Allocation Domain">
    Provision Grid 1 constraints from the transmission owner. Clear one Allocator against in-zone Members. No peer announcements required. See [Minimum viable domain](/minimum-viable-domain) and [Provision constraint inputs](/provision-constraint-inputs).
  </Step>
  <Step title="Keep Phase 0 execution on Grid 1">
    Exchange and track G2P Commitments. Physical dispatch stays on the Grid 1 baseline until the domain is ready to honor `commit-%`.
  </Step>
  <Step title="Couple a boundary only after both sides speak G2P §3.3">
    Each Allocator continues to clear against **its** custodian limits. Import at most announced boundary headroom. If the peer is silent, clear as if that boundary adds nothing.
  </Step>
  <Step title="Verify partition isolation">
    Drop the peer announcement path. Confirm local Commitments still publish and that Members in the live domain do **not** enter fallback. Confirm the isolated peer’s Members follow **that** domain’s own stale/missed-Commitment rules only.
  </Step>
</Steps>

## Open items (do not invent)

`architecture/federation.md`, G2P, GCAP, and `architecture/temporal-position.md` leave these unspecified:

- Announcement payload: boundary headroom only vs per-class aggregates
- G2P §3.3 message schema, wire format, and state machines
- Loop prevention and path attributes in multi-level hierarchies
- Inter-domain policy (who may import whose headroom)
- Phase 2 milestone criteria
- Interval phase alignment across federated domains
- Hierarchical element-ID format
- Overlapping-domain membership (local + regional)
- Allocator redundancy (active/standby)
- Authentication requirements specific to Federation Announcements

## Next

<CardGroup>
  <Card title="Allocation domains" href="/allocation-domains">
    Nested domains, transmission-owner authority, voluntary membership.
  </Card>
  <Card title="Allocator" href="/allocator">
    Deterministic clearing, federation broadcasts/listens, withhold-on-stale.
  </Card>
  <Card title="Failsafe model" href="/failsafe-model">
    Element fallbacks, interval-only commits, locally determinable revert.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Four message families including §3.3 Federation Announcement.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Peer announcements as inputs that must not relax local limits.
  </Card>
  <Card title="Provision constraint inputs" href="/provision-constraint-inputs">
    Required Grid 1 set and the no-relax-from-peers rule.
  </Card>
  <Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
    Dry-run now; Phase 2 federation only after local proof.
  </Card>
</CardGroup>

---

## 10. Run Phase 0 shadow mode

> Phase 0 dry-run: exchange and track commitments, execute only the Grid 1 baseline, then graduate to Phase 1 local integration and Phase 2 federation.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/10-run-phase-0-shadow-mode.md
- Generated: 2026-08-17T18:28:46.633Z

### Source Files

- `architecture/design-principles.md`
- `architecture/federation.md`
- `architecture/failsafe-model.md`
- `CONTRIBUTING.md`
- `rfcs/grid-2-rfc-1.pdf`
- `README.md`

---
title: "Run Phase 0 shadow mode"
description: "Phase 0 dry-run: exchange and track commitments, execute only the Grid 1 baseline, then graduate to Phase 1 local integration and Phase 2 federation."
---

RFC #1 §Phased Adoption defines **Phase 0 — Shadow Mode** as: run the full protocol stack as a dry run; make and track commitments; execute only what would have happened anyway. In this repository that stack is **G2P** (`specs/g2p/spec.md`, v26.0-draft), **GCAP** (`specs/gcap/spec.md`), and **DESP** (`specs/desp/spec.md`). Physical dispatch stays on each element's **Grid 1 baseline**. There is no shadow-mode flag, CLI, or wire format in the living specs — Phase 0 is an operational constraint on an otherwise complete interval loop.

<Warning>
All three protocols and the member files are `Status: Draft — seeking input`. G2P §7 leaves wire format, encoding, element state machines, version negotiation, and conformance test vectors unspecified. A Phase 0 run is an implementation report against Draft text, not a conformance claim against a Stable `v26.Y` line.
</Warning>

## What Phase 0 does and does not do

| Surface | Phase 0 requirement | Not in Phase 0 |
|---|---|---|
| G2P message families | Exchange and persist Service Descriptors, Commitments, and Response / Telemetry on the one-minute clock | A published encoding or transport |
| GCAP | Allocator computes per-class `commit-%`, Buffer committed dispatch, and Source committed take from provisioned Grid 1 constraints | Binding those outputs to physical setpoints |
| DESP | Members declare A / B / C positions; Allocator records C → B → A curtailment order | Charging, class SLAs, or domain class-mix enforcement (commercial terms, outside the protocol) |
| Physical POI | Execute only the Grid 1 baseline that would have run without Grid 2 | Self-dispatch of the Commitment |
| Federation announcements (G2P §3.3) | Optional local bookkeeping | Phase 2 inter-domain interoperation |

RFC #1 recommends starting in **select grid pockets**, typically a hyperscaler, a utility transmission provider, a clean energy provider, and a load serving entity. The smallest Allocation Domain remains a **host utility plus one flexible load** (`architecture/allocation-domains.md`). Broader recognition (for example FERC-level) is deferred until the local path is proven (`architecture/design-principles.md`).

## Adoption lifecycle

```mermaid
stateDiagram-v2
    [*] --> Phase0: RFC 1 recommended start
    Phase0: Phase 0 Shadow Mode
    Phase0: protocol runs, Grid 1 executes
    Phase1: Phase 1 Local Vertical Integration
    Phase1: solution proof in existing rules
    Phase2: Phase 2 Regional Federation
    Phase2: peer Allocators announce and listen
    Phase0 --> Phase1: local pocket ready to bind commits
    Phase1 --> Phase2: same-spec peers couple domains
    Phase0 --> Phase0: interval loop, no physical Grid 2
```

| Phase | RFC #1 wording | Binding physical behavior |
|---|---|---|
| **0 Shadow Mode** | Run the full stack as a dry run; make and track commitments; execute only what would have happened anyway | Grid 1 baseline / standalone schedule / interconnection behavior (`architecture/failsafe-model.md`) |
| **1 Local Vertical Integration** | Groups of large loads, transmission owners, and load serving entities build a solution proof in existing rules structures | Members self-dispatch Commitments inside host-utility parameters |
| **2 Regional Federation** | Peer entities running the same spec interoperate; inter-domain advertisements and policy | Announce-and-listen across coupled zones; local constraints still win (`architecture/federation.md`) |

`architecture/federation.md` lists **Phase 2 milestone criteria** as an open item. Do not invent a graduation scorecard.

## Interval loop (dry-run)

Phase 0 uses the same Member ↔ Allocator pattern as live operation. The split is at the point of interconnection: the Commitment is recorded; the physical asset does not follow it.

```mermaid
sequenceDiagram
    participant Use as Use / Buffer / Source
    participant Alloc as Allocator
    participant TO as Grid 1 custodians
    participant POI as Physical POI
    TO->>Alloc: Provision constraints (capacity, transmission, reserves)
    Use->>Alloc: G2P Service Descriptor (signed positions)
    Alloc->>Alloc: GCAP clear (headroom, buffers, C then B then A)
    Alloc->>Use: G2P Commitment (interval, domain, inputs version)
    Note over Use: Track commit vs baseline; do not bind setpoints
    Use->>POI: Execute Grid 1 baseline only
    Use->>Alloc: G2P Response / Telemetry (actual vs Commitment)
```

<Info>
Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **Grid 1 prevails** (`architecture/temporal-position.md`). In Phase 0 that rule is absolute: the allocation is never the executed instruction.
</Info>

### Messages still required

G2P defines four families. Phase 0 still needs the first, second, and fourth. The third belongs to Phase 2.

<ParamField body="Service Descriptor" type="Member → Allocator" required>
Signed per-interval (or reissued) statement of requests/offers over a forward time vector. Use: one consume position per DESP class. Buffer: signed charge (+) / discharge (−). Source: offer to supply. Units: energy in the interval (v26.0).
</ParamField>

<ParamField body="Commitment" type="Allocator → Member" required>
Per-class `commit-%` to Use; committed dispatch to Buffer (cleared before any load curtailment); committed take to Source. MUST identify interval, domain, and the clearing-inputs version.
</ParamField>

<ParamField body="Response / Telemetry" type="Member → Allocator" required>
Verified self-dispatch report of actual per-class dispatch against the Commitment so the overlay footprint is measurable. In Phase 0, **actual** is the Grid 1 baseline; the Commitment is the counterfactual.
</ParamField>

<ParamField body="Federation Announcement" type="Allocator ↔ Allocator">
Announce-and-listen across coupled zones. Out of Phase 0 scope. A missing peer announcement MUST be treated as no extra boundary headroom if you exercise this path early.
</ParamField>

Timing budget (descriptor deadline, clearing deadline, commitment publication, clock sync) is an open Engineering discussion. Allocations apply to **whole one-minute intervals** only.

## Element behavior in shadow mode

Treat Phase 0 physical output as the same table the failsafe model uses when context is lost. Protocol software still runs; setpoints do not move off baseline.

| Element | Protocol still does | Physical execute (Phase 0) |
|---|---|---|
| **Use** | Broadcast per-class consume positions; listen for `commit-%` | Grid 1 firm load limit or the site's existing manual curtailment; honor agreed ramp rates |
| **Buffer** | Broadcast charge/discharge offers; listen for committed dispatch | Standalone Grid 1 schedule; **no Grid 2 support commitment** |
| **Source** | Broadcast supply offers; listen for committed take | Grid 1 interconnection behavior; agreed ramp rates |
| **Allocator** | Deterministic GCAP from TO-provisioned constraints; publish Commitments and (SHOULD) an inputs digest | Does not command breakers, setpoints, or market awards. On stale inputs or partition: **MUST NOT clear** |

The Allocator has **no discretion** (`members/allocator.md`, GCAP §1). Identical inputs MUST produce identical allocations so a shadow log can be reproduced by any party holding the same descriptors and constraint set.

<Note>
Pool sizing still applies as a planning bound: the participating pool MUST be sized so simultaneous fallback stays inside manageable Grid 1 ramp limits. Phase 0 does not relax that constraint; it is the same bound Phase 1 will inherit.
</Note>

## Run a pocket

<Steps>
<Step title="Fix the domain and authority">
Pick the smallest viable pocket: host utility transmission owner plus at least one Use Member. Authority for constraints is the transmission owner; a regional operator MAY add capacity limits. Commercial terms (flex enforcement, class mix, charging) stay **outside** G2P/GCAP/DESP.
</Step>
<Step title="Provision Grid 1 constraint inputs">
Feed the Allocator each interval: zone production capacity, transmission constraints, target reserves; optionally distribution factors and DLR. Peer announcements MUST NOT relax local limits. GCAP MUST withhold clearing on stale constraint inputs.
</Step>
<Step title="Stand up Draft 26.0-draft implementations">
Implement Use / Buffer / Source / Allocator against `members/*.md` and the three specs. Choose any local encoding and transport; this repository does not specify one. Authenticate every Service Descriptor and Commitment (G2P §6). Transmission-level deployments are expected on private networks.
</Step>
<Step title="Exchange and persist every interval">
On the one-minute clock: Members send descriptors → Allocator runs GCAP → Allocator publishes Commitments (interval, domain, inputs version) → Members **do not** apply them to the POI → Members send telemetry of actual (baseline) versus Commitment.
</Step>
<Step title="Track, do not bind">
Keep a per-interval log that a third party can replay: inputs digest, descriptors, Commitment, actual MW/MWh, and the delta (counterfactual Grid 2 vs executed Grid 1). That delta is the Phase 0 evidence, not a dispatch order.
</Step>
<Step title="Report running code">
File implementation reports in GitHub Discussions (`CONTRIBUTING.md` comment-cycle step **Run**). Use Issues only for spec defects or RFC #1 errata. Running Phase 0 experience is what informs the next living-spec revision.
</Step>
</Steps>

### Suggested per-interval record

There is no mandated schema. A replayable log needs at least:

| Field | Role |
|---|---|
| `interval` | One-minute window the messages bind to |
| `domain` | Allocation Domain id (format open) |
| `inputs_version` / digest | Constraint set the Commitment was computed against (GCAP §5 SHOULD publish) |
| Service Descriptor set | Signed Use / Buffer / Source positions |
| Commitment | `commit-%`, committed dispatch, committed take |
| `actual` | Metered or scheduled Grid 1 baseline |
| `delta` | Commitment minus actual (tracking only) |
| `cleared` | Whether the Allocator published or withheld (stale/partition) |

## Graduation

Specs do not define numeric exit criteria. RFC #1 sequences the work as **local proof first**, then federation.

**Phase 0 → Phase 1** is appropriate when the pocket can bind Commitments to self-dispatch **inside existing Grid 1 rules** (connect-and-manage / host-utility parameters), still meeting NERC, FERC, utility, and TSO/ISO obligations. Phase 1 is the first interval in which executed MW may follow `commit-%` rather than the prior baseline.

**Phase 1 → Phase 2** is appropriate when a second domain runs the same spec and Allocators exchange G2P federation announcements. Partition MUST NOT stop local clearing and MUST NOT trip Members in unaffected domains. Missing announcements clear as **zero extra boundary headroom**.

<Check>
Phase 1 does not require a market-rule change. Grid 2 sits below ~5-minute market dispatch and above sub-second ancillaries, so a voluntary pocket can go live without replacing Grid 1 settlements (`architecture/temporal-position.md`).
</Check>

## Verification signals

A Phase 0 run is healthy when:

- Every interval has either a Commitment that names `interval`, `domain`, and inputs version, or an explicit withhold (stale/partition).
- Replaying stored inputs through a second GCAP implementation reproduces the same allocations.
- Physical telemetry matches the site's **pre-Grid 2** schedule or firm limit, not the Commitment.
- Aggregate ramps, if you simulated applying Commitments, stay inside the host-agreed ramp rates and the domain pool-sizing bound.
- Grid 1 measures (frequency, ACE, flows) are unchanged by the overlay software, because the overlay is not yet moving the POI.

Grid 1 custodians verify the overlay by **aggregate footprint**, not by inspecting internal workloads (`architecture/overview.md`). The Allocator never sees facility-internal mapping of jobs onto A / B / C.

## Failure modes and open items that block a closed-loop test

<AccordionGroup>
<Accordion title="No wire format">
G2P §7. Interoperability between two vendors in one pocket is a local agreement until encoding and test vectors land. Report the encoding you used in the Discussion.
</Accordion>
<Accordion title="Staleness timers unspecified">
Failsafe says allocations are interval-only and a missed `commit-%` is fallback. Quantitative missed-interval thresholds and re-entry hysteresis are open. In Phase 0, fallback equals the behavior you are already executing — still log withhold vs miss.
</Accordion>
<Accordion title="Intra-interval timing budget open">
Commit-before-open is required in spirit (`architecture/temporal-position.md`) but the millisecond/second budget is an Engineering discussion. Do not claim a spec deadline.
</Accordion>
<Accordion title="Telemetry and conformance tests open">
G2P §3.4 verification granularity, metering source of truth, and attestation are unspecified. Domain certification criteria for “spec compliance” are an open item on allocation domains. Phase 0 reports should state how actuals were measured.
</Accordion>
<Accordion title="Phase 2 criteria not written">
Do not treat federation announcements, loop prevention, or import policy as Phase 0 exit gates.
</Accordion>
</AccordionGroup>

<Warning>
Do not size or operate a shadow pool that would be unsafe if software later bound Commitments by mistake. Ramp discipline and whole-pool fallback limits are normative now, including in dry-run.
</Warning>

## Related pages

<CardGroup>
<Card title="Failsafe model" href="/failsafe-model">
The Grid 1 baselines Phase 0 executes on purpose, and that Phase 1+ must revert to on fault.
</Card>
<Card title="Minimum viable domain" href="/minimum-viable-domain">
Host utility plus one flexible load: the on-ramp pocket for a first shadow run.
</Card>
<Card title="G2P reference" href="/g2p-reference">
The four message families, one-minute clock, and authentication MUSTS the dry-run still exercises.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing, withhold-on-stale, and constraint-authority inputs.
</Card>
<Card title="Federation" href="/federation">
What Phase 2 adds: announce-and-listen, conservative missing-announcement clearing.
</Card>
<Card title="Contributing" href="/contributing">
Where Phase 0 implementation reports go (Discussions) and how they feed the next spec revision.
</Card>
</CardGroup>

---

## 11. Map workloads to classes

> Informative Flex 0–3 and ERCOT CLR/PCLR mappings onto DESP A/B/C, plus what the Allocator never sees inside a facility.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/11-map-workloads-to-classes.md
- Generated: 2026-08-17T18:28:54.844Z

### Source Files

- `specs/desp/spec.md`
- `members/use.md`
- `specs/gcap/spec.md`
- `rfcs/grid-2-rfc-1.pdf`
- `architecture/overview.md`

---
title: "Map workloads to classes"
description: "Informative Flex 0–3 and ERCOT CLR/PCLR mappings onto DESP A/B/C, plus what the Allocator never sees inside a facility."
---

DESP §3 in `specs/desp/spec.md` (v26.0-draft) publishes an **informative** Flex 0/1/2/3 and ERCOT CLR/PCLR alignment onto classes **A / B / C**. A Use Member (`members/use.md`) performs that mapping at the edge, then emits one signed per-class *request to consume* over G2P. The Allocator never receives workload identities, job queues, or facility topology — GCAP clears class-level positions only.

<Warning>
DESP §3 is not a protocol identifier set. G2P Service Descriptors and GCAP commit-% use DESP classes A, B, and C (with Firm / Semi-Firm / Flex as an unresolved alias). Flex 0–3 and CLR/PCLR labels MUST NOT appear as G2P class names.
</Warning>

## Protocol surface vs facility interior

Use Members own three edge decisions that never enter the Allocator:

- How to map internal workloads onto service classes
- Which demand is deferrable, and when
- Anticipating the facility's own forward load

That split is the *scale without singular operator* rule: every asset runs the same algorithm against the same observable signals. Grid 1 custodians verify the overlay by aggregate footprint (frequency stability, ACE, transmission flows, peak shaving), not by inspecting a member's internals.

```mermaid
flowchart LR
  subgraph Facility["Use Member facility — Allocator never sees"]
    W["Workloads<br/>inference / training / spot / batch"]
    MAP["Edge mapping<br/>DESP §3 informative"]
    SD["Self-dispatch + agreed ramps"]
    W --> MAP
  end

  subgraph Wire["G2P — class positions only"]
    DESC["Service Descriptor<br/>signed A / B / C energy"]
    TEL["Telemetry<br/>per-class actual vs Commitment"]
  end

  subgraph Domain["Allocator / GCAP"]
    IN["Grid 1 constraints<br/>+ peer announcements"]
    CLR["Deterministic clear<br/>headroom → buffers → C then B then A"]
    OUT["Per-class commit-%"]
    IN --> CLR
    CLR --> OUT
  end

  MAP -->|"one signed position per class"| DESC
  DESC --> CLR
  OUT --> SD
  SD --> TEL
```

G2P `Service Descriptor` (Member → Allocator) for Use:

<ParamField body="request to consume" type="signed energy (+)" required>
One signed position per DESP class over a forward time vector. v26.0 units are energy in the one-minute interval.
</ParamField>

<ParamField body="class" type="A | B | C" required>
DESP class. Positions MAY be reclassified each interval. Traditional Firm (Grid 1) is outside Grid 2 and is never curtailed by GCAP.
</ParamField>

<ParamField body="commit-%" type="per-class fraction">
Allocator output the Use Member listens for. MUST self-dispatch within that commit-% for the interval, within host-utility ramp parameters.
</ParamField>

<ParamField body="verified self-dispatch" type="per-class actuals" required>
G2P §3.4 telemetry: actual per-class dispatch against the Commitment. Open: verification granularity, metering source of truth, attestation.
</ParamField>

## Informative Flex 0–3 and ERCOT alignment

Field evidence in DESP §3 is aligned with Emerald AI's Flex 0/1/2/3 schema and ERCOT CLR/PCLR constructs. RFC #1 positions Grid 2 as an operational layer that can coexist with ERCOT PCLR (Provisional Controllable Load Resources) and PJM IRAS/PRD in the minutes timeframe.

| DESP class | Name | Flex tier | ERCOT alignment | Typical workloads | Flexibility the edge can use |
|---|---|---|---|---|---|
| **A** | Assured (highest non-firm) | ≈ Flex 0 | LPC-aligned firm portion | Real-time inference, interactive services | Spatial routing, cooling, behind-the-meter storage, bounded power-capping (~20% inference headroom without deferring requests). Sub-second SLAs. |
| **B** | Preferred | ≈ Flex 1–2 | CLR/PCLR dispatchable portion | Training with checkpointing, deadline batch | Checkpoint pause, throttling, GPU frequency-capping. Minutes-to-hours deferral. 10–25% throttle sustained 3–6 h is field-proven. Primary flex reservoir. |
| **C** | Best Efforts (lowest) | ≈ Flex 3 | Shed-first interruptible tier | Opportunistic / spot compute, non-urgent batch | Hours-to-days pause; deep temporal and spatial shifting. |
| — | Traditional Firm (Grid 1) | Outside overlay | Existing firm service | Contracted firm load | Never curtailed by GCAP. Failsafe target when commit-% is missing or stale. |

G2P interaction-table aliases map **Firm / Semi-Firm / Flex → A / B / C**. Naming reconciliation (Assured / Preferred / Best Efforts vs those aliases) is an open DESP item.

<Info>
The mapping is written from data-center flexibility research. Use Members also cover electrified industry and sites that combine flex-capable load with on-site power. Standard workload→class guidance **per facility type** is an open item on `members/use.md`.
</Info>

### Empirical anchors (class design, not protocol limits)

DESP §3 and RFC #1 §Industry Analysis Informing Grid 2.0 cite:

| Anchor | Claim in the specs / RFC |
|---|---|
| Emerald AI production trial | 25% sustained facility power reduction for 3 hours; 256 GPUs; 15-minute ramps |
| Duke, *Rethinking Load Growth* (Norris et al., Feb 2025) | Curtailing 0.25% of annual load unlocks 76 GW US headroom; 1.0% unlocks 126 GW |
| DESP ramp research note | 15-minute ramp discipline suggested for per-class snap-back (not yet normative) |

Those figures inform why Class B is treated as the primary flex reservoir. They are not GCAP inputs and they do not bind commit-%.

## Edge mapping procedure

<Steps>
<Step title="Separate Grid 1 Firm from Grid 2 buckets">
Keep contracted firm load on the Grid 1 baseline. Only non-firm demand is classified A / B / C. GCAP never touches Traditional Firm.
</Step>
<Step title="Apply the informative DESP §3 map">
Assign latency-sensitive / Flex 0 demand to **A**, checkpointable / Flex 1–2 demand to **B**, and interruptible / Flex 3 demand to **C**. Re-bucket each interval if the facility's mix changes.
</Step>
<Step title="Honor domain class policy if the commercial agreement sets one">
A domain MAY constrain the mix a Member can declare (example: a minimum Class C share for expedited interconnection). Those limits live in the domain agreement, not in DESP/GCAP. See Discussion: Commercial terms.
</Step>
<Step title="Emit one signed G2P position per class">
Broadcast energy-in-the-interval requests over the forward vector. Do not attach workload names, GPU inventories, or job SLAs.
</Step>
<Step title="Self-dispatch to commit-% and report per-class actuals">
MUST stay inside per-class commit-% and agreed ramp rates. MUST report verified self-dispatch (G2P §3.4). On missing or stale Commitment, MUST revert to the Grid 1 firm load limit or manual curtailment, still following allowed ramps.
</Step>
</Steps>

RFC #1 Figure 5 shows a utility-domain example of the **external** bucket stack a data-center Use Member might advertise (not an internal job list):

| Bucket | Example request |
|---|---|
| Best Efforts (C) | 300 MW |
| Preferred (B) | 200 MW |
| Assured (A) | 300 MW |
| Firm (Grid 1) | 500 MW |

## What the Allocator never sees

| Inside the facility (edge only) | On the wire / in GCAP |
|---|---|
| Individual workloads, job IDs, SLA clocks | Signed A / B / C energy positions |
| Which racks or processes implement a class | Per-class commit-% |
| How Flex 0–3 or CLR/PCLR labels were applied | DESP class order C → B → A |
| Behind-the-meter cooling, spatial routing, GPU clocks | Optional Buffer Member as a **separate** element (− discharge / + charge) |
| On-site generation used to hold Class A | Source Member offers, if present as their own element |
| Forward load forecast internals | Descriptor reissued each interval |

The Allocator holds **no internal intelligence or discretion**. GCAP order is: headroom first, Buffer committed dispatch second (before any load curtailment), then ramp down Use requests C → B → A, proportional within a class. Intelligence that would require seeing jobs stays on the Use Member.

<Note>
Behind-the-meter storage can appear two ways. DESP §3 lists it as an **internal** Class A flexibility tool (the Allocator still sees only the A position). A storage asset that participates as a Buffer Member is a distinct element with its own offer and committed dispatch. Those are not interchangeable protocol objects.
</Note>

## Constraints and failsafe

- **Reclassification.** A Member MAY reclassify request buckets each one-minute interval. Commitments expire with the interval.
- **Ramp.** All transitions — interval-to-interval and into fallback — MUST respect host-utility ramp rates. DESP flags per-class ramp and snap-back limits as unspecified (research points at 15-minute discipline).
- **Undershoot.** Behavior when actual load is below requested+committed amounts (whether unused allocation returns to the pool mid-interval) is open on `members/use.md`.
- **Fallback.** Loss of peers, missing commit-%, or stale Commitment → Grid 1 firm load limit or manual curtailment. Fallback MUST be locally determinable; it MUST NOT depend on reaching the Allocator.
- **PCLR coexistence.** Grid 2 sits below ~5-minute market dispatch. RFC #1 and `architecture/temporal-position.md` treat that as the window where ERCOT PCLR / PJM IRAS/PRD minute-scale compliance can be operationalized without changing market rules. Grid 1 dispatch instructions prevail on conflict.

## Open items that affect mapping

<AccordionGroup>
<Accordion title="Still unspecified in DESP / Use">
- Standard workload→class mapping guidance per facility type
- Whether the standard itself should give guidance or limits on differential service classes
- Naming: Assured / Preferred / Best Efforts vs Firm / Semi-Firm / Flex
- Fixed three classes vs domain-extensible class count
- Per-class unmet-frequency envelopes (SLA-like)
- Ramp-rate and snap-back limits per class
- Enforcement of declared class behavior (ties to G2P §3.4)
- Minimum telemetry for commit-% compliance
</Accordion>
</AccordionGroup>

Class-policy and flex-enforcement questions are tracked under Discussion: **Commercial terms**. Reliability of materializing declared flexibility at scale is tracked under **Reliability assurance**.

## Next

<CardGroup>
<Card title="Service classes" href="/service-classes">
Normative A / B / C table, C-then-B-then-A curtailment, and per-interval reclassification.
</Card>
<Card title="Use Member" href="/use-member">
Per-class consume positions, commit-% listen, self-dispatch MUSTS, and firm-limit fallback.
</Card>
<Card title="DESP reference" href="/desp-reference">
Class semantics, domain class-policy limits, and open naming / SLA items.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing: the process that never sees facility workloads.
</Card>
</CardGroup>

---

## 12. Provision constraint inputs

> Required Grid 1 constraint set, optional DLR and distribution-factor inputs, input digests, and the rule that peer announcements must not relax local limits.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/12-provision-constraint-inputs.md
- Generated: 2026-08-17T18:29:12.306Z

### Source Files

- `members/allocator.md`
- `specs/gcap/spec.md`
- `architecture/allocation-domains.md`
- `architecture/federation.md`
- `specs/g2p/spec.md`

---
title: "Provision constraint inputs"
description: "Required Grid 1 constraint set, optional DLR and distribution-factor inputs, input digests, and the rule that peer announcements must not relax local limits."
---

Each interval, a GCAP Allocator clears Member Service Descriptors against **Grid 1 constraints provisioned by that domain's custodians**. The living input set is `specs/gcap/spec.md` §2; authority and optional Dynamic Line Ratings (DLR) / distribution-factor language live in `members/allocator.md` and `architecture/allocation-domains.md`. The protocol carries and enforces those bounds. It does not create them.

<Warning>
An Allocator MUST clear only against constraints provisioned by its own domain's Grid 1 custodians. Peer-Allocator announcements MAY add **boundary headroom**. They MUST NOT relax local limits.
</Warning>

## Who provisions

Authority is anchored in the **utility transmission owner**. No Grid 2 element derives authority from G2P, GCAP, or DESP.

| Role | Obligation | What it binds |
|---|---|---|
| Utility transmission owner | MUST provision the Allocator's **local and regional** constraints | Clearing for Member Elements in that Allocation Domain |
| Regional system operator | MAY additionally provision **capacity constraints** | A regional Allocator |
| Peer Allocator | Announce coupled-boundary quantities via G2P | Informs local clearing; never overrides local constraints |

A **Grid 2 Allocation Domain** is the set of Member Elements cleared by a common Allocator (or Allocator hierarchy) against a common Grid 1 constraint set. Domains nest: local transmission congestion zone → utility / balancing authority → regional RTO/ISO.

The smallest viable domain is a host utility plus one flexible load. Membership exists only at a point of interconnection **covered by a provisioned domain**.

```mermaid
flowchart LR
  subgraph custodians [Grid 1 custodians]
    TO["Transmission owner"]
    RSO["Regional system operator"]
  end
  subgraph domain [This Allocation Domain]
    LOCAL["Local and regional constraints"]
    GCAP["GCAP Allocator"]
    DIGEST["Input digest / clearing-inputs version"]
  end
  subgraph peers [Coupled zones]
    ANN["G2P Federation Announcement"]
  end
  TO -->|"MUST provision"| LOCAL
  RSO -->|"MAY add capacity constraints"| LOCAL
  LOCAL --> GCAP
  ANN -->|"MAY add boundary headroom; MUST NOT relax"| GCAP
  GCAP --> DIGEST
```

## Required Grid 1 constraint set

GCAP §2 lists the custodian-provisioned inputs the Allocator clears against each one-minute interval:

<ParamField body="zone power production capacity" type="Grid 1 constraint" required>
Zone-level Grid 1 production capability represented by the Allocator. Same quantity RFC #1 names as a zone's Grid 1 power production capacity.
</ParamField>

<ParamField body="transmission constraints" type="Grid 1 constraint" required>
Local and regional transmission limits the transmission owner MUST provision. These are the bounds Member Elements in the domain cannot exceed through Grid 2 allocations.
</ParamField>

<ParamField body="target reserves" type="Grid 1 constraint" required>
Reserve targets supplied by Grid 1 custodians. Federation text lists zone capacity and target reserves as the examples an Allocator uses when setting allocation decisions.
</ParamField>

The Allocator **represents** that production-capacity + transmission-constraint pair. It holds **no internal intelligence or discretion**. Given identical inputs, any conformant GCAP implementation MUST produce identical allocations.

<Note>
Which existing transmission-owner signals should feed these fields, and how to standardize them, is an open Engineering discussion. Do not invent a wire mapping; implementations consume whatever the domain's Grid 1 custodians provision until that discussion lands in the living specs.
</Note>

## Optional DLR and distribution factors

The required set is sufficient to clear. The Allocator MAY also incorporate:

| Input | Status | Source language |
|---|---|---|
| Power distribution factors | Optional | GCAP §2; Allocator "Represents" |
| Dynamics from Dynamic Line Ratings | Optional | GCAP §2; Allocator MAY use DLR "and similar sources" |

These refine how surplus network capability (headroom) is computed. They do not replace the required Grid 1 set and MUST NOT be used to invent headroom the transmission owner did not authorize.

GCAP still treats **multi-constraint (nodal) allocation versus single-zone headroom** as unspecified. Until that lands, treat optional factors as additional custodian-provisioned inputs to the same deterministic function, not as a second clearing engine.

## Other interval inputs (not custodian constraints)

Besides the Grid 1 set, each interval's GCAP input vector includes:

| Input | Direction | Role in clearing |
|---|---|---|
| Member Service Descriptors | Member → Allocator (G2P §3.1) | In-zone requests and offers: Use consume positions, Buffer charge/discharge, Source supply |
| Peer-Allocator announcements | Allocator ↔ Allocator (G2P §3.3) | Coupled-boundary quantities; MAY add boundary headroom |

Member Descriptors do not loosen Grid 1 limits. They only state what Members request or offer inside those limits.

## Peer announcements must not relax local limits

Federation is announce-and-listen. Domains do not command one another.

Normative rules (`architecture/federation.md`, GCAP §2):

1. Clear **only** against this domain's Grid 1-provisioned constraints.
2. Carry Federation Announcements on G2P. Each announcement MUST identify the **announcing domain**, **interval**, and **coupled-boundary quantities**. Message schema is still to be specified in G2P.
3. If required peer announcements for a coupled boundary are missing, clear **conservatively as if the boundary contributes no additional headroom**.
4. Partition between peer Allocators MUST NOT prevent **local** clearing and MUST NOT trigger member fallback in unaffected domains.

<Info>
Missing peer data is a **no extra headroom** condition, not a withhold-clearing condition. Stale **local Grid 1 constraint inputs** are the withhold-clearing condition (below).
</Info>

Announcement *content* (boundary headroom only versus per-class aggregates) and inter-domain import policy remain open. Until specified, treat imported quantities as optional additive headroom that is discarded when absent and that cannot raise any locally provisioned limit.

## Input digests and clearing-inputs version

Deterministic clearing is auditable only if parties can name the input vector:

| Surface | Requirement |
|---|---|
| GCAP §5 | Allocators SHOULD publish, **within the domain**, the **input digest** each Commitment was computed against |
| G2P §3.2 Commitment | MUST identify the **interval**, the **domain**, and the **clearing inputs version** they were computed against |

`members/allocator.md` still lists "publication of clearing inputs digest for reproducibility" as an open item. Implement the GCAP SHOULD and the G2P MUST now; hash algorithm, canonical serialization, and publication channel are not specified.

Any party holding the same inputs MUST be able to reproduce the same allocations. The digest / inputs version is how Members and auditors bind a Commitment to that vector.

## Stale, invalid, or missing constraint inputs

| Condition | Allocator | Members |
|---|---|---|
| Stale Grid 1 constraint inputs | MUST NOT clear (withhold) | Detect missed Commitment; fall back |
| Domain partition (Allocator isolated from its constraint feed) | MUST NOT clear | Same |
| Invalid clearing inputs (G2P §5) | MUST trigger failsafe | Element-specific fallback |
| Missing required peer announcement | Still clears, with zero extra boundary headroom | Continue if a fresh Commitment arrives |
| Grid 1 dispatch instruction conflicts with a Grid 2 allocation | Grid 1 instruction **prevails** | Self-dispatch under the Grid 1 instruction |

Fallback is Grid 1 baseline (Use firm load limit or manual curtailment; Buffer standalone Grid 1 schedule; Source interconnection baseline), along allowed ramp rates. Quantitative staleness timers are still open in G2P.

The participating pool MUST be sized so simultaneous fallback stays inside manageable Grid 1 aggregate ramp limits. That bound is a provisioning input to domain growth, not a GCAP output.

## Provisioning sequence

<Steps>
<Step title="Identify the Allocation Domain">
Name the constraint scope the Allocator will clear: a local congestion zone, a utility / balancing-authority domain, or a regional RTO/ISO domain. Bind every Member and Allocator element identifier to a physical point of interconnection inside that provisioned domain (G2P §2).
</Step>
<Step title="Provision the required Grid 1 set">
The transmission owner supplies zone power production capacity, transmission constraints, and target reserves. A regional system operator MAY add capacity constraints to a regional Allocator. Host the Allocator under utility authority (utility-operated versus third-party hosting is still open).
</Step>
<Step title="Attach optional DLR and distribution factors">
If the custodian already publishes DLR dynamics or power distribution factors, feed them as optional GCAP inputs. Do not treat them as a license to exceed the required Grid 1 set.
</Step>
<Step title="Configure peer listen without override">
Subscribe to G2P Federation Announcements for coupled boundaries. On a missing required announcement, add **no** boundary headroom. Never let a peer quantity raise a local limit.
</Step>
<Step title="Publish digest and withhold on stale local inputs">
Stamp each Commitment with interval, domain, and clearing-inputs version. Publish the in-domain input digest (GCAP SHOULD). If local constraint inputs are stale or invalid, withhold clearing for that interval.
</Step>
</Steps>

Verification signals:

- Same input vector → same per-class commit-%, Buffer committed dispatch, and Source committed take.
- Injected peer headroom never increases any locally provisioned limit.
- Dropping a required peer announcement reduces (or leaves unchanged) available headroom; it does not stop local clearing.
- Dropping or aging local Grid 1 constraint inputs stops clearing; Members revert to Grid 1 baseline.

## Still unspecified

`specs/` and `members/` are **26.0-draft** / **Draft — seeking input**. These items are explicitly open around this surface:

| Item | Where tracked |
|---|---|
| Standardization of transmission-owner input signals | Allocator open items; CONTRIBUTING Engineering; RFC #1 Engineering questions |
| Digest publication mechanics | Allocator open items; GCAP SHOULD without a schema |
| Federation announcement schema and whether content is boundary headroom only or per-class aggregates | G2P §3.3; federation open items |
| Machine-readable domain descriptor (constraint scope, class policy, ramp limits) | Allocation-domains open items |
| Multi-constraint (nodal) allocation vs single-zone headroom | GCAP §7 |
| Allocator redundancy (active/standby) and operational hosting | Allocator open items |
| Quantitative staleness thresholds | Failsafe model; G2P timing |

Raise Engineering Discussions for input-signal standardization. File Issues for contradictions or missing MUST/SHOULD text. Change the living files under `specs/`, `members/`, and `architecture/` — not `rfcs/grid-2-rfc-1.pdf`.

## Next

<CardGroup>
<Card title="Allocation domains" href="/allocation-domains">
Nested domains, transmission-owner authority, and membership by spec compliance.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing, federation announce-and-listen, withhold-on-stale, pool ramp sizing.
</Card>
<Card title="GCAP reference" href="/gcap-reference">
Full input vector, headroom-then-buffers-then-C-B-A curtailment, identical-input determinism.
</Card>
<Card title="Federation" href="/federation">
Conservative missing-announcement clearing and partition that does not trip unrelated members.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Interval-only commitments and locally determinable Grid 1 fallback.
</Card>
<Card title="G2P reference" href="/g2p-reference">
Commitment clearing-inputs version, Federation Announcement fields, stale-commitment faults.
</Card>
</CardGroup>

---

## 13. Comment, review, and file errata

> Discussions versus Issues versus PRs, RFC #1 errata label, two-editor review, RFC 2119 and compatibility statements, and decision-log recording.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/13-comment-review-and-file-errata.md
- Generated: 2026-08-17T18:28:29.201Z

### Source Files

- `CONTRIBUTING.md`
- `GOVERNANCE.md`
- `rfcs/README.md`
- `README.md`
- `NOTICE.md`

---
title: "Comment, review, and file errata"
description: "Discussions versus Issues versus PRs, RFC #1 errata label, two-editor review, RFC 2119 and compatibility statements, and decision-log recording."
---

Commenting on Grid 2 happens in this repository through the `CONTRIBUTING.md` comment cycle: GitHub Discussions for open questions and alternatives, Issues for concrete defects (including RFC #1 errata), and pull requests against `specs/`, `members/`, and `architecture/`. RFCs under `rfcs/` are never edited after publication. The only published RFC is `rfcs/grid-2-rfc-1.pdf` (RFC #1, August 2026).

<Info>
Participation is open to individuals. Organizational affiliation confers no extra standing. Submitting an Issue, Discussion post, or PR licenses specification text under CC BY 4.0 (`NOTICE.md`) and may be incorporated into G2TF publications with attribution.
</Info>

## Choose a channel

| Channel | Use for | Do not use for |
|---|---|---|
| GitHub Discussions | Technical questions, design alternatives, implementation reports (Phase 0 shadow mode and later) | Filing a concrete defect or proposing replaceable spec text |
| Issues | Ambiguities, contradictions, missing normative requirements, errata against RFC #1 | Open design exploration |
| Pull requests | Proposed text against `specs/`, `members/`, or `architecture/` | Patching `rfcs/` |
| G2TF WhatsApp Community | Cross-organization news and policy debate | Normative decisions or archival rationale |

```mermaid
flowchart TD
  intent["Incoming comment"] --> q{"What is it?"}
  q -->|"Question, alternative, or implementation report"| disc["GitHub Discussions"]
  q -->|"Defect, contradiction, or missing MUST"| issue["GitHub Issue"]
  q -->|"Replacement spec text"| pr["Pull request"]
  q -->|"News or policy debate"| wa["WhatsApp Community"]
  issue --> errata{"Against RFC #1?"}
  errata -->|Yes| label["Label errata"]
  errata -->|No| living["Track against living file"]
  disc --> consensus["Editor summarizes rough consensus"]
  consensus --> pr
  label --> pr
  living --> pr
  pr --> review["Two spec-editor reviews"]
  review --> log["Decision log in GOVERNANCE.md"]
```

Living files stay the correction surface. `rfcs/README.md` states RFCs are immutable archival publications; corrections are Issues labeled `errata` and resolved in the living specs.

## Discussion categories

Discussions are organized around the technical open-question areas called out in RFC #1:

| Category | Scope in this repo |
|---|---|
| **Commercial terms** | Enforcement of flexible capabilities, limits on differential service classes, congestion-solving investment, rate-structure impacts. Specs point here (for example DESP class-policy limits stay in the domain agreement). |
| **Reliability assurance** | Coincidental load shedding, materialization of flexibility commitments at scale, compliance incentives. Failsafe open items (coincidental-fallback stability) point here. |
| **Engineering** | Headroom for coincident swings, cybersecurity / NERC CIP, standardization of transmission-owner input signals. G2P security and intra-interval timing open items point here. |

Alignment work with IEEE 2030.5 and related standards is also tracked in Discussions (`GOVERNANCE.md`). Spec files already mark open items with `*(Open: …)*` or `Discussion: …`; file those as Discussions, not as errata.

## File RFC #1 errata

RFC #1 is `rfcs/grid-2-rfc-1.pdf`. The PDF is not revised. The `errata` label is the only issue label defined in this repository.

<Steps>
  <Step title="Confirm it is errata, not a design change">
    Use `errata` when RFC #1 is wrong, internally inconsistent, or contradicts a living file that already captures the intended rule. Use a Discussion when RFC #1 left a question open (naming, timing budget, class policy, CIP mapping).
  </Step>
  <Step title="Open an Issue labeled errata">
    State the RFC section or figure, quote the incorrect or ambiguous sentence, and name the living file that should absorb the fix (`specs/g2p/spec.md`, `specs/gcap/spec.md`, `specs/desp/spec.md`, a file under `members/`, or `architecture/`).
  </Step>
  <Step title="Resolve in living specs, not in rfcs/">
    Open a PR against the living file. Do not submit a PDF or `rfcs/` patch. After merge, the RFC stays as published; implementers follow the living text.
  </Step>
</Steps>

<Warning>
There is no in-repo issue template and no other documented label set. Do not invent labels. If the defect is only in a living Draft file and does not claim RFC #1 is wrong, skip `errata` and file a normal Issue.
</Warning>

## Comment cycle

<Steps>
  <Step title="Raise">
    Open a Discussion (question or alternative) or an Issue (defect). Implementation experience from Phase 0 shadow mode and later also starts as a Discussion.
  </Step>
  <Step title="Converge">
    Editors summarize positions. When a direction has rough consensus, an editor or the proposer opens a PR with spec text.
  </Step>
  <Step title="Review">
    PRs against normative documents require review by **two spec editors**. Normative changes MUST use RFC 2119 keywords and MUST state compatibility impact.
  </Step>
  <Step title="Record">
    Merged decisions are logged in the `GOVERNANCE.md` decision log with a one-paragraph rationale and links to the originating thread. The responsible editor judges rough consensus; there is no vote.
  </Step>
  <Step title="Run">
    Implementations report experience back via Discussions. Running code informs the next revision.
  </Step>
</Steps>

Each normative document lists editors in its header. Current headers still read **Editors:** `TBD`. Until named editors appear, treat two-editor review as a merge gate on the PR, not as a named-person roster.

## Normative PR requirements

### What is normative

| Path | Status today | Keywords |
|---|---|---|
| `specs/g2p/spec.md`, `specs/gcap/spec.md`, `specs/desp/spec.md` | `Status: Draft — seeking input`, `Version: 26.0-draft` | RFC 2119 / RFC 8174 apply |
| `members/use.md`, `members/buffer.md`, `members/source.md`, `members/allocator.md` | `Status: Draft — seeking input` | RFC 2119 / RFC 8174 apply |
| `architecture/` files **not** marked `Status: Informative` | `Status: Draft — seeking input` | RFC 2119 / RFC 8174 apply |
| `architecture/design-principles.md` | `Status: Informative` | Avoid RFC 2119 keywords |
| `rfcs/` | Published, immutable | Corrections via `errata` Issues only |

Normative files are those under `specs/`, `members/`, and `architecture/` that do **not** carry `Status: Informative`. Allowed status header values:

- `Status: Draft — seeking input`
- `Status: Proposed`
- `Status: Stable (vXX.Y)`

### RFC 2119

Normative PRs use only **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, and **MAY**, interpreted as in IETF RFC 2119 / RFC 8174. Living specs already open with:

```text
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119 / RFC 8174.
```

Informative documents must not introduce those keywords as requirements.

### Compatibility statement

Every normative PR states its compatibility impact in the PR description. `GOVERNANCE.md` additionally requires a compatibility statement for changes to **Stable** documents (`Status: Stable (vXX.Y)`). Protocols version independently on a **YY.N** line (current line **26.x**; first 2026 release is `26.0`). The README compatibility matrix is not published yet; until it exists, the PR statement is the only required impact record.

At Draft seeking-input maturity, treat the statement as an explicit claim, for example:

- No wire or semantic change (editorial, errata wording, header-only).
- Additive open-item fill that existing Draft implementations can ignore.
- Breaking change to a MUST / MUST NOT (call it out; do not silently rewrite).

### Reviewable diffs

Prefer one sentence per line for new or substantially revised normative text. That is a review convention, not a protocol rule.

## Decision log

The log lives in `GOVERNANCE.md` under **Decision log**. Columns:

| Column | Required content |
|---|---|
| Date | Month or day of the merge / publication |
| Decision | One-line outcome |
| Rationale | One paragraph; record sustained objections even when overruled |
| Thread | Link to the originating Discussion, Issue, or PR |

Current entry:

| Date | Decision | Rationale | Thread |
|---|---|---|---|
| 2026-08 | Publish RFC #1; decompose into living specs (this repo structure) | Separate immutable narrative from evolving normative text; give the community focused surfaces for comment | — |

<Note>
Rough consensus is not unanimity. The responsible editor records that objections were considered and either addressed or explicitly overruled. Overruled objections still go in the log.
</Note>

The Task Force, not individual editors, resolves cross-document conflicts, appoints editors, sets milestone dates, and approves publication of new RFCs.

## License and acknowledgment on comments

| Contribution kind | License |
|---|---|
| Specification text (Issue, Discussion, or PR) | CC BY 4.0; may be incorporated into G2TF publications |
| Code in this repository | Apache-2.0 (`LICENSE-CODE`) |

Substantive contributors are acknowledged in subsequent RFC publications, following RFC #1's acknowledgments section. Neither license grants trademark rights in "Grid 2.0"™, "G2TF"™, "G2P"™, "GCAP"™, or "DESP"™.

## Common misroutes

| Symptom | Fix |
|---|---|
| PR edits `rfcs/grid-2-rfc-1.pdf` or `rfcs/README.md` to "correct" RFC #1 | Close the PR. File an `errata` Issue and patch the living spec. |
| Discussion used for a contradiction between two MUSTS | Convert to an Issue. Discussions do not close defects. |
| Issue used for "should class count be extensible?" | Move to Discussion: Commercial terms (already flagged in DESP). |
| Normative PR with no MUST/MAY and no compatibility sentence | Request changes; two-editor review cannot complete. |
| Informative PR (`Status: Informative`) that adds MUST | Strip keywords or move the text into a normative file. |
| Merge without a decision-log row | Add the row before considering the cycle complete. |

## Next

<CardGroup>
  <Card title="Contributing" href="/contributing">
    Open individual participation, writing conventions, and Phase 0 implementation reports.
  </Card>
  <Card title="Document lifecycle" href="/document-lifecycle">
    Draft → Proposed → Stable → RFC, YY.N versions, and when a compatibility statement is mandatory.
  </Card>
  <Card title="How to read the specs" href="/how-to-read-the-specs">
    Status headers, RFC 2119 as a reader, living files versus immutable RFCs.
  </Card>
  <Card title="Governance and licenses" href="/governance">
    Editor, contributor, and Task Force roles; rough consensus; CC BY 4.0 and Apache-2.0.
  </Card>
</CardGroup>

---

## 14. G2P reference

> Element identity, four message families, one-minute timing, authenticated descriptors and commitments, stale-commitment faults, and unspecified wire format.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/14-g2p-reference.md
- Generated: 2026-08-17T18:28:57.420Z

### Source Files

- `specs/g2p/spec.md`
- `specs/gcap/spec.md`
- `specs/desp/spec.md`
- `architecture/failsafe-model.md`
- `architecture/temporal-position.md`
- `architecture/federation.md`

---
title: "G2P reference"
description: "Element identity, four message families, one-minute timing, authenticated descriptors and commitments, stale-commitment faults, and unspecified wire format."
---

`specs/g2p/spec.md` is **G2P** (Grid 2.0 Protocol) **26.0-draft**. G2P is the addressing, service-configuration, and response layer under [GCAP](/gcap-reference) and [DESP](/desp-reference). It states how Member Elements and Allocators hold identity, exchange four per-interval message families, authenticate Service Descriptors and Commitments, and treat missing or stale Commitments as failsafe faults. Wire format, encoding, element state machines, version negotiation, and conformance test vectors are **not specified**.

<Note>
**Status:** Draft — seeking input. **Editors:** TBD. RFC 2119 / RFC 8174 keywords apply. G2P versions independently on the **26.x** line. Living text lives in `specs/g2p/spec.md`; [RFC #1](https://github.com/g2tf-org/g2tf-standards/blob/main/rfcs/grid-2-rfc-1.pdf) is archival.
</Note>

## Role in the stack

G2P **carries** GCAP allocations and DESP class positions. It does **not** define clearing semantics or the class taxonomy.

| Layer | File | G2P relationship |
|---|---|---|
| DESP | `specs/desp/spec.md` | Class A / B / C positions ride in Service Descriptors |
| GCAP | `specs/gcap/spec.md` | Clearing consumes §3.1 descriptors and §3.3 announcements; publishes §3.2 Commitments |
| G2P | `specs/g2p/spec.md` | Identity, messages, interval clock, auth, staleness |
| Member behavior | `members/use.md`, `members/buffer.md`, `members/source.md`, `members/allocator.md` | Who broadcasts and who listens |

:::files
specs/g2p/spec.md
specs/gcap/spec.md
specs/desp/spec.md
members/use.md
members/buffer.md
members/source.md
members/allocator.md
architecture/temporal-position.md
architecture/failsafe-model.md
architecture/federation.md
:::

v26.0 scope is **energy in the one-minute interval** on the bulk power system. Commercial terms, prices, and Grid 1 settlements stay off the protocol.

## Element identity

Every Member Element and Allocator **MUST** hold a **stable element identifier** bound to a physical point of interconnection inside a provisioned [Allocation Domain](/allocation-domains).

<ParamField body="element identifier" type="string" required>
Stable identity of a Use, Buffer, Source, or Allocator. Bound to a physical POI in a provisioned domain. Format is **open**; the living spec recommends a domain-scoped hierarchical ID that mirrors nested constraint domains in `architecture/federation.md`.
</ParamField>

<ParamField body="Allocation Domain" type="constraint set">
Set of Member Elements cleared by a common Allocator (or Allocator hierarchy) against a common Grid 1 constraint set. Technical membership is spec compliance at a covered POI, not a registration API.
</ParamField>

There is no G2P admission message and no published machine-readable domain descriptor. Overlapping local + regional membership is an open item.

## Message families

G2P defines **four** families. All are **per-interval (one minute)** unless a later revision says otherwise. There is no encoding, framing, or transport binding.

| Family | Direction | Interval binding | Required content (normative today) |
|---|---|---|---|
| Service Descriptor | Member → Allocator | Per interval; MAY be reissued each interval | Signed positions; energy units; Use: one position per DESP class over a forward vector |
| Commitment | Allocator → Member | Coming interval only | Interval, domain, clearing-inputs version; Use `commit-%`; Buffer `committed dispatch`; Source `committed take` |
| Federation Announcement | Allocator ↔ Allocator | Per interval | Announcing domain, interval, coupled-boundary quantities |
| Response / Telemetry | Member → Allocator | Against the interval Commitment | Actual per-class dispatch for verified self-dispatch |

### Service Descriptor (Member → Allocator)

A Member's signed statement of requests/offers for a **forward time vector**.

| Member | Signed position | Sign convention |
|---|---|---|
| Use | Per-class **request to consume** | `+` consume; one signed position per DESP class |
| Buffer | **Offer to be a source or use** | `−` discharge / `+` charge; may switch role per interval |
| Source | **Offer to supply** | `−` generation available this window, over a forward vector |

<ParamField body="position" type="signed energy quantity" required>
Each position **MUST** be signed by the originating Member. Positions **MUST** be expressed as **energy within the interval** (v26.0). Classes **MAY** change per interval (DESP dynamic reclassification).
</ParamField>

<ParamField body="forward time vector" type="open">
Length, resolution, and revision rules are **not specified**.
</ParamField>

DESP notes that RFC #1 interaction-table names Firm / Semi-Firm / Flex map to classes **A / B / C**. Naming reconciliation is open. The Allocator never sees intra-facility workloads; it clears class-level positions only.

### Commitment (Allocator → Member)

GCAP outputs travel as Commitments.

<ParamField body="commit-%" type="per-class allocation" required>
Use Members. Allocator **MUST** publish in time for self-dispatch **before the interval opens**.
</ParamField>

<ParamField body="committed dispatch" type="buffer schedule" required>
Buffer Members. GCAP **MUST** clear buffers **before any load is curtailed**.
</ParamField>

<ParamField body="committed take" type="supply schedule" required>
Source Members. v26.0 supply is a **single class**; mirrored A/B/C supply is open.
</ParamField>

<ParamField body="interval" type="one-minute interval id" required>
Commitments **MUST** identify the interval they apply to. Allocations expire with that interval.
</ParamField>

<ParamField body="domain" type="Allocation Domain id" required>
Domain in which the Commitment was computed.
</ParamField>

<ParamField body="clearing inputs version" type="digest / version" required>
Version of clearing inputs the Commitment was computed against. GCAP says Allocators **SHOULD** publish that input digest in-domain for reproducibility.
</ParamField>

A Member **MUST** treat a **missing or stale** Commitment as fallback-triggering.

### Federation Announcement (Allocator ↔ Allocator)

Announce-and-listen across coupled zones. Domains do not command one another.

<ParamField body="announcing domain" type="domain id" required>
Identity of the announcing Allocator's domain.
</ParamField>

<ParamField body="interval" type="one-minute interval id" required>
Interval the announcement applies to.
</ParamField>

<ParamField body="coupled-boundary quantities" type="open schema" required>
Required on the wire conceptually; **message schema is still to be specified**. Whether content is boundary headroom only or per-class aggregates is open.
</ParamField>

Normative federation rules that G2P must carry:

- An Allocator **MUST** clear only against constraints provisioned by its own Grid 1 custodians.
- Peer announcements **MAY** add boundary headroom and **MUST NOT** relax local constraints.
- Missing required peer announcements for a coupled boundary: clear **conservatively**, as if the boundary contributes **no additional headroom**.
- Partition **MUST NOT** prevent local clearing and **MUST NOT** trip member fallback in unaffected domains.

### Response / Telemetry (Member → Allocator)

Members own **verified self-dispatch**. Each Member **MUST** report actual per-class dispatch against its Commitment so compliance is auditable and the overlay's aggregate footprint is measurable.

Open: verification granularity, metering source of truth, attestation.

## Interval exchange

```mermaid
sequenceDiagram
  autonumber
  participant Use as Use / Buffer / Source
  participant Alloc as Allocator
  participant Peer as Peer Allocator

  Note over Use,Peer: One-minute interval (commit before open)
  Use->>Alloc: Service Descriptor (signed positions)
  Peer-->>Alloc: Federation Announcement (domain, interval, boundary)
  Note over Alloc: GCAP clear (not G2P)<br/>stale local constraints → MUST NOT clear
  Alloc->>Use: Commitment (interval, domain, inputs version)
  Use->>Use: Self-dispatch before interval opens
  Use->>Alloc: Response / Telemetry (actual vs Commitment)
  Note over Use: Missing or stale Commitment → fallback
```

If Grid 1 dispatch conflicts with a Grid 2 allocation, the **Grid 1 instruction prevails**.

## Timing

All G2P messages bind to the **one-minute interval clock** in `architecture/temporal-position.md`.

| Rule | Normative text |
|---|---|
| Interval grain | Allocations **MUST** apply to whole one-minute intervals. Sub-minute response is out of scope for the orchestration plane. |
| Commit-before-open | Clearing **MUST** finish so Members receive `commit-%` (and Buffer/Source commits) with time to self-dispatch **before the interval opens**. |
| Non-interference | Elements **MUST NOT** interfere with, substitute for, or assume sub-second primary controls (governor, AGC, protection). |
| Market coexistence | Grid 2 **SHOULD** consume, not contradict, forward market-dispatch information. |

**Not specified:** descriptor deadline, clearing deadline, commitment publication deadline, clock sync, federated phase alignment (common epoch vs per-domain clocks), late-arrival and clock-skew tolerances, interaction with 15-minute settlement intervals.

## Faults and stale commitments

Allocations are valid **for their interval only**. A Member that has not received a `commit-%` (or the Buffer/Source equivalent) for the **current** interval **MUST** treat itself as in fallback.

Triggers that **MUST** invoke element-specific fallback in `architecture/failsafe-model.md`:

- Loss of connectivity
- Missed Commitments beyond the staleness threshold
- Invalid clearing inputs
- Allocator stale constraint inputs or domain partition (Allocator **MUST NOT** clear; Members detect missed clearing)

| Element | Fallback |
|---|---|
| Use | Grid 1 baseline (firm load limit) or manual curtailment; follow allowed ramp rates |
| Buffer | Standalone Grid 1 schedule; **no Grid 2 support commitment** while in fallback; follow allowed ramp rates |
| Source | Grid 1 baseline interconnection behavior; follow allowed ramp rates |
| Allocator | **MUST NOT** clear on stale inputs or partition |

Fallback **MUST** be locally determinable from the Member's own state and last-known configuration. It **MUST NOT** depend on reaching a remote peer. All transitions into/out of fallback and between interval allocations **MUST** respect ramp rates agreed with the host utility.

<Warning>
**Staleness timers are not specified.** Failsafe text assigns quantitative thresholds (missed intervals before fallback) and explicit timers to G2P. Until those land, the only specified rule is: no Commitment for the current interval → fallback now.
</Warning>

Also unspecified: re-entry / hysteresis after fallback, coincidental-fallback stability analysis, and audit/telemetry to verify fallback compliance.

## Authentication

Transmission-level deployments are expected on **private networks**.

- All **Service Descriptors** and **Commitments** **MUST** be authenticated.
- Message integrity **MUST** be verifiable end-to-end.

<ParamField body="PKI / key management" type="open">
Not specified. Tracked as Discussion: Engineering with NERC CIP mapping.
</ParamField>

<ParamField body="replay protection" type="open">
Not specified.
</ParamField>

Federation Announcement and Response / Telemetry authentication are not given a separate MUST in `specs/g2p/spec.md` §6. Do not assume they inherit the same requirement until the spec says so.

## Unspecified wire surface

G2P §7 lists work still required before an interoperable implementation can be frozen:

| Surface | Status in 26.0-draft |
|---|---|
| Wire format and encoding | Unspecified — no schema, MIME type, or binary framing |
| Transport | Unspecified — no sockets, topics, or HTTP routes |
| State machines per element | Unspecified |
| Version negotiation | Unspecified (protocols version independently; README compatibility matrix is planned, not present) |
| Conformance test vectors | Unspecified (domain certification criteria also open in `architecture/allocation-domains.md`) |

There is no code, fixture, or parser in this repository. Implementers in [Phase 0 shadow mode](/phase-0-shadow-mode) exchange and track commitments out of band while executing only the Grid 1 baseline.

## Open items (G2P-owned or G2P-adjacent)

<AccordionGroup>
<Accordion title="Identity and messages">
- Element identifier format (hierarchical domain-scoped ID recommended, not adopted)
- Forward-vector length, resolution, revision rules
- Federation announcement schema and whether it carries headroom only vs per-class aggregates
- Response verification granularity, metering source of truth, attestation
</Accordion>
<Accordion title="Timing and faults">
- Intra-interval timing budget and clock sync
- Quantitative staleness threshold and timers
- Re-entry procedure and hysteresis
- Late-arrival / clock-skew tolerances
- Interval phase alignment across federated domains
</Accordion>
<Accordion title="Security and ops">
- PKI, NERC CIP applicability, replay protection
- Allocator redundancy (active/standby)
- Hosting responsibility (utility-operated vs third-party under utility authority)
</Accordion>
</AccordionGroup>

Propose text against `specs/g2p/spec.md` via PR. Engineering-category questions (CIP, auth, TO signal standardization) go to GitHub Discussions. See [Comment, review, and file errata](/comment-and-errata).

## Next

<CardGroup>
<Card title="GCAP reference" href="/gcap-reference">
What Allocators compute from G2P descriptors and announcements, and what they put back on Commitments.
</Card>
<Card title="One-minute window" href="/one-minute-window">
Commit-before-open clock, Grid 1-prevails conflict rule, and open timing budget.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Per-element fallback, interval-only commitments, and locally determinable recovery.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing, withhold-on-stale, federation announce-and-listen.
</Card>
<Card title="Use Member" href="/use-member">
Per-class consume positions, commit-% listen, self-dispatch and telemetry MUSTs.
</Card>
<Card title="How to read the specs" href="/how-to-read-the-specs">
Draft headers, RFC 2119 keywords, living files vs RFC #1, independent 26.x lines.
</Card>
</CardGroup>

---

## 15. GCAP reference

> Clearing inputs, headroom-then-buffers-then-tiered-curtailment, per-class commit outputs, identical-input determinism, and pool and ramp-safety bounds.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/15-gcap-reference.md
- Generated: 2026-08-17T18:31:01.158Z

### Source Files

- `specs/gcap/spec.md`
- `specs/desp/spec.md`
- `specs/g2p/spec.md`
- `members/allocator.md`
- `architecture/failsafe-model.md`
- `members/buffer.md`

---
title: "GCAP reference"
description: "Clearing inputs, headroom-then-buffers-then-tiered-curtailment, per-class commit outputs, identical-input determinism, and pool and ramp-safety bounds."
---

**GCAP** (Grid Capacity Allocation Protocol), version **26.0-draft**, is the Allocator clearing specification in `specs/gcap/spec.md`. Each one-minute interval the Allocator computes per-class allocations from Member Service Descriptors and Grid 1 constraints, then publishes interval-only commitments over [G2P](/g2p-reference). Given identical inputs, any conformant implementation **MUST** produce identical allocations. The Allocator holds **no internal intelligence or discretion**; intelligence stays at the edge in Member Elements.

<Info>
Status is **Draft — seeking input**. RFC 2119 / RFC 8174 keywords in `specs/gcap/spec.md` are normative. Wire format, exact proportionality weights, and intra-interval timing budgets are not specified in v26.0-draft.
</Info>

## Stack position

GCAP is the middle protocol of the Grid 2 stack. It does not define identity, messages, or class names; it consumes them.

| Layer | Spec | GCAP relationship |
|---|---|---|
| Classes | DESP `26.0-draft` | Curtailment order **C → B → A**; Grid 1 Firm is never cut by GCAP |
| Clearing | GCAP `26.0-draft` | Deterministic allocation each interval |
| Transport | G2P `26.0-draft` | Carries Service Descriptors, Commitments, federation announcements, telemetry |

Allocations apply to **whole one-minute intervals**. Clearing **MUST** finish so Members receive `commit-%` with time to self-dispatch **before** the interval opens. Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **Grid 1 prevails**. Positions are **units of energy within the interval** (v26.0 scope).

## Inputs

Each interval the Allocator clears against exactly these three input families.

<ParamField body="Grid 1 constraints" type="custodian-provisioned set" required>
Zone power production capacity, transmission constraints, and target reserves. Optionally power distribution factors and Dynamic Line Rating dynamics. The utility transmission owner **MUST** provision local and regional constraints. A regional system operator **MAY** add capacity constraints. The Allocator **MUST NOT** clear on stale constraint inputs.
</ParamField>

<ParamField body="Member Service Descriptors" type="G2P §3.1, signed" required>
In-zone descriptors: Use per-class request to consume (`+`); Buffer offer to source or use (`−` discharge / `+` charge); Source offer to supply (`−`). Each position **MUST** be signed by the originating Member. A descriptor **MAY** be reissued each interval; DESP classes **MAY** change per interval.
</ParamField>

<ParamField body="Peer-Allocator announcements" type="G2P §3.3" required>
Announce-and-listen quantities across coupled zones. **MAY** add boundary headroom. **MUST NOT** relax local constraints. If a required peer announcement is missing, clear conservatively as if that boundary contributes **no additional headroom**. Partition from a peer **MUST NOT** block local clearing in an unaffected domain.
</ParamField>

<Warning>
Peer announcements inform local clearing; they never override constraints provisioned by the domain's own Grid 1 custodians.
</Warning>

```text
Allocator input set (interval N)
├── Grid 1 constraints          (TO required; RSO optional extras)
│   ├── zone production capacity
│   ├── transmission constraints
│   ├── target reserves
│   └── optional DLR / distribution factors
├── in-zone Service Descriptors (signed; energy in the interval)
│   ├── Use:    {A, B, C} request to consume (+)
│   ├── Buffer: charge (+) / discharge (−)
│   └── Source: offer to supply (−)
└── peer announcements          (boundary headroom only; never relax local)
```

## Clearing algorithm

The Allocator redispatches deterministically and proportionally in **strict order**. Buffers are a shock absorber, not a later residual.

```mermaid
flowchart TD
  subgraph inputs [Inputs]
    G1[Grid 1 constraints]
    SD[Service Descriptors]
    FA[Peer announcements]
  end

  stale{Stale constraints or domain partition?}

  subgraph steps [GCAP §3]
    H[1 Headroom]
    B[2 Buffer committed dispatch]
    T[3 Ramp down C then B then A]
  end

  subgraph out [Outputs]
    U[Use commit-%]
    BF[Buffer committed dispatch]
    S[Source committed take]
  end

  G1 --> stale
  SD --> stale
  FA --> stale
  stale -->|yes| W[MUST NOT clear]
  W --> FB[Members fall back to Grid 1]
  stale -->|no| H --> B --> T --> U
  T --> BF
  T --> S
```

| Step | Name | Rule |
|---|---|---|
| 1 | **Headroom first** | Compute surplus network capability (grid capacity headroom) available to the domain for the interval. |
| 2 | **Buffers second** | Clear Buffer **committed dispatch** to absorb shortfall or surplus. **Buffers are cleared before any load is curtailed.** |
| 3 | **Tiered ramp-down** | If relief is still required, reduce Use allocations by DESP class: **Best Efforts (C)**, then **Preferred (B)**, then **Assured (A)**. Never touch traditional **Firm (Grid 1)** service. |

Within a class, curtailment **MUST** be **proportional**: equitable dispatch proportional to **connection size** and **differential request size**. The exact weighting formula is an open item.

<Note>
GCAP never inspects facility-internal workloads. Use Members map jobs onto class positions at the edge; the Allocator clears class-level signed positions only.
</Note>

### Class order GCAP honors

| Class | DESP name | GCAP treatment |
|---|---|---|
| — | Traditional Firm (Grid 1) | Outside Grid 2. Never curtailed by GCAP. |
| A | Assured | Curtailed last among Grid 2 classes. |
| B | Preferred | Curtailed after C, before A. |
| C | Best Efforts | Curtailed first. |

G2P interaction-table aliases Firm / Semi-Firm / Flex map to A / B / C; naming reconciliation is open in DESP.

## Outputs

Commitments are G2P §3.2 messages. They apply to the **coming interval only** and expire with it.

<ResponseField name="commit-%" type="per class, per Use Member">
Per-class committed share of the Use Member's requested consume position. The Use Member **MUST** self-dispatch within this `commit-%` and agreed host-utility parameters.
</ResponseField>

<ResponseField name="committed dispatch" type="per Buffer">
Signed charge or discharge the Buffer **MUST** honor within agreed ramp rates. Cleared in algorithm step 2, before any Use class is cut.
</ResponseField>

<ResponseField name="committed take" type="per Source">
Supply the Source **MUST** self-dispatch to within agreed ramp rates. v26.0 treats supply as a single class.
</ResponseField>

<ResponseField name="commitment envelope" type="required G2P fields">
A Commitment **MUST** identify the **interval**, the **domain**, and the **clearing inputs version** it was computed against.
</ResponseField>

<RequestExample>
```text
G2P Service Descriptor  Member → Allocator
  element_id:  domain-scoped POI id
  interval:    one-minute forward vector
  positions:   signed energy-in-interval
    Use:    A+, B+, C+
    Buffer: charge+ or discharge−
    Source: supply−
```
</RequestExample>

<ResponseExample>
```text
G2P Commitment  Allocator → Member
  interval:          coming one-minute window
  domain:            allocation domain id
  inputs_version:    digest of the input set
  Use:               commit-% per class
  Buffer:            committed dispatch
  Source:            committed take
```
</ResponseExample>

A Member that has not received a Commitment for the current interval **MUST** treat itself as in fallback.

## Determinism and verifiability

| Rule | Normative text |
|---|---|
| Identical inputs | Any conformant implementation **MUST** produce identical allocations. |
| No discretion | The Allocator **MUST NOT** apply internal intelligence or operator judgment. |
| Reproducibility | Any party holding the same inputs **MUST** be able to reproduce the computation. |
| Input digest | Allocators **SHOULD** publish, within the domain, the input digest each Commitment was computed against. |
| Stale inputs | The Allocator **MUST NOT** clear on stale constraint inputs. |

Publication of that digest is listed as an Allocator open item; G2P already requires Commitments to carry the clearing-inputs version.

## Pool and ramp safety

GCAP bounds both **who may be in the pool** and **how far one interval may move a member**.

- The Allocator **MUST** bound total cleared participation so that **simultaneous member fallback** stays within manageable aggregate ramp limits for the domain. Failsafe-model language: the total participating pool **MUST** be sized so whole-pool fallback produces aggregate ramps within manageable Grid 1 system ramp limits. That bound is the binding constraint on domain growth; sizing methodology is open.
- Per-member allocation **deltas between consecutive intervals MUST** respect each member's agreed ramp rates.
- All transitions — into fallback, out of fallback, and between interval allocations — **MUST** respect ramp rates agreed with the host utility.

## Failsafe and withhold

On **stale constraint inputs** or **domain partition**, the Allocator **MUST withhold clearing**. Members detecting a missed or stale Commitment fall back locally. Fallback **MUST** be determinable from the Member's own state and last-known configuration; it **MUST NOT** depend on reaching a remote peer.

| Element | Fallback when GCAP does not commit |
|---|---|
| Use | Grid 1 baseline (firm load limit) or manual curtailment; follow allowed ramps. |
| Buffer | Standalone Grid 1 schedule; **no Grid 2 support commitment** while in fallback. |
| Source | Grid 1 baseline interconnection behavior; follow allowed ramps. |
| Allocator | **MUST NOT** clear. |

<Warning>
Missing peer announcements are not the same as domain partition. Conservative local clearing (zero extra boundary headroom) continues. Only stale **local** constraint inputs or partition of the **local** domain withhold the entire clear.
</Warning>

## Open items in v26.0-draft

These affect implementers; they are not implied defaults.

<AccordionGroup>
<Accordion title="Proportionality and load shape">
Exact connection-size vs. request-size weights; treatment of indivisible loads; multi-constraint (nodal) allocation vs. single-zone headroom.
</Accordion>
<Accordion title="Cross-interval fairness">
Whether deferred Class C accrues priority in later intervals.
</Accordion>
<Accordion title="Markets and mid-interval dispatch">
Interaction with market dispatch instructions that arrive mid-interval. Grid 1 still prevails on conflict.
</Accordion>
<Accordion title="Buffers">
How much state-of-charge the Allocator needs for step 2; priority among multiple Buffers (proportional vs. merit order by round-trip efficiency).
</Accordion>
<Accordion title="Sources">
How forecast error interacts with headroom; whether curtailed Source energy can move to a co-located Buffer in the same interval.
</Accordion>
<Accordion title="Operations">
Allocator redundancy (active/standby); who hosts the Allocator; digest publication practice.
</Accordion>
</AccordionGroup>

## Related pages

<CardGroup>
<Card title="Allocator" href="/allocator">
No-discretion execution of this algorithm, constraint-authority inputs, withhold-on-stale, and whole-pool ramp sizing.
</Card>
<Card title="DESP reference" href="/desp-reference">
Class table, mandatory C-B-A order, and domain class-policy limits GCAP consumes.
</Card>
<Card title="G2P reference" href="/g2p-reference">
Service Descriptor, Commitment, federation announcement, and telemetry families that carry GCAP I/O.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Interval-only commitments, locally determinable fallback, and pool ramp limits.
</Card>
<Card title="Provision constraint inputs" href="/provision-constraint-inputs">
Required Grid 1 set, optional DLR and distribution factors, and the no-relax-from-peers rule.
</Card>
<Card title="Buffer Member" href="/buffer-member">
Signed charge/discharge offers and step-2 committed dispatch before any load curtailment.
</Card>
</CardGroup>

---

## 16. DESP reference

> Class table and semantics, mandatory C-B-A curtailment order, domain class-policy limits, and open naming, extensibility, and SLA items.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/16-desp-reference.md
- Generated: 2026-08-17T18:31:16.134Z

### Source Files

- `specs/desp/spec.md`
- `specs/gcap/spec.md`
- `specs/g2p/spec.md`
- `members/use.md`
- `rfcs/grid-2-rfc-1.pdf`

---
title: "DESP reference"
description: "Class table and semantics, mandatory C-B-A curtailment order, domain class-policy limits, and open naming, extensibility, and SLA items."
---

`specs/desp/spec.md` is the living **DESP** (Differential Electric Service Protocol) document: version **26.0-draft**, status **Draft — seeking input**. DESP owns the non-firm service-class taxonomy and the priority order Allocators MUST honor when constraints bind. GCAP clears against those classes; G2P carries them in Service Descriptors and Commitments. DESP does not define a wire format, prices, or commercial terms.

<Info>
RFC 2119 / RFC 8174 keywords apply. Editors are TBD. DESP versions independently of G2P and GCAP on the **26.x** line. RFC #1 is the immutable August 2026 snapshot; class-table changes land here, not in the PDF.
</Info>

## Status and stack role

| Field | Value |
|---|---|
| Path | `specs/desp/spec.md` |
| Version | `26.0-draft` |
| Status | Draft — seeking input |
| Role | Service classification and prioritization |
| Consumers | GCAP clearing; G2P Use Service Descriptors and per-class `commit-%` |
| Clock | One-minute interval; a Member MAY reclassify request buckets each interval |
| v26.0 units | Energy within the interval (same scope as G2P/GCAP) |

DESP classes apply to **Use** demand above Grid 1 Firm. Buffer offers and Source supply are not A/B/C in v26.0; Source class structure (single class vs. mirrored A/B/C) is an open item.

## Service classes

Grid 2 stratifies demand **above** traditional Grid 1 firm service. Classes **A**, **B**, and **C** together are traditional non-firm demand (RFC #1 Figure 2). GCAP MUST NOT curtail Traditional Firm.

| Class | Name | Position | Semantics |
|---|---|---|---|
| — | Traditional Firm (Grid 1) | Base | Outside Grid 2; served per existing firm service. Never curtailed by GCAP. |
| `A` | Assured | Highest non-firm | Curtailed last among Grid 2 classes. Intended for latency-sensitive, hard-to-defer demand. |
| `B` | Preferred | Middle | Curtailed after `C`, before `A`. Deferrable-with-constraints demand. |
| `C` | Best Efforts | Lowest | Curtailed first. Unmet or deferred most frequently; statistical-multiplexing tier. |

<ParamField body="A" type="class" required>
Assured. Highest non-firm priority. Alias in the RFC #1 interaction table: Firm.
</ParamField>

<ParamField body="B" type="class" required>
Preferred. Middle non-firm priority. Alias: Semi-Firm.
</ParamField>

<ParamField body="C" type="class" required>
Best Efforts. Lowest non-firm priority. Alias: Flex.
</ParamField>

```text
 unmet / deferred  (headroom shortfall)
 ┌─────────────────────────────────────┐
 │  C  Best Efforts                    │  curtailed first
 │  B  Preferred                       │
 │  A  Assured                         │  curtailed last among Grid 2
 └─────────────────────────────────────┘
    Grid 2 non-firm (DESP)
 ───────────────────────────────────────
    Traditional Firm (Grid 1)          never touched by GCAP
```

### Naming aliases

G2P Service Descriptors carry **one signed position per class**. The RFC #1 Protocol Interactions table names those positions **Firm / Semi-Firm / Flex**. The living spec maps that triple onto **A / B / C**. Reconciliation of Assured/Preferred/Best-Efforts vs. Firm/Semi-Firm/Flex is an open item — do not treat either set as the sole on-the-wire identifier until that lands.

RFC #1 Figure 5 labels DESP “dynamic request classification standard (can change each interval)” and shows per-Use buckets such as Best Efforts (C), Preferred (B), Assured (A), plus a separate Firm row that stays on Grid 1.

## Curtailment order

When constraints bind, Allocators MUST honor this order. GCAP §3 and `members/allocator.md` restate it; DESP is the class-order authority.

1. **Headroom first** — compute surplus network capability for the interval.
2. **Buffers second** — clear Buffer **committed dispatch** before **any** Use class is curtailed.
3. **Tiered Use third** — if relief is still required, reduce Use allocations **C → B → A**.
4. **Never Firm** — Traditional Firm (Grid 1) is outside this loop.

```mermaid
flowchart TD
  subgraph gcap["GCAP interval clear"]
    H[Headroom]
    BUF[Buffer committed dispatch]
    C[Best Efforts C]
    B[Preferred B]
    A[Assured A]
    H --> BUF
    BUF -->|still constrained| C
    C -->|still constrained| B
    B -->|still constrained| A
  end
  subgraph protected["Outside DESP / GCAP"]
    FIRM[Traditional Firm Grid 1]
  end
  A -.->|MUST NOT touch| FIRM
```

Within a class, curtailment MUST be **proportional**: equitable dispatch proportional to connection size and differential request size (GCAP §3). The exact weighting formula is a GCAP open item, not a DESP one.

<Warning>
Buffer dispatch is not a DESP class. Treating storage as Class A/B/C, or curtailing Use before committed Buffer dispatch, is non-conformant.
</Warning>

## Dynamic reclassification

Classification is **dynamic**:

- A Member MAY reclassify its request buckets **each interval**.
- A G2P Service Descriptor MAY be reissued each interval; classes MAY change with it.
- Positions MUST be signed by the originating Member and expressed in energy within the interval (v26.0).
- The Allocator clears **class-level positions only**. It never sees or directs internal workloads.

Use Members listen for per-class **commit-%** for the coming interval and MUST self-dispatch within that commit-%, within host-utility parameters, and MUST report actual per-class dispatch (G2P §3.4). On a missing or stale Commitment they revert to the Grid 1 firm load limit or manual curtailment — not to a DESP class.

## Domain class policy

A domain MAY constrain the mix of classes a Member can declare (example in the spec: a minimum Class C share for expedited interconnection). Those limits are **commercial-terms matters** in the domain agreement, not protocol fields.

| Surface | What it may do | What it MUST NOT do |
|---|---|---|
| Domain agreement | Cap or floor declared class mix; charge for Grid 2-enabled use; enforce flex capabilities | Change C → B → A order or let GCAP curtail Firm |
| DESP | Define A/B/C semantics and mandatory curtailment order | Encode tariffs, interconnection queues, or SLA envelopes (those are open) |
| Machine-readable domain descriptor | Proposed open item: constraint scope, class policy, ramp limits | Not specified in v26.0-draft |

RFC #1’s Commercial terms discussion asks whether the **standard** should provide guidance or limits on differential service classes. Until that closes, implementers treat mix limits as domain-local and keep GCAP order global.

## Informative workload mapping

DESP §3 is **informative**, not a conformance test. It aligns classes with Emerald AI Flex 0/1/2/3 and ERCOT CLR/PCLR constructs. Facility-type mapping guidance remains an open Use-Member item.

| Class | Informative analog | Typical demand | Flexibility notes in spec |
|---|---|---|---|
| `A` | ≈ Flex 0; ERCOT LPC-aligned firm portion | Real-time inference, interactive services | Sub-second SLAs; flex via spatial routing, cooling, behind-the-meter storage, bounded power-capping (~20% headroom on inference without deferring requests) |
| `B` | ≈ Flex 1–2; CLR/PCLR dispatchable portion | Training with checkpointing, deadline batch | Minutes-to-hours deferral; 10–25% throttle sustained 3–6 h cited as field-proven; primary flex reservoir |
| `C` | ≈ Flex 3 | Opportunistic/spot compute, non-urgent batch | Pausable hours-to-days; shed first |

Empirical anchors cited in DESP (and RFC #1 Industry Analysis): 25% sustained facility power reduction for 3 hours in production (Emerald AI, 256 GPUs, 15-minute ramps); curtailing 0.25–1.0% of annual load unlocking 76–126 GW of US headroom (Duke, *Rethinking Load Growth*). Those figures inform class design; they are not protocol SLAs.

## Carriage and outputs

DESP has no messages of its own. Adjacent contracts:

| Direction | Message | DESP-related content |
|---|---|---|
| Use → Allocator | G2P Service Descriptor | One signed **request to consume** (+) per class over a forward time vector |
| Allocator → Use | G2P Commitment | Per-class **commit-%**; identifies interval, domain, and clearing-inputs version |
| Use → Allocator | G2P Response / Telemetry | Actual per-class dispatch vs. Commitment |
| Allocator → Buffer / Source | G2P Commitment | **Committed dispatch** / **committed take** — not classed A/B/C in v26.0 |

Federation announcements MAY later carry per-class aggregates; whether they carry boundary headroom only or per-class totals is an open federation item. Missing peer announcements MUST NOT relax local limits.

## Open items

Tracked in DESP §5 unless noted:

| Item | Status |
|---|---|
| Naming: Assured/Preferred/Best-Efforts vs. Firm/Semi-Firm/Flex | Open |
| Class count fixed at three vs. extensible per domain | Open |
| Per-class performance envelopes (target unmet-frequency, SLA-like) | Open |
| Ramp-rate and snap-back limits per class (research cited: 15-minute ramp discipline) | Open; agreed host-utility ramps already MUST bind transitions |
| Enforcement/verification of declared class behavior | Open; ties to G2P §3.4 verified self-dispatch |
| Standard should publish class-mix guidance or limits | Open (RFC #1 Commercial terms) |
| Machine-readable domain descriptor including class policy | Open (`architecture/allocation-domains.md`) |
| Deferred Class C accruing priority across intervals | Open (GCAP) |
| Source supply class structure in v26.0 | Open (`members/source.md`: single class vs. mirrored A/B/C) |
| Per-facility-type workload→class guidance | Open (`members/use.md`) |

<Note>
Do not implement extra classes, per-class SLAs, or on-the-wire Firm/Semi-Firm/Flex tokens as if they were Stable. Comment via Discussions (Commercial terms for mix limits; Engineering for verification) or a PR against `specs/desp/spec.md`.
</Note>

## Related pages

<CardGroup>
  <Card title="Service classes" href="/service-classes">
    Conceptual A/B/C stack, Firm aliases, and per-interval reclassification.
  </Card>
  <Card title="Map workloads to classes" href="/map-workloads-to-classes">
    Informative Flex 0–3 and ERCOT CLR/PCLR mappings; what the Allocator never sees.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Headroom, then Buffers, then C-B-A; proportional within class.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Signed per-class descriptors, commit-%, and verified self-dispatch.
  </Card>
  <Card title="Use Member" href="/use-member">
    Per-class consume positions, commit-% listen, and firm-limit fallback.
  </Card>
  <Card title="Allocation domains" href="/allocation-domains">
    Class-mix limits stay in the domain agreement, not in DESP.
  </Card>
</CardGroup>

---

## 17. Use Member

> Per-class consume positions, commit-% listen, edge workload mapping, self-dispatch and telemetry MUSTS, ramp limits, and firm-limit fallback.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/17-use-member.md
- Generated: 2026-08-17T18:31:03.052Z

### Source Files

- `members/use.md`
- `specs/g2p/spec.md`
- `specs/desp/spec.md`
- `architecture/failsafe-model.md`
- `specs/gcap/spec.md`

---
title: "Use Member"
description: "Per-class consume positions, commit-% listen, edge workload mapping, self-dispatch and telemetry MUSTS, ramp limits, and firm-limit fallback."
---

A **Use Member** is the Grid 2 Member Element for a flexible large load. The living behavioral contract is `members/use.md` (**Status:** Draft — seeking input). Each one-minute interval the Member broadcasts a signed per-class **request to consume** (`+`) on G2P, listens for its Allocator’s per-class **commit-%**, self-dispatches within that commit-% and host-utility ramp limits, and reports **verified self-dispatch**. A missing or stale Commitment forces revert to the Grid 1 **firm load limit** or manual curtailment.

<Note>
`members/use.md`, G2P **26.0-draft**, DESP **26.0-draft**, and GCAP **26.0-draft** are living Draft files seeking input. RFC 2119 / RFC 8174 keywords in those files are normative. G2P does not yet specify wire format, encoding, per-element state machines, or conformance test vectors.
</Note>

## Status and stack position

| Surface | Role for Use |
|---|---|
| `members/use.md` | Behavioral MUST/MAY contract for the load Member |
| G2P §3.1 / §3.2 / §3.4 | Service Descriptor, Commitment, Response / Telemetry |
| DESP | Classes **A / B / C**, dynamic reclassification, C→B→A curtailment |
| GCAP | Deterministic per-class **commit-%**; headroom, then Buffers, then Use curtailment |
| Failsafe model | Firm-limit / manual-curtailment fallback when context is stale |

Use is one of three Member kinds (Use, Buffer, Source). Membership is spec compliance at a point of interconnection covered by a provisioned Allocation Domain, under commercial terms with the host utility. The smallest domain is a host utility plus a single flexible load.

Every Use Member MUST hold a stable element identifier bound to that physical point of interconnection. Identifier format is open (G2P recommends a domain-scoped hierarchical ID). v26.0 positions are **energy within the one-minute interval** on the bulk power system.

## Associated physical asset

Flexible large load: capable datacenter sites (any mix of flex-capable load and/or on-site power resources) and electrified industry.

Internal facility assets — GPUs, cooling, behind-the-meter storage, process lines — stay behind the Member. The Allocator never sees or directs those workloads; it clears **class-level positions only**.

## Interval contract

Grid 2 allocations apply to whole one-minute intervals. Clearing MUST finish so the Member receives **commit-%** with time to self-dispatch **before the interval opens**. Exact descriptor / clearing / publication deadlines and clock-sync rules are open in G2P.

Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **the Grid 1 instruction prevails**. Sub-minute primary controls (governor, AGC, protection) stay out of scope for the orchestration plane.

```mermaid
sequenceDiagram
  participant Use as Use Member
  participant Alloc as Allocator
  Note over Use,Alloc: One-minute interval (commit before open)
  Use->>Alloc: Service Descriptor — per-class request to consume (+)
  Note over Alloc: GCAP: headroom → Buffers → C then B then A
  Alloc-->>Use: Commitment — per-class commit-%, interval, domain, inputs version
  Use->>Use: Self-dispatch within commit-% and agreed ramps
  Use->>Alloc: Response / Telemetry — actual per-class dispatch
  alt Missing or stale Commitment
    Use->>Use: Fallback — Grid 1 firm load limit or manual curtailment
  end
```

### Broadcasts (G2P Service Descriptor)

<ParamField body="request to consume" type="signed position per DESP class" required>
One `+` consume position per service class over a forward time vector. Each position MUST be signed by the originating Member. Positions MUST be energy in the interval (v26.0).
</ParamField>

<ParamField body="class set" type="A | B | C" required>
DESP **Assured (A)**, **Preferred (B)**, **Best Efforts (C)**. G2P interaction-table names Firm / Semi-Firm / Flex map to A / B / C; naming reconciliation is an open item.
</ParamField>

<ParamField body="forward time vector" type="open" required>
Descriptor covers a forward vector. Length, resolution, and revision rules are unspecified.
</ParamField>

A Service Descriptor MAY be reissued each interval. Positions MAY be reclassified each interval (DESP dynamic classification). All Service Descriptors MUST be authenticated; integrity MUST be verifiable end-to-end.

### Listens (G2P Commitment)

<ResponseField name="commit-%" type="per-class percentage">
Allocator output to each Use Member for the **coming interval only**. Allocations expire with the interval.
</ResponseField>

<ResponseField name="interval">
Interval the Commitment applies to. MUST be present.
</ResponseField>

<ResponseField name="domain">
Allocation Domain the Commitment was computed in. MUST be present.
</ResponseField>

<ResponseField name="clearing inputs version">
Input digest / version the Allocator cleared against. MUST be present. Allocators SHOULD publish the digest in-domain.
</ResponseField>

A Member MUST treat a **missing or stale** Commitment as fallback-triggering. A Member that has not received a commit-% for the **current** interval MUST treat itself as in fallback. Explicit staleness timers remain open in G2P.

### Reports (G2P Response / Telemetry)

Each Member MUST report **actual per-class dispatch against its Commitment** so compliance is auditable and the overlay’s aggregate footprint is measurable. Verification granularity, metering source of truth, and attestation are open.

## Edge workload mapping

The Use Member owns all operational decisions:

- How to map internal workloads onto DESP classes
- Which demand is deferrable, and when
- Anticipating its own forward load

This is the **scale without singular operator** rule: every asset runs the same algorithm against the same observable signals. The Allocator holds no internal intelligence or discretion.

DESP §3 mapping is **informative only** (Emerald AI Flex 0/1/2/3 and ERCOT CLR/PCLR constructs). Standard per-facility-type guidance is an open item on `members/use.md`.

| DESP class | Informative workload hint | Curtailment rank |
|---|---|---|
| Traditional Firm (Grid 1) | Outside Grid 2; never curtailed by GCAP | Not a Grid 2 class |
| **A** Assured | ≈ Flex 0 / LPC-aligned firm portion; latency-sensitive inference | Last among Grid 2 |
| **B** Preferred | ≈ Flex 1–2 / CLR-PCLR dispatchable; checkpointed training, deadline batch | After C, before A |
| **C** Best Efforts | ≈ Flex 3; opportunistic / spot compute | First |

A domain MAY constrain the mix of classes a Member can declare (for example a minimum Class C share). Those limits are **commercial-terms** in the domain agreement, not protocol fields.

When constraints bind, GCAP reduces Use allocations in DESP order **C → B → A**, never touching Grid 1 Firm. **Buffer committed dispatch clears before any Use class is curtailed.** Within a class, curtailment MUST be proportional (connection size and differential request size). The exact proportionality formula is open.

## Self-dispatch and telemetry MUSTS

<Steps>
<Step title="Issue the descriptor">
Sign and send one consume position per class for the forward vector before the (still unspecified) descriptor deadline.
</Step>
<Step title="Wait for commit-%">
Accept only an authenticated Commitment that names this interval, this domain, and a clearing-inputs version. If it does not arrive, or is stale, enter fallback — do not invent a commit-%.
</Step>
<Step title="Self-dispatch">
MUST self-dispatch **within** the per-class commit-% for the interval, within parameters agreed with the host utility. MUST respect agreed ramp rates on every transition (interval-to-interval, into fallback, out of fallback).
</Step>
<Step title="Report verified self-dispatch">
MUST report actual per-class dispatch against the Commitment (G2P §3.4). Grid 1 verifies the overlay by aggregate footprint, not by inspecting facility internals.
</Step>
</Steps>

<Warning>
Do not treat unused requested-and-committed energy as automatically returned to the pool mid-interval. Whether undershoot recycles mid-interval is an explicit open item on `members/use.md`.
</Warning>

## Ramp limits

| Bound | Rule |
|---|---|
| Per-Member delta | GCAP: allocation deltas between consecutive intervals MUST respect that Member’s agreed ramp rates |
| All transitions | Failsafe model: into fallback, out of fallback, and between interval allocations MUST follow rates agreed with the host utility |
| Whole-pool fallback | Allocator MUST bound total cleared participation so simultaneous Member fallback stays inside manageable aggregate Grid 1 ramp limits |

Per-class snap-back / ramp envelopes (research cites 15-minute ramp discipline) are open in DESP. Quantitative domain-growth methodology is an open engineering question.

## Firm-limit fallback

On loss of Allocator, peers, or fresh context, or on a stale Commitment:

| Trigger | Required Use behavior |
|---|---|
| Missed / stale / invalid Commitment | MUST revert to Grid 1 baseline (**firm load limit**) **or** manual curtailment |
| Transition | MUST follow allowed ramp rates |
| Determinism | MUST be locally determinable from the Member’s own state and last-known configuration; MUST NOT depend on reaching a remote peer |
| Interval validity | Allocations are valid for their interval only |

Allocator-side complement: if constraint inputs are stale or the domain is partitioned, the Allocator MUST NOT clear; Members detecting a missed clearing fall back as above. Partition between peer Allocators MUST NOT trip Members in unaffected domains.

Open failsafe items that affect Use implementations: quantitative missed-interval thresholds, re-entry / hysteresis after fallback, coincidental-fallback stability, and audit/telemetry to verify fallback compliance.

<AccordionGroup>
<Accordion title="v26.0 scope and security posture">
v26.0 is energy consumed and provided inside the one-minute window. Transmission-level deployments are expected on private networks. Service Descriptors and Commitments MUST be authenticated. PKI, NERC CIP mapping, and replay protection are open (Discussion: Engineering).
</Accordion>
<Accordion title="What this spec does not yet define">
Wire format · intra-interval timing budget · identifier format · forward-vector length · staleness timer values · minimum telemetry schema · unused-allocation recycling · standard facility-type class maps · class-count extensibility · per-class SLA envelopes.
</Accordion>
</AccordionGroup>

## Open items (Use-owned)

Tracked on `members/use.md` and the linked protocol specs:

- Standard workload→class mapping guidance per facility type
- Minimum telemetry for commit-% compliance verification
- Behavior when actual load undershoots requested + committed amounts
- DESP naming (Assured/Preferred/Best-Efforts vs Firm/Semi-Firm/Flex)
- Enforcement of declared class behavior (ties to G2P §3.4)

## Next

<CardGroup>
<Card title="Buffer Member" href="/buffer-member">
Committed dispatch clears before any Use class is curtailed.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing that produces per-class commit-%.
</Card>
<Card title="Service classes" href="/service-classes">
DESP A/B/C, C→B→A order, and per-interval reclassification.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Firm-limit fallback, interval-only commits, locally determinable ramps.
</Card>
<Card title="G2P reference" href="/g2p-reference">
Descriptor, Commitment, and verified-self-dispatch message families.
</Card>
<Card title="Map workloads to classes" href="/map-workloads-to-classes">
Informative Flex 0–3 / CLR mappings; Allocator never sees internals.
</Card>
</CardGroup>

---

## 18. Buffer Member

> Signed charge and discharge offers, committed dispatch before any load curtailment, verified self-dispatch, SoC open items, and standalone Grid 1 schedule fallback.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/18-buffer-member.md
- Generated: 2026-08-17T18:30:53.505Z

### Source Files

- `members/buffer.md`
- `specs/gcap/spec.md`
- `specs/g2p/spec.md`
- `architecture/failsafe-model.md`
- `members/allocator.md`

---
title: "Buffer Member"
description: "Signed charge and discharge offers, committed dispatch before any load curtailment, verified self-dispatch, SoC open items, and standalone Grid 1 schedule fallback."
---

<Info>
`members/buffer.md` is **Draft — seeking input**. RFC 2119 keywords apply. G2P, GCAP, and DESP are independently versioned on the **26.0-draft** line. Wire format, element state machines, and conformance vectors are unspecified.
</Info>

A Buffer Member is the storage element in `members/buffer.md`: a behind-the-meter or front-of-meter grid battery that broadcasts a signed G2P Service Descriptor offering **− discharge** or **+ charge**, then self-dispatches the Allocator’s **committed dispatch**. GCAP step 2 clears that dispatch **before any Use-class curtailment**. Version 26.0 coordinates energy in the one-minute interval only.

## Status and stack

| Surface | Path | Role for a Buffer |
|---|---|---|
| Member behavior | `members/buffer.md` | Offers, listen set, edge decisions, MUSTS, failsafe, open items |
| Transport | `specs/g2p/spec.md` | Identity, four message families, signed descriptors, authenticated commitments, telemetry |
| Clearing | `specs/gcap/spec.md` | Headroom → buffers → C-B-A curtailment; committed-dispatch output |
| Classes | `specs/desp/spec.md` | Buffer dispatch MUST clear before class A/B/C is curtailed |
| Failsafe | `architecture/failsafe-model.md` | Standalone Grid 1 schedule; no Grid 2 support while in fallback |
| Clock | `architecture/temporal-position.md` | One-minute interval; Grid 1 dispatch prevails on conflict |

Membership is spec compliance at a point of interconnection whose Grid 1 constraints are provisioned to an Allocator. Commercial terms (charging, investment, class-policy limits) stay in the domain agreement, not in the protocol.

## Physical asset and identity

The associated asset is a **grid battery / storage asset** acting as the domain’s buffer.

Every Member Element MUST hold a **stable element identifier** bound to a physical point of interconnection inside a provisioned Allocation Domain. Identifier format is open (G2P §2 recommends a domain-scoped hierarchical ID matching federation nesting). A Buffer can sit in a local utility domain (`Storage A1`, `Storage B1`) or as a **regional** Buffer under the regional constraint domain.

v26.0 scope is bulk-power **energy in the interval**. Voltage support, IEEE 2030.5 distribution devices, and SST/HVDC routing are out of this version.

## Interval contract

```mermaid
sequenceDiagram
  participant B as Buffer Member
  participant A as Allocator
  participant G1 as Grid 1 custodians
  Note over B,A: One-minute interval (G2P / GCAP)
  G1->>A: Constraint set (capacity, transmission, reserves)
  B->>A: Service Descriptor: signed − discharge / + charge
  Note over A: GCAP 1 headroom, then 2 Buffer dispatch, then 3 C→B→A
  A->>B: Commitment: committed dispatch + interval + domain + inputs version
  B->>B: Self-dispatch within agreed ramp rates
  B->>A: Response / Telemetry: verified actual vs Commitment
  alt Missing or stale Commitment
    B->>B: Standalone Grid 1 schedule; no Grid 2 support
  end
```

All four G2P families are per-interval unless noted. Clearing MUST finish so the Member can self-dispatch **before the interval opens**. Exact descriptor / clearing / publication deadlines and clock-sync rules are open.

Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **the Grid 1 instruction prevails**.

## Broadcast: signed charge and discharge offers

The Buffer sits on **either side of the ledger** and MAY switch roles each interval.

<ParamField body="Service Descriptor" type="Member → Allocator (G2P §3.1)" required>
Signed statement of requests/offers over a **forward time vector**.
</ParamField>

<ParamField body="offer" type="− discharge / + charge" required>
Offer to be a **source or a use**. Sign convention is normative in G2P and `members/buffer.md`.
</ParamField>

<ParamField body="units" type="energy in the interval" required>
v26.0 positions MUST be energy within the interval, not other goal-seeks.
</ParamField>

<ParamField body="signature" type="originating Member" required>
Each position MUST be signed. All Service Descriptors and Commitments MUST be authenticated; integrity MUST be verifiable end-to-end.
</ParamField>

<ParamField body="reissue" type="per interval" optional>
A Service Descriptor MAY be reissued each interval.
</ParamField>

A Buffer does **not** publish DESP A/B/C consume buckets. Those positions belong to Use Members. Buffer participation is the signed source/use offer; GCAP consumes it at step 2, not in the class-curtailment step.

Forward-vector length, resolution, and revision rules are open. Encoding, PKI, replay protection, and NERC CIP mapping are open (Discussion: Engineering). Transmission-level deployments are expected on **private networks**.

<RequestExample>
```text title="Conceptual Buffer Service Descriptor (encoding unspecified)"
element_id:    <stable POI-bound id>
domain:        <provisioned Allocation Domain>
interval:      <one-minute clock>
offer_sign:    - | +          # discharge | charge
quantity:      <energy in interval>
forward_vector:<open: length / resolution>
signature:     <originating Member>
```
</RequestExample>

## Listen: committed dispatch before any load curtailment

The Buffer listens only for its Allocator’s **committed dispatch**, not Use `commit-%` and not Source `committed take`.

<ResponseField name="committed dispatch" type="Allocator → Buffer (G2P §3.2 / GCAP §4)">
Cleared **before any load is curtailed**. Applies to the coming interval only and expires with it.
</ResponseField>

<ResponseField name="interval, domain, inputs version" type="required on every Commitment">
The Commitment MUST identify the interval, the domain, and the clearing-inputs version it was computed against.
</ResponseField>

GCAP order is strict and deterministic (identical inputs → identical allocations; Allocator has **no discretion**):

| Step | Action | Buffer effect |
|---|---|---|
| 1 | **Headroom first** — surplus network capability for the interval | May leave nothing for step 2 |
| 2 | **Buffers second** — committed dispatch to absorb **shortfall or surplus** | Dispatch issued here; **before any class is curtailed** |
| 3 | **Ramp down tiered requests** — DESP C → B → A, proportional within class | Use Members only; never Firm (Grid 1) |

Peer-Allocator announcements MAY add boundary headroom but MUST NOT relax local constraints. On stale constraint inputs or partition, the Allocator MUST **withhold clearing**. A Member that has not received a fresh Commitment for the current interval MUST treat itself as in fallback.

Allocator SHOULD publish, inside the domain, the **input digest** each Commitment was computed against.

<ResponseExample>
```text title="Conceptual Buffer Commitment (encoding unspecified)"
element_id:           <same POI-bound id>
domain:               <Allocation Domain>
interval:             <coming one-minute interval>
committed_dispatch:   <energy in interval, signed − / +>
clearing_inputs_ver:  <digest / version>
authentication:       <Allocator>
```
</ResponseExample>

## Edge intelligence

The Allocator does not decide charge vs discharge. The Buffer owns:

- When to discharge vs hold charge for a later peak
- When to charge on surplus
- Protecting a coupled asset (for example a co-located Use Member)
- Its defining job: **reduce how often Grid 2 load goes unmet**

Network-directed storage (anticipatory movement of energy in space and time) is a planned G2TF companion document, not a living spec in this repository. Over time, buffers added to a domain are expected to shrink the unmet/deferred share for Classes B and C.

The Allocator never inspects facility internals. Overlay verification is the **aggregate footprint** (frequency, ACE, flows, peak shaving), not internal SoC or EMS state — except whatever SoC disclosure, if any, is later specified for step-2 clearing.

## Obligations

| Requirement | Normative text |
|---|---|
| Honor dispatch | MUST honor committed dispatch within **agreed ramp rates** |
| Verify | MUST report **verified self-dispatch** (G2P §3.4) |
| Ramp deltas | Per-member allocation deltas between consecutive intervals MUST respect that member’s agreed ramp rates (GCAP §6) |
| Interval-only | Allocations are valid for their interval only |
| Grid 1 conflict | Grid 1 instruction prevails |

G2P §3.4 requires each Member to report **actual per-class dispatch against its Commitment** so compliance is auditable and the overlay footprint is measurable. Buffer offers are not DESP class positions; treat the MUST as **actual dispatch versus the Commitment**. Verification granularity, metering source of truth, and attestation are open.

Pool sizing (Allocator): total participating pool MUST be sized so simultaneous fallback of all Members stays within manageable Grid 1 aggregate ramp limits. That bound is the stated limit on domain growth; methodology is open.

## Failsafe

On loss of Allocator, peers, or fresh context — including a missing or stale Commitment — the Buffer:

1. MUST revert to its **standalone Grid 1 schedule**
2. Carries **no Grid 2 support commitment** while in fallback
3. MUST follow **allowed ramp rates** (into fallback, out of fallback, and between interval allocations)
4. MUST determine fallback from **its own state and last-known configuration** — it MUST NOT depend on reaching a remote element

<Warning>
While in fallback the Buffer does not absorb domain shortfall or surplus for Grid 2. Use Members that expected Buffer relief still fall back independently to their firm-limit / manual-curtailment path.
</Warning>

Quantitative staleness thresholds (missed intervals), re-entry hysteresis, coincidental-fallback stability analysis, and audit/telemetry to verify fallback compliance are open.

## Phase 0 shadow mode

Phase 0 runs the full stack as a dry run: exchange and **track** descriptors and commitments; **execute only the Grid 1 baseline**. A Buffer still signs offers and records committed dispatch, but physical charge/discharge follows the standalone Grid 1 schedule until Phase 1 local integration.

## Open items

Do not implement these as if they were decided.

| Item | Owner / venue |
|---|---|
| How much **SoC** visibility the Allocator needs for GCAP step 2 | `members/buffer.md` |
| Priority among multiple Buffers (proportional vs merit order by round-trip efficiency) | `members/buffer.md` |
| Investment framing when a new battery is needed to support new Grid 2 loads | Discussion: Commercial terms |
| Whether curtailed Source energy can be redirected to a **co-located Buffer** in the same interval | `members/source.md` |
| Forward-vector length, resolution, revision; descriptor / clearing / publication deadlines | G2P §3.1, §4 |
| Telemetry granularity, metering source of truth, attestation | G2P §3.4 |
| Staleness timers, re-entry, coincidental-fallback analysis | Failsafe model |
| Wire format, per-element state machines, conformance vectors | G2P §7 |

## Implement a conformant Buffer

<Steps>
<Step title="Bind identity to a provisioned POI">
Obtain a stable element identifier at a point of interconnection whose transmission-owner constraints are provisioned to the domain Allocator. Membership is spec compliance plus host-utility commercial terms.
</Step>
<Step title="Publish signed source/use offers">
Each interval, emit a G2P Service Descriptor: signed − discharge or + charge, energy in the interval. Reissue when the edge decision changes. Authenticate every descriptor.
</Step>
<Step title="Wait for committed dispatch, then self-dispatch">
Accept only Commitments that name interval, domain, and clearing-inputs version. Honor committed dispatch within agreed ramp rates **before the interval opens**. If Grid 1 issues a conflicting instruction, follow Grid 1.
</Step>
<Step title="Report verified actuals">
Send G2P Response / Telemetry of actual dispatch versus the Commitment. Keep records auditable; do not expose facility internals the Allocator is not specified to see.
</Step>
<Step title="Fail locally on stale or missing commit">
If no fresh Commitment arrives for the current interval, revert to the standalone Grid 1 schedule with no Grid 2 support, ramping only at agreed rates. Do not wait for a peer to confirm fallback.
</Step>
</Steps>

## Related pages

<CardGroup>
<Card title="G2P reference" href="/g2p-reference">
Element identity, four message families, authenticated descriptors and commitments, stale-commitment faults.
</Card>
<Card title="GCAP reference" href="/gcap-reference">
Headroom, then buffers, then C-B-A curtailment; committed-dispatch outputs; determinism.
</Card>
<Card title="Allocator" href="/allocator">
No-discretion clearing, withhold-on-stale, federation announcements, whole-pool ramp sizing.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Standalone Grid 1 schedule, interval-only commitments, locally determinable fallback.
</Card>
<Card title="Use Member" href="/use-member">
Per-class consume positions and commit-% — what Buffer dispatch is meant to protect.
</Card>
<Card title="Source Member" href="/source-member">
Supply offers and the open co-located-Buffer redirect question.
</Card>
<Card title="One-minute window" href="/one-minute-window">
Commit-before-open and the Grid 1-prevails conflict rule.
</Card>
<Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
Exchange and track commitments; execute only the Grid 1 baseline.
</Card>
</CardGroup>

---

## 19. Source Member

> Supply offers over a forward vector, committed take, forecast-error open items, v26.0 single-class supply, and Grid 1 interconnection fallback.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/19-source-member.md
- Generated: 2026-08-17T18:31:16.536Z

### Source Files

- `members/source.md`
- `specs/g2p/spec.md`
- `specs/gcap/spec.md`
- `architecture/failsafe-model.md`
- `architecture/overview.md`

---
title: "Source Member"
description: "Supply offers over a forward vector, committed take, forecast-error open items, v26.0 single-class supply, and Grid 1 interconnection fallback."
---

A **Source Member** is the Member Element for clean-energy / inverter-based supply (solar, wind). The living contract is `members/source.md` (Draft — seeking input; RFC #1 Protocol Interactions table). Each interval it publishes a signed G2P **Service Descriptor** *offer to supply* (`−`) over a forward time vector, listens for the Allocator's **committed take**, self-dispatches to that take within host-utility ramp rates, and reports verified self-dispatch. v26.0 carries a single supply class. On a missing or stale Commitment it MUST revert to Grid 1 baseline interconnection behavior.

<Info>
Living files `members/source.md`, `specs/g2p/spec.md` (26.0-draft), and `specs/gcap/spec.md` (26.0-draft) are **Draft — seeking input**. RFC 2119 / RFC 8174 keywords apply. Wire format, element state machines, and conformance vectors are unspecified (G2P §7).
</Info>

## Role

Source is one of three Member Element kinds on the Grid 2 overlay (Use, Buffer, Source). It is a digital representative of a physical point of interconnection, not a market participant or price-setting agent.

| Field | Value |
|---|---|
| Associated asset | Clean-energy / inverter-based supply — solar, wind |
| Ledger sign | *Offer to supply* (`−`) |
| Listen surface | Allocator **committed take** (not Use **commit-%**, not Buffer **committed dispatch**) |
| Edge intelligence | Forecast available output; anticipate ramps |
| v26.0 energy unit | Energy provided in the one-minute interval |
| Failsafe | Grid 1 baseline interconnection behavior; allowed ramp rates |
| Document status | Draft — seeking input · Editors TBD |

The same G2P/GCAP stack that clears load-side positions also bounds Grid 2-compliant supply. RFC #1 and `members/source.md` treat that as the interconnection-side counterpart of load flex: permission-based access each interval instead of a one-shot interconnection permit. A companion G2TF document on expedited renewables interconnection is planned; it is not a living spec in this repository.

<Note>
The smallest Allocation Domain is a host utility plus one flexible **Use** Member. A Source is not required to stand up a domain. Federation diagrams place some Sources at the regional layer (`Supply (Source Member, regional)`), not only under a local utility domain.
</Note>

## Interval contract

Every Source MUST hold a stable element identifier bound to a physical point of interconnection in a provisioned Allocation Domain. Identifier format is open (G2P §2).

All messages bind to the one-minute interval clock. Allocations apply to the coming interval only and expire with it. Grid 2 MUST NOT interfere with sub-second Grid 1 primary controls. Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **the Grid 1 instruction prevails**.

```mermaid
sequenceDiagram
  participant Src as Source Member
  participant Alloc as Allocator
  participant G1 as Grid 1 interconnection
  Note over Src,Alloc: Interval n (one minute)
  Src->>Alloc: Service Descriptor: offer to supply (−)<br/>signed, energy in interval, forward vector
  Note over Alloc: GCAP deterministic clear<br/>headroom → Buffers → C then B then A
  Alloc-->>Src: Commitment: committed take<br/>interval, domain, inputs version
  alt Commitment fresh
    Src->>G1: Self-dispatch to committed take<br/>within agreed ramp rates
    Src->>Alloc: Response / telemetry<br/>verified self-dispatch (G2P §3.4)
  else Missing, stale, or Allocator withheld
    Src->>G1: Fallback: Grid 1 baseline interconnection<br/>allowed ramp rates
  end
```

<Steps>
  <Step title="Publish a Service Descriptor">
    Sign an *offer to supply* (`−`) for generation available this window, over a forward time vector. Positions MUST be in units of energy within the interval. Reissue MAY happen each interval.
  </Step>
  <Step title="Wait for committed take">
    Listen only for this Source's Allocator Commitment. Treat a missing or stale Commitment as fallback-triggering. Do not infer take from a peer, a federation announcement, or a prior interval.
  </Step>
  <Step title="Self-dispatch before the interval opens">
    G2P requires clearing to complete so Members receive the Commitment with time to self-dispatch before the interval opens. Intra-interval deadlines (descriptor, clear, publish) are open.
  </Step>
  <Step title="Verify or fall back">
    Report actual dispatch against the Commitment. If the Allocator withheld (stale constraint inputs or partition) or the Commitment did not arrive, revert to Grid 1 interconnection behavior on the agreed ramp.
  </Step>
</Steps>

## Broadcast: offer to supply

G2P §3.1 Service Descriptor (Member → Allocator) is the Source's outbound surface. A Source does **not** publish per-class consume positions and does **not** flip sign the way a Buffer does (`−` discharge / `+` charge).

<ParamField body="element_id" type="stable identifier" required>
Bound to the physical point of interconnection in the provisioned Allocation Domain. Format open.
</ParamField>

<ParamField body="offer_to_supply" type="signed energy position (−)" required>
Generation available this window. MUST be signed by the originating Member. MUST be energy in the interval (v26.0). Single class in v26.0 — not DESP A/B/C.
</ParamField>

<ParamField body="forward_time_vector" type="vector of future intervals" required>
Offer is over a forward time vector. Length, resolution, and revision rules are open (G2P §3.1).
</ParamField>

<Warning>
G2P does not specify a wire encoding. Do not treat the field names above as a schema. Implementations must still satisfy the signed-descriptor, energy-unit, authentication, and interval-binding MUSTS.
</Warning>

Authentication: every Service Descriptor MUST be authenticated; integrity MUST be verifiable end-to-end. Transmission-level deployments are expected on private networks. PKI, NERC CIP mapping, and replay protection remain open (G2P §6).

## Listen: committed take

G2P §3.2 / GCAP §4 emit **committed take** to each Source. That is distinct from the other two Member listen surfaces.

| Member | Commitment field | When it clears |
|---|---|---|
| Use | Per-class **commit-%** | After headroom and Buffer dispatch; C then B then A if still short |
| Buffer | **Committed dispatch** | GCAP step 2 — **before any load is curtailed** |
| Source | **Committed take** | Per-interval output of the same clear; supply class order is not specified |

<ParamField body="committed_take" type="energy in interval" required>
Quantity the Source MUST self-dispatch toward. Allocator has no discretion: identical inputs MUST produce identical allocations.
</ParamField>

<ParamField body="interval" type="one-minute interval id" required>
Commitments MUST identify the interval they apply to. Valid for that interval only.
</ParamField>

<ParamField body="domain" type="Allocation Domain id" required>
Commitments MUST identify the domain.
</ParamField>

<ParamField body="clearing_inputs_version" type="input digest / version" required>
Commitments MUST identify the clearing inputs version they were computed against. Allocators SHOULD publish the input digest in-domain.
</ParamField>

A Member that has not received a Commitment for the current interval MUST treat itself as in fallback. Quantitative staleness timers (missed intervals before fallback) are still to be specified in G2P.

## Edge intelligence

The Allocator holds **no internal intelligence**. Forecast and ramp anticipation live on the Source:

- Forecast available output for the forward vector.
- Anticipate ramps so consecutive-interval deltas stay inside the host-utility agreed rates.

GCAP still binds **per-member allocation deltas** between consecutive intervals to those agreed ramp rates. Pool-level: the Allocator MUST bound total cleared participation so simultaneous member fallback stays inside manageable aggregate Grid 1 ramp limits.

<Note>
Forecast accuracy expectations, and how forecast error interacts with GCAP **headroom**, are open items on `members/source.md`. Do not assume an offer-to-supply automatically increases domain headroom, or that under-delivery is absorbed by a specified GCAP term. Grid 1 ancillaries absorb interval error without modification; NERC CPS1/BAL remain the balancing measures.
</Note>

## Obligations

| Requirement | Normative text |
|---|---|
| Self-dispatch | MUST self-dispatch to committed take within agreed ramp rates |
| Telemetry | MUST report verified self-dispatch (G2P §3.4) |
| Ramp on every transition | MUST follow allowed ramp rates into fallback, out of fallback, and between interval allocations |
| Local fallback | Fallback MUST be locally determinable from the Member's own state and last-known configuration; MUST NOT depend on reaching a remote peer |
| Grid 1 prevails | If a Grid 1 dispatch instruction conflicts with the Grid 2 take, follow Grid 1 |
| Overlay duties | Continue to meet all NERC, FERC, utility, and TSO/ISO requirements in the Grid 1 context |

G2P §3.4 states Members MUST report **actual per-class dispatch** against the Commitment. For a v26.0 Source that is the single supply position. Verification granularity, metering source of truth, and attestation are open.

Commercial terms (interconnection product, charging, class-policy limits if supply classes appear later) stay in the domain agreement, not in G2P/GCAP/DESP.

## v26.0 single-class supply

DESP A / B / C stratify **demand** above traditional Grid 1 Firm. Use Service Descriptors carry one signed consume position per class. Source does not.

`members/source.md` records the open question explicitly: class structure for supply offers is **single class in v26.0**, or mirrored A/B/C later. Until that is closed:

- Do not emit Assured / Preferred / Best-Efforts (or Firm / Semi-Firm / Flex) positions on a Source Descriptor.
- Do not expect GCAP's C → B → A curtailment order to rank supply offers.
- Domain class-policy limits in DESP §4 (for example a minimum Class C share for expedited interconnection) apply to declared demand classes, not to a specified Source class table.

## Failsafe

| Trigger | Source behavior |
|---|---|
| Loss of Allocator, peers, or fresh context | MUST revert to Grid 1 baseline interconnection behavior; MUST follow allowed ramp rates |
| Missing or stale Commitment | Same fallback (G2P §3.2, failsafe model) |
| Allocator stale inputs or partition | Allocator MUST NOT clear; Source falls back as above |
| Federation partition elsewhere | MUST NOT trip this Source if its local Allocator still clears |

Fallback carries no extra Grid 2 support duty (contrast Buffer: no Grid 2 support commitment while in fallback). Re-entry procedure and hysteresis after fallback are open.

```text
  last Commitment for this interval?
           │
     yes   │   no / stale / withheld
           ▼
  self-dispatch to          Grid 1 baseline
  committed take            interconnection
  (agreed ramp)             (agreed ramp)
```

## Open items that bind implementers

Treat these as unspecified, not as implied product behavior:

| Item | Why it matters on the Source |
|---|---|
| Forecast accuracy vs GCAP headroom | No specified penalty, reserve, or headroom adjustment for forecast error |
| Curtailed Source energy → co-located Buffer same interval | Not allowed by a specified message; do not invent an intra-interval redirect |
| Supply class structure after v26.0 | Single-class now; A/B/C mirror is a live question |
| Forward-vector length / revision | Cannot yet size descriptor history or mid-horizon edits |
| Intra-interval timing budget | Descriptor deadline, clear deadline, commit publish, clock sync |
| Staleness threshold | How many missed intervals before fallback |
| Telemetry / attestation | What "verified self-dispatch" must prove |
| Wire format | No encoding, version negotiation, or test vectors yet |

Comment via GitHub Discussions (Engineering / Reliability assurance) or a PR against `members/source.md` and the three specs. Errata against RFC #1 use the `errata` label.

## Phase 0

Phase 0 shadow mode exchanges and tracks Commitments but **executes only the Grid 1 baseline**. A Source implementation in Phase 0 still publishes descriptors and records committed take; it MUST NOT change physical output from its Grid 1 interconnection schedule until Phase 1 local integration.

## Next

<CardGroup>
  <Card title="Use Member" href="/use-member">
    Per-class consume positions and commit-% — the demand-side counterpart of committed take.
  </Card>
  <Card title="Buffer Member" href="/buffer-member">
    Signed charge/discharge offers and committed dispatch before any load curtailment.
  </Card>
  <Card title="Allocator" href="/allocator">
    Deterministic GCAP clear that emits committed take; withhold-on-stale; pool ramp sizing.
  </Card>
  <Card title="G2P reference" href="/g2p-reference">
    Service Descriptor, Commitment, telemetry, authentication, and unspecified wire format.
  </Card>
  <Card title="GCAP reference" href="/gcap-reference">
    Headroom, then Buffers, then C-B-A; interval-only outputs; identical-input determinism.
  </Card>
  <Card title="Failsafe model" href="/failsafe-model">
    Grid 1 interconnection fallback, interval-only commitments, locally determinable recovery.
  </Card>
  <Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
    Exchange commitments, execute Grid 1 only, then Phase 1 / Phase 2.
  </Card>
</CardGroup>

---

## 20. Allocator

> No-discretion deterministic clearing, constraint-authority inputs, federation announcements, withhold-on-stale, and whole-pool ramp sizing.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/20-allocator.md
- Generated: 2026-08-17T18:31:14.340Z

### Source Files

- `members/allocator.md`
- `specs/gcap/spec.md`
- `specs/g2p/spec.md`
- `architecture/allocation-domains.md`
- `architecture/federation.md`
- `architecture/failsafe-model.md`

---
title: "Allocator"
description: "No-discretion deterministic clearing, constraint-authority inputs, federation announcements, withhold-on-stale, and whole-pool ramp sizing."
---

The Allocator is the per-domain clearing agent in `members/allocator.md`. Each one-minute interval it executes [GCAP](/gcap-reference) over [G2P](/g2p-reference) messages: it listens for in-zone Member Service Descriptors and peer-Allocator federation announcements, then broadcasts per-class **commit-%** (plus **committed dispatch** / **committed take**) and federation announcements. It holds **no internal intelligence or discretion**. Any party with the same inputs MUST be able to reproduce the same allocations.

<Info>
**Status:** Draft — seeking input · **Editors:** TBD · **Source:** RFC #1 Protocol Interactions table. GCAP and G2P are independently versioned on the **26.0-draft** line. RFC 2119 / RFC 8174 keywords apply. Wire format, encoding, and per-element state machines are unspecified.
</Info>

## Role and scope

An Allocator represents one **Allocation Domain**: the Member Elements cleared against a common Grid 1 constraint set. Domains nest (local transmission congestion zone → utility / balancing authority → regional RTO/ISO). One Allocator's associated scope can sit at any of those levels: transmission line → utility load zone → RTO region.

It represents the zone's Grid 1 **power production capacity** and **transmission constraints**. It MAY incorporate power distribution factors and dynamics from Dynamic Line Ratings (DLR) and similar sources. It does **not** see or direct workloads inside a facility; it clears class-level positions only.

| Attribute | Value |
|---|---|
| Canonical spec | `members/allocator.md` |
| Clearing logic | `specs/gcap/spec.md` (GCAP 26.0-draft) |
| Message layer | `specs/g2p/spec.md` (G2P 26.0-draft) |
| Class order | DESP C → B → A; Grid 1 Firm is never curtailed |
| Interval | Whole one-minute window; allocations expire with the interval |
| v26.0 quantity | Units of energy in the interval |
| Identity | Stable element identifier bound to a provisioned Allocation Domain (identifier format open) |
| Prices | Out of scope — coordination without prices |

```mermaid
flowchart LR
  subgraph custodians [Grid 1 custodians]
    TO["Transmission owner<br/>MUST provision local + regional constraints"]
    RSO["Regional system operator<br/>MAY add capacity constraints"]
  end
  subgraph domain [Allocation Domain]
    ALLOC["Allocator<br/>GCAP, no discretion"]
    USE["Use Members"]
    BUF["Buffer Members"]
    SRC["Source Members"]
  end
  subgraph peers [Coupled zones]
    PEER["Peer Allocators"]
  end
  TO -->|constraint inputs| ALLOC
  RSO -.->|optional capacity| ALLOC
  USE -->|"Service Descriptor (+ consume)"| ALLOC
  BUF -->|"Service Descriptor (−/+ charge-discharge)"| ALLOC
  SRC -->|"Service Descriptor (− supply)"| ALLOC
  ALLOC -->|"Commitment: commit-%"| USE
  ALLOC -->|"Commitment: committed dispatch"| BUF
  ALLOC -->|"Commitment: committed take"| SRC
  ALLOC <-->|"Federation Announcement"| PEER
  USE -->|"Response / Telemetry"| ALLOC
  BUF -->|"Response / Telemetry"| ALLOC
  SRC -->|"Response / Telemetry"| ALLOC
```

Authority is **not** derived from the protocol. The utility transmission owner MUST provision the Allocator's local and regional constraints. A regional system operator MAY additionally provision capacity constraints to a regional Allocator. Commercial terms (class-mix limits, charging, enforcement of flex) stay in the domain agreement.

## Broadcasts and listens

Two interaction patterns exist: **Member ↔ Allocator** and **Allocator ↔ Allocator**. Both ride G2P. All four message families are per-interval unless noted.

| Direction | G2P family | Payload the Allocator handles |
|---|---|---|
| In | Service Descriptor (§3.1) | Signed in-zone requests/offers over a forward time vector |
| In | Federation Announcement (§3.3) | Coupled-boundary quantities from peer Allocators |
| In | Response / Telemetry (§3.4) | Verified self-dispatch vs. Commitment |
| Out | Commitment (§3.2) | Per-class commit-%; committed dispatch; committed take |
| Out | Federation Announcement (§3.3) | This domain's announce-and-listen export |

<ParamField body="Service Descriptor" type="Member → Allocator" required>
Signed positions in energy-in-the-interval units. Use: one consume (+) position per DESP class. Buffer: − discharge / + charge. Source: supply (−). MAY be reissued each interval; classes MAY change per interval.
</ParamField>

<ParamField body="Commitment" type="Allocator → Member" required>
MUST identify the **interval**, the **domain**, and the **clearing inputs version**. Use receives per-class **commit-%**. Buffer receives **committed dispatch** (cleared before any load is curtailed). Source receives **committed take**.
</ParamField>

<ParamField body="Federation Announcement" type="Allocator ↔ Allocator" required>
MUST identify announcing **domain**, **interval**, and **coupled-boundary quantities**. Message schema is still to be specified in G2P.
</ParamField>

<ParamField body="Response / Telemetry" type="Member → Allocator" required>
Members MUST report actual per-class dispatch against the Commitment. Verification granularity, metering source of truth, and attestation are open.
</ParamField>

Descriptors and Commitments MUST be authenticated; message integrity MUST be verifiable end-to-end. Transmission-level deployments are expected on private networks. PKI, NERC CIP mapping, and replay protection are open (Discussion: Engineering).

## Interval cycle

Clearing MUST finish so Members receive commit-% with time to self-dispatch **before the interval opens**. Descriptor, clearing, and publication deadlines, plus clock sync, are open. Where a Grid 1 dispatch instruction conflicts with a Grid 2 allocation, **Grid 1 prevails**.

<Steps>
<Step title="Collect local constraint inputs">
Take the Grid 1 set provisioned by the domain's custodians: zone power production capacity, transmission constraints, target reserves; optionally DLR and distribution factors. If those inputs are stale, or the **local domain** is partitioned from its constraint authority, **do not clear**.
</Step>
<Step title="Collect G2P interval inputs">
Ingest signed Member Service Descriptors. Ingest peer-Allocator announcements. Missing required peer announcements do **not** stop local clearing — treat the coupled boundary as contributing **no additional headroom**.
</Step>
<Step title="Run GCAP or withhold">
If inputs are fresh, run the headroom → buffers → C-B-A algorithm. Identical inputs MUST yield identical allocations. SHOULD publish (inside the domain) the input digest the Commitment was computed against.
</Step>
<Step title="Publish and bound ramps">
Emit Commitments and federation announcements. Bound total cleared participation so simultaneous member fallback stays inside domain ramp limits. Per-member allocation deltas MUST respect each member's agreed ramp rates.
</Step>
</Steps>

```mermaid
sequenceDiagram
  participant TO as Grid 1 custodians
  participant A as Allocator
  participant M as Members
  participant P as Peer Allocators
  TO->>A: Provision constraints (capacity, transmission, reserves; optional DLR)
  M->>A: Service Descriptor (signed positions)
  P->>A: Federation Announcement (boundary quantities)
  alt Stale local constraints or local domain partition
    A--xM: Withhold Commitment
    M->>M: Fallback to Grid 1 baseline
  else Fresh local constraints
    A->>A: GCAP: headroom, then Buffers, then C→B→A
    A->>M: Commitment (interval, domain, inputs version)
    A->>P: Federation Announcement
    M->>M: Self-dispatch before interval open
    M->>A: Response / Telemetry
  end
```

## Constraint inputs

Each interval the Allocator clears **only** against:

1. **Grid 1 constraints** from this domain's custodians.
2. **Member Service Descriptors** in-zone.
3. **Peer-Allocator announcements**, which MAY add boundary headroom but **MUST NOT relax local constraints**.

Which existing transmission-owner signals are the right inputs, and how to standardize them, is a headline Engineering discussion. Input-digest publication is an Allocator open item even though GCAP already says Allocators SHOULD publish the digest.

<Warning>
Peer announcements inform; they never override local custodians. An Allocator MUST clear only against constraints provisioned by **its own** domain's Grid 1 custodians.
</Warning>

## Clearing algorithm

GCAP redispatches deterministically and proportionally, in this **strict** order:

| Step | Name | Rule |
|---|---|---|
| 1 | Headroom | Compute surplus network capability for the interval. |
| 2 | Buffers | Clear Buffer committed dispatch to absorb shortfall or surplus. **Buffers clear before any load is curtailed.** |
| 3 | Tiered ramp-down | If relief is still required, reduce Use allocations C (Best Efforts) → B (Preferred) → A (Assured). Never touch traditional Firm (Grid 1). |

Within a class, curtailment MUST be **proportional** to connection size and differential request size. The exact weighting, indivisible loads, nodal vs. single-zone headroom, and cross-interval fairness (whether deferred Class C accrues priority) are GCAP open items.

Determinism is the trust model: the Allocator is not an operator. Edge Members own forecasting, workload-to-class mapping, charge/discharge timing, and self-dispatch.

<Note>
v26.0 Source offers are a single supply class. Buffer SoC visibility needed for step 2 is unspecified.
</Note>

## Outputs

Allocations apply to the **coming interval only** and expire with it.

| Recipient | Output | Member obligation |
|---|---|---|
| Use | Per-class **commit-%** | MUST self-dispatch within commit-% and agreed ramp rates; MUST report verified self-dispatch |
| Buffer | **Committed dispatch** | MUST honor dispatch within ramp rates; no Grid 2 support commitment while in fallback |
| Source | **Committed take** | MUST self-dispatch to committed take within ramp rates |
| Peer Allocators | Federation announcement | Listeners import boundary quantities; they MUST NOT use them to loosen local limits |

A Member that has not received a commit-% for the current interval MUST treat itself as in fallback. Explicit staleness timers are still to be specified in G2P.

## Withhold-on-stale vs conservative federation

`members/allocator.md` and GCAP say: on stale inputs or partition, **no clearing**. `architecture/federation.md` says: partition between **peer** Allocators MUST NOT prevent local clearing and MUST NOT trip Members in unaffected domains.

Treat those as two different failures:

| Condition | Allocator action | Member effect |
|---|---|---|
| Stale **constraint inputs**, invalid clearing inputs, or **local domain** partition from custodians / Members | MUST **withhold** clearing | Missed Commitment → Grid 1 fallback |
| Missing required **peer** announcements on a coupled boundary | MUST still clear, **conservatively**, as if the boundary adds **zero** headroom | Local Members keep receiving Commitments |
| Partition between peer Allocators only | Independent local operation | MUST NOT trigger fallback in unrelated domains |

<Warning>
Do not implement "any missing announcement ⇒ withhold." That would trip local Members on a peer-zone partition, which federation forbids. Withhold when **local Grid 1 constraint inputs** are stale or the **local** clearing context is partitioned.
</Warning>

Fallback at the edge is locally determinable from the Member's own state. It MUST NOT depend on reaching the Allocator.

| Element | On missed / stale Commitment |
|---|---|
| Use | Grid 1 baseline (firm load limit) or manual curtailment; follow ramp rates |
| Buffer | Standalone Grid 1 schedule; no Grid 2 support commitment |
| Source | Grid 1 interconnection behavior; follow ramp rates |

## Pool and ramp sizing

The Allocator MUST bound total cleared participation so **simultaneous fallback of all Members** produces aggregate ramps within manageable Grid 1 system ramp limits. That bound is the binding constraint on domain growth; the sizing methodology is open.

Per-member allocation deltas between consecutive intervals MUST respect each member's agreed ramp rates. All transitions — into fallback, out of fallback, and between interval allocations — MUST respect host-utility ramp rates.

## Hosting, redundancy, and Phase 0

Hosting (utility-operated vs. third-party under utility authority) and the redundancy model (active/standby Allocators per domain?) are open. Federation diagrams already allow **Allocator(s)** per nested domain.

There is no reference implementation or wire codec in this repository. Phase 0 is shadow mode: exchange and track commitments, execute only the Grid 1 baseline, then graduate to Phase 1 local integration and Phase 2 regional federation. Implementation reports belong in Discussions.

## Open items owned here

<AccordionGroup>
<Accordion title="Allocator-owned">
Redundancy (active/standby per domain). Clearing-inputs digest publication. Hosting and operational responsibility. Standardization of transmission-owner input signals (Discussion: Engineering).
</Accordion>
<Accordion title="Carried on G2P / GCAP / federation">
Wire format. Intra-interval deadlines and clock sync. Staleness-timer values. Federation announcement schema (boundary headroom only vs. per-class aggregates). Loop prevention and inter-domain import policy. Exact proportionality formula. Overlapping-domain membership (local + regional).
</Accordion>
</AccordionGroup>

## Next

<CardGroup>
<Card title="GCAP reference" href="/gcap-reference">
Headroom, then buffers, then C-B-A; identical-input determinism; pool and ramp-safety bounds.
</Card>
<Card title="G2P reference" href="/g2p-reference">
Four message families, commit-before-open timing, authenticated descriptors, stale-commitment faults.
</Card>
<Card title="Federation" href="/federation">
Announce-and-listen, conservative missing-announcement clearing, peer partition that does not trip local Members.
</Card>
<Card title="Provision constraint inputs" href="/provision-constraint-inputs">
Required Grid 1 set, optional DLR and distribution factors, digests, peers MUST NOT relax local limits.
</Card>
<Card title="Failsafe model" href="/failsafe-model">
Withhold-on-stale, interval-only commitments, locally determinable fallback.
</Card>
<Card title="Allocation domains" href="/allocation-domains">
Nested domains, transmission-owner authority, membership by spec compliance.
</Card>
</CardGroup>

---

## 21. Document lifecycle

> Draft to Proposed to Stable to RFC, YY.N protocol versions, required compatibility statements, and the GOVERNANCE.md decision log.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/21-document-lifecycle.md
- Generated: 2026-08-17T18:31:02.000Z

### Source Files

- `GOVERNANCE.md`
- `CONTRIBUTING.md`
- `README.md`
- `rfcs/README.md`
- `specs/g2p/spec.md`
- `architecture/overview.md`

---
title: "Document lifecycle"
description: "Draft to Proposed to Stable to RFC, YY.N protocol versions, required compatibility statements, and the GOVERNANCE.md decision log."
---

Living files in `specs/`, `members/`, and `architecture/` advance through the four-stage lifecycle in `GOVERNANCE.md`. Protocol versions use the **YY.N** scheme (current line **26.x**; G2P, GCAP, and DESP headers currently read `Version: 26.0-draft`). The Task Force publishes immutable snapshots to `rfcs/`. Normative pull requests must state compatibility impact; once a document is `Stable`, further changes require a compatibility statement. Merged decisions append to the decision log in `GOVERNANCE.md`.

<Info>
RFC #1 is already published (August 2026). Living specs were decomposed from that snapshot and are still `Draft — seeking input`. No living file is `Proposed` or `Stable` yet. The README compatibility matrix is reserved, not populated.
</Info>

## Lifecycle states

```
Draft (seeking input) → Proposed (rough consensus on scope & approach)
    → Stable vXX.Y (implementable; changes require compatibility statement)
    → RFC (immutable snapshot published to rfcs/)
```

```mermaid
stateDiagram-v2
    [*] --> Draft: new living document
    Draft --> Draft: comment-cycle revisions
    Draft --> Proposed: rough consensus on scope and approach
    Proposed --> Proposed: comment-cycle revisions
    Proposed --> Stable: implementable YY.N
    Stable --> Stable: change plus compatibility statement
    Stable --> RfcSnap: Task Force publishes snapshot
    RfcSnap --> RfcSnap: never modified
    RfcSnap --> Draft: errata resolved in living specs
```

| State | Meaning | What may change |
|---|---|---|
| `Draft — seeking input` | Scope and approach are open. Current status of all normative living files. | Text, open items, and editors (headers currently `Editors: TBD`). |
| `Proposed` | Rough consensus on scope and approach, as judged by the responsible editor. | Normative text under the comment cycle; still not the implementable line. |
| `Stable (vXX.Y)` | Implementable protocol line. | Changes require a compatibility statement. |
| RFC | Immutable archival snapshot under `rfcs/`. | The RFC file is never edited. Corrections are `errata` issues resolved in living specs. |
| `Informative` | Not a maturity rung. `architecture/design-principles.md` is the only file with this header. | Avoids RFC 2119 keywords; excluded from the normative set. |

The Task Force approves publication of new RFCs. Editors maintain specific documents, judge rough consensus on threads that affect those documents, and merge PRs. Each normative document lists its editors in its header.

## Status and version headers

Every normative file carries a status header in one of these exact forms:

| Header | Where it appears |
|---|---|
| `Status: Draft — seeking input` | Required Draft form (`CONTRIBUTING.md`) |
| `Status: Proposed` | Required Proposed form |
| `Status: Stable (vXX.Y)` | Required Stable form |
| `Status: Informative` | Marks a file out of the normative set |

<ParamField body="Status" type="string" required>
Maturity of the living file. Normative values are `Draft — seeking input`, `Proposed`, or `Stable (vXX.Y)`. `Informative` opts the file out of RFC 2119 and the Draft/Proposed/Stable ladder.
</ParamField>

<ParamField body="Version" type="string">
Present on the three protocol specs only. Current value is `26.0-draft` on `specs/g2p/spec.md`, `specs/gcap/spec.md`, and `specs/desp/spec.md`.
</ParamField>

<ParamField body="Editors" type="string" required>
Editors responsible for the document. Currently `TBD` on every living file that lists the field.
</ParamField>

<ParamField body="Source" type="string">
Citation back to RFC #1 (section or table). Present on architecture and member files.
</ParamField>

<ParamField body="Role in stack" type="string">
Present on the three protocol specs. Positions the file in the DESP / GCAP / G2P stack; it is not a maturity field.
</ParamField>

Normative documents (`specs/`, `members/`, and `architecture/` files not marked `Status: Informative`) use MUST / MUST NOT / SHOULD / SHOULD NOT / MAY per RFC 2119 / RFC 8174. Informative documents must not use those keywords.

## YY.N protocol versions

G2P, GCAP, and DESP version independently. `GOVERNANCE.md` defines **YY.N** (example: `26.0` = first 2026 release). `README.md` names the current line **26.x** and states that a compatibility matrix will live in the README as the specs diverge in maturity. That matrix is not present yet.

| Protocol file | Header version | Status |
|---|---|---|
| `specs/g2p/spec.md` | `26.0-draft` | `Draft — seeking input` |
| `specs/gcap/spec.md` | `26.0-draft` | `Draft — seeking input` |
| `specs/desp/spec.md` | `26.0-draft` | `Draft — seeking input` |

Member and architecture files do not carry a `Version:` field. They share the same Draft/Proposed/Stable (or Informative) status header.

A later `26.1` on one protocol does not imply the same bump on the other two. Interoperability across independently advanced lines is what the README matrix is reserved to record.

## Compatibility statements

Two rules apply, at different gates:

| Gate | Required statement | Source |
|---|---|---|
| Any PR against a normative document | Use RFC 2119 keywords and **state compatibility impact**. Two spec editors must review. | `CONTRIBUTING.md` comment cycle, Review |
| Change to a `Stable` document | **Compatibility statement** required. | `GOVERNANCE.md` lifecycle |

Until a file is `Stable`, the Review-step impact sentence is still required on normative PRs. After `Stable`, that statement is also the condition for changing implementable text.

The README matrix is the planned cross-protocol record. It is not a substitute for the per-PR statement.

## Living files versus RFCs

:::files
rfcs/                      immutable archival snapshots
  README.md                RFC index
  grid-2-rfc-1.pdf         RFC #1, August 2026
specs/                     living protocols, independent YY.N
  g2p/spec.md
  gcap/spec.md
  desp/spec.md
members/                   living member-type behavior
architecture/              living system model
GOVERNANCE.md              lifecycle, roles, decision log
CONTRIBUTING.md            comment cycle and header conventions
:::

| Path | README folder status | File headers |
|---|---|---|
| `rfcs/` | Published | RFC #1 is the only published RFC |
| `architecture/` | Draft | Five files `Draft — seeking input`; `design-principles.md` is `Informative` |
| `specs/` | Draft — seeking input | All three `26.0-draft` / `Draft — seeking input` |
| `members/` | Draft — seeking input | All four `Draft — seeking input` |

RFCs are never modified after publication. File corrections as Issues labeled `errata` and resolve them in the living specs. Substantive contributors are acknowledged in subsequent RFC publications, following RFC #1's acknowledgments model. Contributions submitted as issues, discussion posts, or PRs are licensed CC BY 4.0 and may be incorporated into those publications (`NOTICE.md`).

### Published RFC index

| RFC | Title | Published |
|---|---|---|
| RFC #1 (`rfcs/grid-2-rfc-1.pdf`) | Introducing Grid 2.0: An open standard for grid service access and allocation | August 2026 |

## How a document moves

<Steps>
  <Step title="Raise">
    Open a Discussion for a question or alternative, or an Issue for a defect (ambiguity, contradiction, RFC #1 errata, missing normative requirement).
  </Step>
  <Step title="Converge">
    Editors summarize positions. When a direction has rough consensus, an editor or the proposer opens a PR against `specs/`, `members/`, or `architecture/`.
  </Step>
  <Step title="Review">
    PRs against normative documents require review by two spec editors. The PR must use RFC 2119 keywords and state compatibility impact. One sentence per line is preferred for new or substantially revised normative text.
  </Step>
  <Step title="Record">
    Merged decisions are logged in `GOVERNANCE.md` with a one-paragraph rationale and links to the originating thread. Consensus is judged by the responsible editor, not by vote.
  </Step>
  <Step title="Advance or snapshot">
    Draft → Proposed when the editor judges rough consensus on scope and approach. Proposed → Stable when the line is implementable (`vYY.N`). Stable → RFC when the Task Force approves an immutable snapshot into `rfcs/`.
  </Step>
  <Step title="Run">
    Implementations from Phase 0 shadow mode onward report experience in Discussions. Running code informs the next revision of the living files.
  </Step>
</Steps>

<Warning>
Rough consensus is not unanimity. The editor asks whether all objections have been considered and addressed or explicitly overruled with recorded rationale. Sustained objections go in the decision log even when overruled.
</Warning>

## Decision log

The log is the table in `GOVERNANCE.md`. Each merged decision adds a row: date, decision, one-paragraph rationale, and originating thread.

| Date | Decision | Rationale | Thread |
|---|---|---|---|
| 2026-08 | Publish RFC #1; decompose into living specs (this repo structure) | Separate immutable narrative from evolving normative text; give the community focused surfaces for comment | — |

That first entry is why RFC #1 exists as a published PDF while G2P, GCAP, DESP, member files, and architecture files are still Draft living text.

## Who decides what

| Role | Lifecycle authority |
|---|---|
| Editors | Maintain listed documents, judge rough consensus, merge PRs |
| Contributors | Participate via Discussions, Issues, or PRs. Standing is by merit of contribution, not affiliation |
| Task Force | Resolve cross-document conflicts, appoint editors, set milestone dates, approve publication of new RFCs |

Cross-document conflicts and RFC publication are Task Force actions. Per-document maturity (Draft / Proposed / Stable) is an editor judgment under the comment cycle.

## Current inventory

| File | Status header | Version |
|---|---|---|
| `architecture/overview.md` | `Draft — seeking input` | — |
| `architecture/temporal-position.md` | `Draft — seeking input` | — |
| `architecture/allocation-domains.md` | `Draft — seeking input` | — |
| `architecture/federation.md` | `Draft — seeking input` | — |
| `architecture/failsafe-model.md` | `Draft — seeking input` | — |
| `architecture/design-principles.md` | `Informative` | — |
| `specs/g2p/spec.md` | `Draft — seeking input` | `26.0-draft` |
| `specs/gcap/spec.md` | `Draft — seeking input` | `26.0-draft` |
| `specs/desp/spec.md` | `Draft — seeking input` | `26.0-draft` |
| `members/use.md` | `Draft — seeking input` | — |
| `members/buffer.md` | `Draft — seeking input` | — |
| `members/source.md` | `Draft — seeking input` | — |
| `members/allocator.md` | `Draft — seeking input` | — |
| `rfcs/grid-2-rfc-1.pdf` | Published RFC | RFC #1 |

## Failure modes

| Symptom | Cause | What to do |
|---|---|---|
| PR edits `rfcs/grid-2-rfc-1.pdf` or other RFC artifacts | RFCs are immutable | File an Issue labeled `errata`; patch the living spec instead |
| Normative PR has no compatibility-impact sentence | Review gate in `CONTRIBUTING.md` | Add the statement; obtain two spec-editor reviews |
| Stable-line change without a compatibility statement | `GOVERNANCE.md` Stable rule | Do not merge until the statement is in the PR and, when lines diverge, the README matrix |
| RFC 2119 keywords in `architecture/design-principles.md` | File is `Status: Informative` | Rewrite without MUST/SHOULD/MAY, or reclassify the file first |
| Missing or non-canonical `Status:` header | Every normative file must use one of the three CONTRIBUTING forms | Fix the header before treating the file as Proposed or Stable |
| Decision merged but not in `GOVERNANCE.md` | Record step skipped | Append date, decision, one-paragraph rationale, and thread link |
| Sustained objection dropped | Overrules must still be logged | Record the objection and the editor rationale in the decision log |
| Cross-protocol bump assumed | G2P, GCAP, and DESP version independently | Bump only the protocol that changed; update the README matrix when it exists |

## Related pages

<CardGroup>
  <Card title="How to read the specs" href="/how-to-read-the-specs">
    Status headers, RFC 2119 keywords, living files versus immutable RFCs, and independent 26.x lines.
  </Card>
  <Card title="Comment, review, and file errata" href="/comment-and-errata">
    Discussions versus Issues versus PRs, the `errata` label, two-editor review, and decision-log recording.
  </Card>
  <Card title="Contributing" href="/contributing">
    Open participation, comment-cycle steps, writing conventions, and Phase 0 implementation reports.
  </Card>
  <Card title="Governance and licenses" href="/governance">
    Editor, contributor, and Task Force roles; rough consensus; licenses; and the Grid 1 regulator relationship.
  </Card>
</CardGroup>

---

## 22. Contributing

> Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions, and implementation reports from Phase 0 onward.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/22-contributing.md
- Generated: 2026-08-17T18:30:43.777Z

### Source Files

- `CONTRIBUTING.md`
- `GOVERNANCE.md`
- `NOTICE.md`
- `README.md`
- `rfcs/README.md`

---
title: "Contributing"
description: "Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions, and implementation reports from Phase 0 onward."
---

Participation in `g2tf-org/g2tf-standards` is open to individuals. Organizational affiliation is not required and confers no extra standing. The Grid 2.0 Task Force (G2TF) runs the repo with an IETF-style ethos: start small, stay focused; open participation on individual merit; time-limited milestones; get rough consensus, publish, then run.

Work lands on GitHub Discussions, Issues, and pull requests against `specs/`, `members/`, and `architecture/`. Submitting an issue, discussion post, or PR licenses that contribution under CC BY 4.0 so it can be incorporated into G2TF publications with attribution. Any code that appears in the work is Apache-2.0 (`LICENSE-CODE`).

<Info>
This page is the contributor operating surface. Channel choice, RFC #1 `errata` Issues, two-editor review, and the decision log are also covered on [Comment, review, and file errata](/comment-and-errata). Roles, licenses, and trademarks live on [Governance and licenses](/governance).
</Info>

## Ethos

| Rule | What it means in this repo |
|---|---|
| Start small, stay focused | Comment and PR against one living file or one open question; do not rewrite RFC #1 |
| Open participation, individual merit | Anyone may raise, review, or implement; standing comes from the contribution |
| Time-limited milestones | The Task Force sets milestone dates; protocol lines use `YY.N` (current: **26.x**) |
| Rough consensus, publish, then run | Editors judge consensus, merge living-spec text, then implementations report back |

## Where work happens

| Channel | Use it for | Do not use it for |
|---|---|---|
| **GitHub Discussions** | Technical questions, design alternatives, implementation reports | Concrete defects or ready spec text |
| **Issues** | Ambiguities, contradictions, missing normative requirements, RFC #1 errata (`errata` label) | Open design exploration |
| **Pull requests** | Proposed text against `specs/`, `members/`, `architecture/` | Edits to published files under `rfcs/` |
| **G2TF WhatsApp Community** | Cross-organization news and policy debate | Normative spec language |

README routes the same three GitHub surfaces: Discussions for questions and alternatives, PRs for spec text, Issues labeled `errata` for RFC #1.

### Discussion categories

Discussions follow the technical open-question areas from RFC #1:

1. **Commercial terms** — enforcement of flexible capabilities, limits on differential service classes, congestion-solving investment decisions, rate-structure impacts.
2. **Reliability assurance** — coincidental load shedding and system stability, materialization of flexibility commitments at scale, compliance incentives.
3. **Engineering** — headroom sufficiency for coincident swings, cybersecurity / NERC CIP, standardization of transmission-owner input signals.

Living specs already point some open items at these categories (for example G2P security maps PKI, NERC CIP, and replay protection to `Discussion: Engineering`).

## Contribution surfaces

:::files
g2tf-standards/
  CONTRIBUTING.md          # this process
  GOVERNANCE.md            # roles, lifecycle, decision log
  NOTICE.md                # CC BY 4.0 / Apache-2.0 contribution terms
  specs/
    g2p/spec.md            # G2P 26.0-draft
    gcap/spec.md           # GCAP 26.0-draft
    desp/spec.md           # DESP 26.0-draft
  members/
    use.md
    buffer.md
    source.md
    allocator.md
  architecture/            # normative unless Status: Informative
  rfcs/                    # immutable snapshots — file errata, do not PR text
:::

`specs/*` and `members/*` are **Draft — seeking input** with **Editors: TBD**. `architecture/design-principles.md` is `Status: Informative`. G2P §7 explicitly invites PRs for wire format, element state machines, version negotiation, and conformance test vectors.

<Warning>
Files under `rfcs/` are immutable archival publications. RFC #1 (`rfcs/grid-2-rfc-1.pdf`, August 2026) is never edited in place. File an Issue labeled `errata` and resolve the correction in the living specs.
</Warning>

## Comment cycle

<Steps>
  <Step title="Raise">
    Open a Discussion for a question or design alternative, or an Issue for a defect (ambiguity, contradiction, missing MUST/SHOULD, or RFC #1 errata).
  </Step>
  <Step title="Converge">
    Editors summarize positions. When a direction has rough consensus, an editor or the proposer opens a PR with spec text against `specs/`, `members/`, or `architecture/`.
  </Step>
  <Step title="Review">
    PRs against normative documents require review by **two spec editors**. Normative changes MUST use RFC 2119 keywords and MUST state compatibility impact.
  </Step>
  <Step title="Record">
    Merged decisions are logged in `GOVERNANCE.md` with a one-paragraph rationale and links to the originating thread. The responsible editor judges rough consensus; there is no vote.
  </Step>
  <Step title="Run">
    Implementations from Phase 0 shadow mode onward report experience in Discussions. Running code informs the next living-spec revision.
  </Step>
</Steps>

Rough consensus means all objections have been considered and either addressed or explicitly overruled with recorded rationale. Sustained objections stay in the decision log even when overruled.

Current decision-log row:

| Date | Decision | Rationale | Thread |
|---|---|---|---|
| 2026-08 | Publish RFC #1; decompose into living specs | Separate immutable narrative from evolving normative text; give the community focused surfaces for comment | — |

## Writing conventions

Apply these rules to new or substantially revised text.

### Normative vs informative

| Kind | How you recognize it | Keyword rule |
|---|---|---|
| Normative | `specs/`, `members/`, and `architecture/` files **not** marked `Status: Informative` | Use **MUST / MUST NOT / SHOULD / SHOULD NOT / MAY** per RFC 2119 / RFC 8174 |
| Informative | Header carries `Status: Informative` | Avoid RFC 2119 keywords |

Normative files open with the RFC 2119 boilerplate already used in G2P, GCAP, DESP, and the member specs:

```markdown
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be
interpreted as described in RFC 2119 / RFC 8174.
```

### Status header

Every normative file carries one of:

| Header | Meaning |
|---|---|
| `Status: Draft — seeking input` | Current living-spec default |
| `Status: Proposed` | Rough consensus on scope and approach |
| `Status: Stable (vXX.Y)` | Implementable; further changes require a compatibility statement |

Protocol versions use **YY.N** (example: `26.0-draft` on G2P / GCAP / DESP). G2P, GCAP, and DESP version independently. Promotion through Draft → Proposed → Stable → RFC is documented on [Document lifecycle](/document-lifecycle).

### One sentence per line

Prefer one sentence per line in new or substantially revised normative text so Git diffs stay reviewable. Do not reflow an entire file just to match the convention.

### Compatibility statement

Normative PRs must state compatibility impact. After a line is **Stable**, changes require an explicit compatibility statement; the README compatibility matrix is the planned home for cross-protocol drift and is not populated yet.

### Review checklist

Before requesting editor review:

- Target is a living file under `specs/`, `members/`, or `architecture/` — not `rfcs/`.
- Status header is present and accurate.
- RFC 2119 keywords appear only in normative files.
- Compatibility impact is stated in the PR.
- Open items stay marked as open (the living specs use `*(Open: …)*`) unless the PR actually closes them.
- Two spec editors are requested on the PR.

## Implementation reports (Phase 0 onward)

There is no implementation tree, test harness, or report template in this repository. The required feedback path is GitHub Discussions.

Phased adoption in `architecture/design-principles.md` (from RFC #1 §Phased Adoption):

| Phase | Name | What to report |
|---|---|---|
| **Phase 0** | Shadow mode | Commitments exchanged and tracked; execution stays on the Grid 1 baseline |
| **Phase 1** | Local vertical integration | Local host-utility integration experience against the living specs |
| **Phase 2** | Regional federation | Cross-domain announce-and-listen and partition behavior |

File reports under the matching Discussion category (Commercial terms, Reliability assurance, or Engineering). Running-code evidence feeds the next revision; it does not amend RFC #1.

Operational Phase 0 steps live on [Run Phase 0 shadow mode](/phase-0-shadow-mode).

## Licensing and acknowledgment

By submitting an issue, discussion post, or pull request you agree the contribution is licensed **CC BY 4.0** and may be incorporated into G2TF publications. Code that emerges in the work is **Apache-2.0**.

Substantive contributors are acknowledged in subsequent RFC publications, following the acknowledgments section of RFC #1.

"Grid 2.0"™, "G2TF"™, "G2P"™, "GCAP"™, and "DESP"™ are trademarks of the Grid 2.0 Task Force. Neither license grants trademark rights. A trademark usage policy for describing conformant implementations is forthcoming in `GOVERNANCE.md`.

<Note>
Grid 2 is voluntary and sits inside existing Grid 1 rules. Contributions must not assume the overlay supersedes NERC, FERC, utility, or TSO/ISO requirements.
</Note>

## Next

<CardGroup>
  <Card title="Comment, review, and file errata" href="/comment-and-errata">
    Discussions vs Issues vs PRs, the `errata` label, two-editor review, and the decision log.
  </Card>
  <Card title="Document lifecycle" href="/document-lifecycle">
    Draft → Proposed → Stable → RFC, YY.N versions, and required compatibility statements.
  </Card>
  <Card title="Governance and licenses" href="/governance">
    Editor, contributor, and Task Force roles; CC BY 4.0 and Apache-2.0; trademarks.
  </Card>
  <Card title="How to read the specs" href="/how-to-read-the-specs">
    Status headers, RFC 2119 keywords, living files vs immutable RFCs.
  </Card>
  <Card title="Run Phase 0 shadow mode" href="/phase-0-shadow-mode">
    Dry-run commitments, Grid 1 baseline execution, then Phase 1 and Phase 2.
  </Card>
</CardGroup>

---

## 23. Governance and licenses

> Editor, contributor, and Task Force roles; rough consensus; CC BY 4.0 spec text and Apache-2.0 code; trademarks; and Grid 1 regulator relationship.

- Page Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/pages/23-governance-and-licenses.md
- Generated: 2026-08-17T18:32:21.441Z

### Source Files

- `GOVERNANCE.md`
- `NOTICE.md`
- `LICENSE`
- `LICENSE-CODE`
- `CONTRIBUTING.md`
- `README.md`

---
title: "Governance and licenses"
description: "Editor, contributor, and Task Force roles; rough consensus; CC BY 4.0 spec text and Apache-2.0 code; trademarks; and Grid 1 regulator relationship."
---

The Grid 2.0 Task Force (G2TF) maintains this repository as the canonical Grid 2 specification home and publishes progress at [g2tf.org](https://www.g2tf.org). Roles, rough consensus, the decision log, trademarks, and the Grid 1 regulator relationship live in `GOVERNANCE.md`. Copyright, inbound contribution licenses, and the dual outbound split live in `NOTICE.md`, `LICENSE` (CC BY 4.0 specification text), and `LICENSE-CODE` (Apache-2.0 code). The Task Force formed at the publication of RFC #1 (August 2026).

<Info>
Every living normative file lists **Editors** in its status header. As of the current tree those headers are `Editors: TBD`. The Task Force appoints editors; until named, two-editor review and merge authority still apply to the editor role as defined below.
</Info>

## Canonical files

:::files
.
├── GOVERNANCE.md      # roles, rough consensus, decision log, trademarks, regulators
├── NOTICE.md          # © 2026 G2TF; inbound SPECS vs CODE licenses; trademark notice
├── LICENSE            # Creative Commons Attribution 4.0 International (spec text)
├── LICENSE-CODE       # Apache License 2.0 (code)
├── CONTRIBUTING.md    # comment cycle, two-editor review, RFC acknowledgments
├── rfcs/              # immutable RFCs (RFC #1, August 2026)
├── architecture/      # living architecture (Draft / Informative)
├── specs/             # G2P, GCAP, DESP (Draft — seeking input)
└── members/           # Use, Buffer, Source, Allocator (Draft — seeking input)
:::

## Task Force

G2TF is a working group of individuals with electric-grid and market-development experience across organizations. It is modeled on the IETF: open individual participation, merit of contribution, time-limited milestones, and “get rough consensus, publish, then run.” Organizational affiliation confers no extra standing.

The Task Force:

- Maintains this repository
- Appoints editors
- Resolves cross-document conflicts
- Sets milestone dates
- Approves publication of new RFCs

RFC publication is a Task Force act. Living files (`architecture/`, `specs/`, `members/`) evolve under editor-judged rough consensus; `rfcs/` snapshots are never modified after publication.

## Roles

| Role | Authority | How standing is established |
|---|---|---|
| **Editor** | Maintains named documents; judges rough consensus on threads that affect those documents; merges PRs | Appointed by the Task Force; listed in each normative document header |
| **Contributor** | Participates via Discussions, Issues, or PRs | Open to any individual; standing follows the merit of the contribution |
| **Task Force** | Cross-document conflicts, editor appointments, milestone dates, new RFC approval | The working group that formed at RFC #1 |

Normative pull requests require review by **two spec editors**. Normative changes must use RFC 2119 / RFC 8174 keywords and state compatibility impact. Merged decisions are written into the `GOVERNANCE.md` decision log with a one-paragraph rationale and a link to the originating thread.

<Note>
Comment-cycle mechanics, Discussion vs Issue vs PR routing, and the `errata` label for RFC #1 belong on the contributing and review pages. This page defines who may judge consensus and who may publish.
</Note>

## Rough consensus

The responsible editor judges consensus. The test is not unanimous agreement. It is whether every objection has been considered and either addressed or explicitly overruled with recorded rationale. Sustained objections stay in the decision log even when overruled. There is no vote.

```text
Raise (Discussion or Issue)
        │
        ▼
Converge (editor summary → rough consensus on direction)
        │
        ▼
Review (PR; two editors on normative text)
        │
        ▼
Record (GOVERNANCE.md decision log + thread link)
        │
        ▼
Run (Phase 0+ implementation reports inform the next revision)
```

## Decision log

The log is the durable record of Task Force and editor decisions. Current entry:

| Date | Decision | Rationale | Thread |
|---|---|---|---|
| 2026-08 | Publish RFC #1; decompose into living specs (this repository structure) | Separate the immutable narrative from evolving normative text; give the community focused surfaces for comment | — |

Protocol versions use a **YY.N** scheme (26.0 is the first 2026 line). G2P, GCAP, and DESP version independently. Status headers on living files are `Draft — seeking input`, `Proposed`, or `Stable (vXX.Y)`. Compatibility statements are required when Stable text changes.

## Licenses

© 2026 The Grid 2.0 Task Force.

| Material | Outbound license | File | Inbound grant |
|---|---|---|---|
| Specification text and other non-code work | Creative Commons Attribution 4.0 International (CC BY 4.0) | `LICENSE` | Submitting an Issue, Discussion post, or pull request licenses that contribution under CC BY 4.0 and allows incorporation into G2TF publications with attribution |
| Code | Apache License 2.0 | `LICENSE-CODE` | Any code that emerges in this work is Apache-2.0 |

This tree is specification-only today: there is no implementation source under `LICENSE-CODE`. The Apache-2.0 file is the binding license for code when it appears.

### CC BY 4.0 on specification text

`LICENSE` is the Creative Commons Attribution 4.0 International Public License. Recipients may reproduce and share the licensed material, and produce adapted material, worldwide and royalty-free, subject to attribution. Patent and trademark rights are **not** licensed under CC BY 4.0. The public license does not grant endorsement by the Licensor.

When sharing licensed or adapted spec text, retain creator identification, the copyright notice, a reference to the public license, the warranty disclaimer, and a URI to the material when practicable; mark modifications.

### Apache-2.0 on code

`LICENSE-CODE` is Apache License 2.0 (January 2004). It grants a copyright license to reproduce, prepare derivative works, display, perform, sublicense, and distribute, plus a patent license limited to claims necessarily infringed by a contributor’s contribution (alone or with the Work). Instituting patent litigation alleging the Work or a contribution infringes terminates that patent license.

Redistribution must include a copy of the license, prominent change notices on modified files, retained notices, and a readable copy of attribution notices from `NOTICE.md` where that file is distributed. Apache-2.0 does **not** grant permission to use the licensor’s trade names, trademarks, service marks, or product names except for reasonable and customary description of origin and reproduction of NOTICE content.

Both licenses deliver the work **AS IS**, without warranties of title, non-infringement, merchantability, or fitness.

### Attribution of contributors

Substantive contributors are acknowledged in subsequent RFC publications, following RFC #1’s acknowledgments section. That is the `CONTRIBUTING.md` acknowledgment process referenced by `NOTICE.md`.

## Trademarks

The following marks are trademarks of the Grid 2.0 Task Force:

| Mark | Owner |
|---|---|
| "Grid 2.0"™ | Grid 2.0 Task Force |
| "G2TF"™ | Grid 2.0 Task Force |
| "G2P"™ | Grid 2.0 Task Force |
| "GCAP"™ | Grid 2.0 Task Force |
| "DESP"™ | Grid 2.0 Task Force |

<Warning>
**No trademark rights are granted** by CC BY 4.0 or Apache-2.0. A trademark usage policy for describing conformant implementations is forthcoming from the Task Force and will be published in this repository. Until that policy exists, do not treat either copyright license as permission to brand a product as Grid 2.0, G2TF, G2P, GCAP, or DESP.
</Warning>

## Relationship to Grid 1 regulators and formal standards

Grid 2 is **voluntary** and sits inside existing Grid 1 rules. G2TF coordinates with, and does **not** supersede, NERC, FERC, utility, and TSO/ISO requirements. Participating assets continue to meet those requirements in their Grid 1 context. Authority for constraint inputs is anchored in the utility transmission owner, not in the protocol.

Alignment work with IEEE 2030.5 and related standards is tracked in GitHub Discussions. Design principles treat broader (for example FERC-level) recognition as something to pursue after a local path is proven (Phase 0 shadow mode → Phase 1 local integration → Phase 2 federation), not as a prerequisite for the overlay.

A companion document covering detailed regulatory and engineering concerns is in development with focused stakeholder outreach, including:

- Hyperscalers, utilities, and state regulators under committed contracts
- Research labs including EPRI, Purdue, Duke, Emerald.ai, GridCare, Nvidia
- ERCOT, SPP, PJM, MISO
- NERC, FERC, DOE
- The international community via the World Economic Forum

<Note>
Non-interference, “coordination without prices,” and the v26.0 energy-in-the-interval scope are protocol facts, not governance process. See Overlay and Grid 1 for those rules.
</Note>

## Next

<CardGroup>
  <Card title="Document lifecycle" href="/document-lifecycle">
    Draft → Proposed → Stable → RFC, YY.N versions, compatibility statements, and the decision log.
  </Card>
  <Card title="Contributing" href="/contributing">
    Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions.
  </Card>
  <Card title="Comment, review, and file errata" href="/comment-and-errata">
    Discussions vs Issues vs PRs, RFC #1 errata, two-editor review, and recording decisions.
  </Card>
  <Card title="Overlay and Grid 1" href="/overlay-and-grid-1">
    Overlay membership, NERC/FERC/TSO non-interference, and coordination without prices.
  </Card>
</CardGroup>

---
