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 04 · Partner intake, listings and operations review

Goal. Approved partners and owner-backed listings, the lifecycle, operations review and the approved public projection.

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

Former 1.3 name: Opportunities, versions and approvals. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-04 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 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: GL06-staged, GQ02-staged, GQ06-staged, GQ07-staged, Q02, Q06.

Changes (illustrative, not a final schema)

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

Build items:

• Partner records and approval; only an approved partner publishes through review (pp. 5, 13)
• Listing with separate public, member and restricted payloads and internal metadata (p. 5)
• Lifecycle: draft, in review, published, changes requested, expired or paused, closed or rejected; submit does not publish (p. 5)
• Operations review with reason and expected_version; the approved version is stored apart from the editable draft; only the approved public projection is rebuilt (pp. 5, 14)
• Material amendment pauses the live listing until re-approved; expiry removes it from active projections and APIs enforce expiry independently (pp. 5, 16)
• Configurable categories; submitter confirms authority to share; screening for misleading claims, confidential names and duplicates (p. 5)
• Unavailable notice at the original URL; projection invalidation on withdrawal (pp. 5, 17)

Expected outputs and invariants

A partner cannot self-approve or edit another owner’s listing; an expired or changed offer cannot accept pitches; names appear publicly only when explicitly approved.

Tests-first subset

Primary scenarios of this step (write these tests first): T05, T13, T14, T15, T21, T22, T23, DG34, DG38, DG39, DG42, GS02-staged, GS08-staged, GS09-staged.

Assertions to write first: new GGA scenarios GS02-staged, GS08-staged, GS09-staged. Legacy scenarios whose primary step is this one: T05, T13, T14, T15, T21, T22, T23, DG34, DG38, DG39, DG42. 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:

• T05: needs step 05 (through GS01, GS08).
• T21: needs step 06, 07 (through GS09).
• T22: needs step 06, 07 (through GS09).
• T23: needs step 06, 07 (through GS09).
• DG34: needs step 06, 07 (through GS08, GS10).
• DG38: needs step 06, 07 (through GS09).
• DG39: needs step 05 (through GS01, GS08).
• DG42: needs step 05 (through GS02).
• GS02-staged: needs step 05. The public URL and cache behaviour need the public routes (05).
• GS09-staged: needs step 06, 07. Existing-pitch handling (06) and expiry jobs (07).

Follow-up verification brought here

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

• GS17-staged: Routes are added in 04, 06 and 09; extend the matrix each time.
• GS32-staged: Listing review labels need operations review (04).

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

GL06-staged, GQ02-staged, GQ06-staged, GQ07-staged, Q02, Q06

Exit evidence

An operations user can review and publish a synthetic listing and the approved projection is the only public source; GS08 can be verified here; GS02 is verified in part until the public routes (05) exist and GS09 until pitches (06) and expiry jobs (07) exist.

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-03-Policy-Pipeline-and-Isolation-Harness ← this step → Step-05-Discovery-and-Rule-Ranking · Implementation-Order-Overview