GGA Exchange vault

Step 06 Pitches, consent and introductions

4 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.

Step 06 · Pitches, consent and introductions

Goal. Scoped pitches, the owner decision, two-party consent and the one-time contact release.

Blueprint delivery stage: Stage 3 (Delivery-Options-Comparison).

Former 1.3 name: Questions, interest, discussions and actions. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-06 label stay valid.

Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.

Prerequisites

Steps 01, 02, 03, 04, 05 as needed by the table in Dependency-and-Regression-Table; the strict prerequisite is the previous step’s exit evidence. Policy-independent scaffolding may start after the overall start conditions; decision-dependent behaviour and its final oracle stay blocked until the named authority decides. Proposed defaults are recommendations, never prerequisites. Blocked decisions: GL04-staged, GQ04-staged, GQ07-staged, Q05, Q07, Q14.

Changes (illustrative, not a final schema)

Sources: Blueprint pages cited per item (GGA-Requirement-Register).

Build items:

  • Pitch with fit statement, proposed next step and applicant-approved fields; never attach the full profile (pp. 6, 10, 14)
  • One open interest per company per opportunity (proposed default) with idempotent retry (pp. 6, 12, 14)
  • Owner accept or decline; one pending introduction per interest; consent request with expiry (pp. 6, 15)
  • Consent record bound to introduction, recipient, fields and files, purpose, version and expiry; package change invalidates approvals (pp. 6, 13)
  • Release transaction: both approvals current, both users authorised, listing active, applicant eligible; release once; one delivery per recipient (pp. 6, 15)
  • Withdrawal before release; after release revoke future access and keep an accurate history (pp. 6, 15)
  • Operations may remind but cannot consent for a participant (p. 6)

Expected outputs and invariants

Two simultaneous accepts create one introduction; no contact appears before both current approvals; replays create no second grant.

Tests-first subset

Primary scenarios of this step (write these tests first): T10, T16, T17, T18, T19, T25, T32, DG04, DG07, DG08, DG10, DG11, DG17, DG20, DG21, GS10-staged, GS11-staged, GS12-staged.

Assertions to write first: new GGA scenarios GS10-staged, GS11-staged, GS12-staged. Legacy scenarios whose primary step is this one: T10, T16, T17, T18, T19, T25, T32, DG04, DG07, DG08, DG10, DG11, DG17, DG20, DG21. Each follows its replacing GS scenario; the 1.3 text is history (Scenario-Dispositions).

Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Blocked by that decision; no oracle is invented.

Deferred integration checks

Scenarios whose primary step is this one but whose full variants need later components:

  • T10: needs step 07, 09 (through GS10, GS17).
  • T16: needs step 07 (through GS11, GS12).
  • T17: needs step 07 (through GS10).
  • T18: needs step 07 (through GS10, GS12).
  • T19: needs step 07 (through GS11, GS12).
  • T25: needs step 07, 09 (through GS11, GS17).
  • T32: needs step 07, 09 (through GS11, GS17).
  • DG04: needs step 07 (through GS11).
  • DG07: needs step 07 (through GS11).
  • DG08: needs step 07 (through GS11).
  • DG10: needs step 07 (through GS11).
  • DG11: needs step 07 (through GS11).
  • DG17: needs step 09 (through GS12, GS23).
  • DG20: needs step 07 (through GS11).
  • DG21: needs step 07, 09, 10 (through GS11, GS27).
  • GS10-staged: needs step 07. A published listing (04) is needed to pitch against; the owner notification after a new pitch needs the worker (07).
  • GS11-staged: needs step 07. Delivery of the contact package needs the worker (07).

Follow-up verification brought here

Scenarios (of any step) that can only be completed or rechecked once this step exists:

  • GS05-staged: Enforcement on discovery (05), pitch (06) and registration (08).
  • GS09-staged: Existing-pitch handling (06) and expiry jobs (07).
  • GS17-staged: Routes are added in 04, 06 and 09; extend the matrix each time.
  • GS18-staged: Grant-checked sharing and download need introductions (06).
  • GS31-staged: Every screen must be exercised; final audit in 10.

Decisions GGA must settle (dependent behaviour stays blocked until the named authority decides)

GL04-staged, GQ04-staged, GQ07-staged, Q05, Q07, Q14

Exit evidence

A synthetic introduction is released once with canary fields confined to the approved scope; GS12 can be verified here; GS10 and GS11 are verified in part until the worker (07) delivers.

Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).

Navigation: Step-05-Discovery-and-Rule-Ranking ← this step → Step-07-Outbox-Worker-Email · Implementation-Order-Overview

Graph View