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 09 · DG membership tool and metadata
Goal. Small membership approval/revocation tool with administrator MFA and a metadata allowlist.
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 02, 03 and 06. 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 DG metadata allowlist and any support access (Q08) and intake states (Q19).
Changes (illustrative, not a final schema)
Membership approval/revocation screens, DG administrator MFA, a metadata-only operational view; intake-state handling for DG26 once Q19 is decided.
Build items:
- Approve/revoke membership; MFA for DG admins
- Metadata-only operational view
- Audit of sensitive changes
- Explicit negative boundary: no private-message browsing; opaque IDs do not grant named oversight
Expected outputs and invariants
DG can approve and revoke membership and see allowed metadata; DG cannot retrieve message bodies; opaque IDs do not grant named oversight.
Tests-first subset
Primary scenarios of this step (write these tests first): none have this step as their primary step.
Assertions to write first: Membership-tool assertions; DG26 intake matrix once policy is signed; completion of T28 and DG22.
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:
- None: the scenarios of this step can be completed here.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- T28 — Message bodies exist only after 06; the DG tool and metadata view (09) complete it.
- T37 — Needs actual identity, role and revocation behaviour (02, 03), protected DG admin operations with MFA (09) and an integrated recheck (11).
- DG22 — Needs engagement records (06) and the DG metadata view (09).
- DG26 — Guest, pending, approved, rejected and revoked operations depend on the DG membership tool (09) and the signed Q19 policy.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
T28 and DG22 verified against real engagement data; DG26 stays Pending decision until Q19 is signed.
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-08-Daily-Tracking-Views ← this step → Step-10-Hardening-and-Operations · Implementation-Order-Overview