Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Step 02 · Identity, membership and roles
Goal. Invitation-only accounts, one company per user, fixed roles, assignment and reassignment.
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
Step 01. Policy-independent scaffolding may start only after the overall start conditions are met (statement of work, ready-to-start kickoff checklist, funded DG-owned accounts, region and identity provider chosen). Decision-dependent behaviour and its final oracle stay blocked until DG chooses the applicable rule. Proposed defaults are recommendations, never prerequisites. Any provisional synthetic exploration must be labelled reversible and unapproved and is not accepted production behaviour. Blocked until DG decides: the one-company-per-user rule and second-invitation handling (Q01), the role, assignment and approval matrix (Q02), and intake states (Q19). Policy-independent here: record structures, invitation delivery mechanics, test fixtures.
Changes (illustrative, not a final schema)
Records for users, companies and company-scoped memberships; invitation claim states; role and assignment records. Illustrative.
Build items:
- User, company, membership (company/user/role)
- Invitation claim rules; atomic race outcome
- Roles owner/admin, approver, contributor, viewer
- Assignment eligibility and reassignment mechanics
Expected outputs and invariants
At most one active company membership per user; an invitation race has one atomic winner; roles and assignment are enforced server-side; denials change no existing assignment.
Tests-first subset
Primary scenarios of this step (write these tests first): T01, T02, T03, T04, T26, DG25, DG26.
Assertions to write first: T01, T02 (team and assignment rows), T03 (role/assignment scoping on identity fixtures), T04 (eligibility), T26 (live-policy reads on identity fixtures), DG25.
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 Pending 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 03: Re-check the safe-denial shape and audit once the pipeline exists.
- T02 — needs step 04, 06: Publish (04) and formal-interest submit, accept and message (06) rows complete the matrix; cells depending on pending Q02 stay Pending decision.
- T03 — needs step 06: Admin visibility of A-B and A-C engagements needs private engagements, messages and actions.
- T04 — needs step 06, 07: Moving a question and an action needs step 06 records; reassignment notification behaviour needs step 07 and Q07 (no new event type assumed).
- T26 — needs step 07: Recipient choice for queued mail needs the worker and Q07.
- DG26 — needs step 09: Guest, pending, approved, rejected and revoked operations depend on the DG membership tool (09) and the signed Q19 policy.
- DG25 — needs step 03: Safe-denial and audit re-check once the pipeline exists.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- T37 — Needs actual identity, role and revocation behaviour (02, 03), protected DG admin operations with MFA (09) and an integrated recheck (11).
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
Allow/deny matrix for identity actions reported with positive controls. For T02, T03, T04 and T26 only partial verification is possible until the publish, engagement and worker features 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