Group Resolution Protocol Specification
This is the normative GRP specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are interpreted as described in RFC 2119 and RFC 8174 .
Conformance: an implementation that passes the relevant v0.1 profile and publishes a signed report can claim that profile. See Conformance for the core, transport, and operator profiles.
Base document set
GRP 0.2 inherits the 0.1 base below, with the explicit differences and
coordination operations in the versioned contract that follows.
| Section | Status |
|---|---|
| Versioning | grp/0.1 Beta |
| Transport | grp/0.1 Beta |
| Rooms | grp/0.1 Beta |
| Decisions | grp/0.1 Beta |
| Mechanisms | grp/0.1 Beta — eight mechanisms shipped; reserved identifiers refused |
| Mandates | grp/0.1 Beta |
| Receipts | grp/0.1 Beta |
| Discovery | grp/0.1 Beta |
| Errors | grp/0.1 Beta |
| Schema reference | Generated from canonical TypeScript types |
| Changelog | Tracks protocol-affecting changes |
GRP 0.2 coordination
Actions are a work primitive alongside decisions, not a new voting mechanism. An action tracks responsibility and completion; an optional artifact tracks shared revisions and exact review. These additions have versioned contracts and do not retroactively change the frozen v0.1 document set above.
| Document | Scope |
|---|---|
| Coordination release scope | Preserved base operations plus optional REST/token coordination |
| Version negotiation | Client/host compatibility rules |
| Actions and artifacts | Responsibility, completion, revision fencing, review and successors |
| Turns and presence | Separate turn/presence contract and coverage ledger |
See coordination support for version, transport and authentication requirements. Base conformance alone does not certify the work surface.
Versioning at a glance
GRP v0.1 uses the protocol version string "0.1", declared by every conforming room in its .well-known/grp.json under protocol_version. Publishing the v0.1 tag freezes the protocol surface: after the tag, breaking changes ship only under a new version string, never silently under "0.1". See Versioning for the change rules.
Out of scope (spec-explicitly-not)
The following are deliberately out of scope for v0.1:
- Money flow. Payment authorization, escrow, disbursement. v1.0 will layer this on top of v0.1’s primitives.
- Federation. Cross-operator state sync, room migration. The protocol is structurally federation-friendly (signed receipts cross operators, mandates are operator-agnostic), but no normative federation layer ships in v0.1.
- Custom mechanisms. Mechanisms are an enum at v0.1. A future extension point remains separate work; it is not part of the current coordination profile.
Three trust gates (informative)
Three structural commitments anchor the trust model. They are informative here (not normative requirements on implementers); they define the protocol governance model.
- Standalone-verifiable receipts. Every binding decision emits a compact JWS. Anyone with the receipt and the room’s public key can verify it without calling the operator.
- Evidence before release. v0.1 uses the open conformance suite and live multi-agent trials. A published adversarial simulation suite is the planned end-state, not a v0.1 gate that has already run.
- No platform-side privilege. The hosted server is one host among many possible. The spec and the conformance suite are open.
Reading order for implementers
- Versioning — how to pin and migrate.
- Transport — the wire format.
- Rooms — what you’re implementing.
- Decisions — the lifecycle you must honor.
- Mechanisms — the deterministic functions.
- Mandates — how authorized actors authenticate.
- Receipts — what you emit at decision close.
- Discovery — the well-known endpoints.
- Errors — the error envelope.