GGA Exchange vault

Versions, approvals and state transitions

5 min read

Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.

Versions, approvals and state transitions

Sources: Blueprint pp. 4 to 6, 12, 15 (GGA-Requirement-Register); retained 1.3 findings on exact-version approval and stale writes.

Opportunity lifecycle

flowchart LR
  D[Draft] -->|owner submits complete version| R[In review]
  R -->|operations approves| P[Published]
  R -->|requests changes| CR[Changes requested]
  CR -->|owner revises and resubmits| R
  R -->|rejects with reason| X[Rejected]
  P -->|owner pauses| PA[Paused by owner]
  P -->|expiry reached| E[Expired]
  P -->|owner closes| CL[Closed]
  P -->|material amendment| MA[Paused pending re-approval]
  MA -->|operations re-approves| P
  PA -->|owner resumes: Blueprint silent, Proposed| P
  E -->|owner reconfirms; review if the content changed| P
  CL -->|reopen: review and new expiry| R
  X -->|new version| D
  • Published: eligible companies may submit interest until expiry; the owner can pause or close immediately.
  • A material amendment to a live offer pauses the affected listing until re-approved (Blueprint p. 5). This replaces the 1.3 rule that V1 stays live while V2 is reviewed, with its separate live-version pointer (owner direction N4). The earlier behaviour is kept as history only.
  • Expired or paused listings leave active discovery; the original URL shows a non-sensitive unavailable notice; new interests are blocked. An expired listing returns only after its owner reconfirms it (Concept and Architecture); review is required for a material change (p. 16) and for reopening closed or rejected content (p. 5). Whether every unchanged reconfirmation also needs operations review is not stated and stays open.
  • Closed or rejected listings keep restricted history for authorised participants and operations. Reopening needs review and a new expiry.
  • The approved version is stored separately from the editable draft. Search, social previews and public APIs use only the approved public projection.

Profile

Editing business content creates a new version that needs owner confirmation before use. Attestation recomputes due_at and eligibility atomically. An older draft cannot overwrite a newer confirmed profile.

flowchart LR
  I[Interest submitted<br/>scoped pitch] -->|owner declines| D[Declined]
  I -->|owner accepts| P[Pending introduction<br/>owner consent recorded]
  P -->|applicant consents, all checks current| R[Released once<br/>grants and notices queued]
  P -->|withdrawal, timeout 14 days, or package change| C[Closed, nothing released]

Owner accepts (Blueprint p. 15): confirm listing ownership and an active offer; create one pending introduction for the interest; record the owner’s scoped consent; queue the applicant’s consent request. No contact has been released.

Release (pp. 6, 15): in one transaction lock the pending introduction and the consent versions, then re-check that both approvals are current and bound to the introduction, recipient, fields and files, purpose, version and expiry; that both users remain authorised; that the opportunity is active; and that the applicant is still eligible. Mark the introduction released and create the grants and notification records exactly once, one delivery per recipient. Changing the package invalidates earlier approvals. A pending request expires after 14 days (proposed default); the owner may close sooner; operations may remind but cannot consent for a participant.

Withdrawal: before release it cancels the pending consent and any release job in the same transaction; after release it revokes future grants where applicable and the accurate history of what was already shared is kept.

Contribution

Value reported, then company confirms, then explicit opt-in, then finance-approved invoice, then settlement, then a dated 12-month term. Renewal needs a fresh decision (Blueprint pp. 8, 15). Voids, refunds and corrections are finance actions with a recorded reason and kept history; a duplicate payment never creates a second term; a partial, disputed or mismatched payment stays a finance exception; renewal invoices are scheduled at or after the current term ends and an unexpected early payment goes to finance review (pp. 8, 15).

Rules retained from 1.3

Every sensitive update carries the expected record version; a stale write gets a safe conflict and the last approved content stays (T14, T15). Editing after approval invalidates that approval; a formal submission binds the approved version and the actor’s authority (T13). Interest records keep the opportunity version the applicant saw and a material change gives each existing interest its own safe notice; a company cannot pitch its own listing (both Proposed carry-forwards from 1.3, no GGA feedback; T21, T22). A race such as accept versus withdraw is one serialised transition and the loser gets a safe “state changed” conflict (T18, T19). Idempotency binds actor and action (GGA p. 15; 1.3 also bound attempt and payload); a changed payload with the same key fails; authorise before replaying any stored result.

Superseded or open

The 1.3 lifecycle matrix (question threads, discussion states, pause behaviour for threads) has no GGA feedback; it is a Proposed carry-forward (Q04). Self-approval by an entitled company owner is superseded: operations review is mandatory before publication; a partner cannot self-approve (Blueprint p. 18, A4).

Graph View