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 02 · Identity, membership, company profile and eligibility

Goal. Registration, company creation, owner-issued invitations, the profile workspace with versions and attestation, the freshness clock and the eligibility function.

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

Former 1.3 name: Identity, membership and roles. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-02 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 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: GL03-staged, GL04-staged, GQ03-staged, Q01, Q19, Q20, GL07-staged.

Changes (illustrative, not a final schema)

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

Build items:

• Verified registration; create a company or accept an owner-issued invitation; a matching email domain never grants access; duplicate-company support that reveals no member (pp. 4, 10, 14)
• Company, membership and owner records; one active owner; owner transfer needs confirmation (pp. 4, 13)
• Profile workspace: draft autosave, required-field checklist, revenue period and currency, evidence upload record, structured missing-field errors (pp. 4, 10, 14)
• Profile versions, attestation, due date and expected-version checks; an older draft cannot overwrite a newer confirmed profile (pp. 4, 7, 13, 15)
• Eligibility derived at request time from timestamps and review status; contribution status absent from the expression (p. 3)
• Evidence status labels: supplied versus GGA-checked; a complete profile is not ‘verified’ (pp. 2, 4)
• File upload record with classification and scan state; allowlist, content sniffing, size limit (pp. 13, 17)

Expected outputs and invariants

No browser-supplied eligibility flag is trusted; the freshness boundary holds without any scheduled job; business edits create a new version that is unused until confirmed.

Tests-first subset

Primary scenarios of this step (write these tests first): T01, T04, T08, T31, DG02, DG25, DG26, DG28, DG35, GS03-staged, GS04-staged, GS06-staged, GS07-staged, GS18-staged, GS31-staged, GS32-staged.

Assertions to write first: new GGA scenarios GS03-staged, GS04-staged, GS06-staged, GS07-staged, GS18-staged, GS31-staged, GS32-staged. Legacy scenarios whose primary step is this one: T01, T04, T08, T31, DG02, DG25, DG26, DG28, DG35. 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:

• T01: needs step 07 (through GS04).
• T04: needs step 03, 04, 06, 09 (through GS17).
• T31: needs step 07 (through GS06).
• DG02: needs step 04 (through GS32).
• DG25: needs step 07 (through GS04).
• DG26: needs step 07 (through GS03, GS04).
• DG28: needs step 04 (through GS32).
• DG35: needs step 07 (through GS04).
• GS04-staged: needs step 07. Invitation email delivery needs the worker (07).
• GS06-staged: needs step 07. Reminder jobs and old-cycle stop need the worker (07).
• GS18-staged: needs step 06. Grant-checked sharing and download need introductions (06).
• GS31-staged: needs step 05, 06, 08, 10. Every screen must be exercised; final audit in 10.
• GS32-staged: needs step 04. Listing review labels need operations review (04).

Follow-up verification brought here

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

• None.

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

GL03-staged, GL04-staged, GQ03-staged, Q01, Q19, Q20, GL07-staged

Exit evidence

Registration, profile, attestation and eligibility behave on a named build with the clock controlled and jobs disabled; GS03 and GS07 can be verified here; GS04, GS06 and GS32 are verified in part until invitation email and reminder jobs (07) and listing review (04) 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-01-Foundation ← this step → Step-03-Policy-Pipeline-and-Isolation-Harness · Implementation-Order-Overview