# Document lifecycle
> Draft to Proposed to Stable to RFC, YY.N protocol versions, required compatibility statements, and the GOVERNANCE.md decision log.
- Repository: g2tf-org/g2tf-standards
- GitHub: https://github.com/g2tf-org/g2tf-standards
- Human docs: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff
- Complete Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/llms-full.txt
## 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`.
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.
## 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 |
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.
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`.
Editors responsible for the document. Currently `TBD` on every living file that lists the field.
Citation back to RFC #1 (section or table). Present on architecture and member files.
Present on the three protocol specs. Positions the file in the DESP / GCAP / G2P stack; it is not a maturity field.
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
Open a Discussion for a question or alternative, or an Issue for a defect (ambiguity, contradiction, RFC #1 errata, missing normative requirement).
Editors summarize positions. When a direction has rough consensus, an editor or the proposer opens a PR against `specs/`, `members/`, or `architecture/`.
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.
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.
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/`.
Implementations from Phase 0 shadow mode onward report experience in Discussions. Running code informs the next revision of the living files.
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.
## 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
Status headers, RFC 2119 keywords, living files versus immutable RFCs, and independent 26.x lines.
Discussions versus Issues versus PRs, the `errata` label, two-editor review, and decision-log recording.
Open participation, comment-cycle steps, writing conventions, and Phase 0 implementation reports.
Editor, contributor, and Task Force roles; rough consensus; licenses; and the Grid 1 regulator relationship.