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.
Implementation order
Twelve ordered steps. They declare what to build, in which order, with which tests first — they do not start coding. Order rationale: identity and isolation first, because every later feature depends on the policy pipeline; the transactional-outbox contract at the foundation so every event-producing mutation uses it; the delivery worker after the records it announces; operations and UAT last.
| Step | Name | Primary scenarios | Decisions DG must settle (dependent behaviour blocked until DG chooses) |
|---|---|---|---|
| 01 | Foundation and outbox contract | 2 | Q09, Q11 |
| 02 | Identity, membership and roles | 7 | Q01, Q02, Q07, Q08, Q09, Q19 |
| 03 | Policy pipeline and isolation harness | 5 | Q07, Q08, Q09, Q16 |
| 04 | Opportunities, versions and approvals | 7 | Q02, Q06 |
| 05 | Discovery and rule ranking | 2 | Q03 |
| 06 | Questions, interest, discussions and actions | 12 | Q02, Q04, Q05, Q07, Q08, Q09, Q10 |
| 07 | Outbox delivery worker and email | 4 | Q07, Q08 |
| 08 | Daily tracking views | 2 | Q10 |
| 09 | DG membership tool and metadata | 0 | Q08, Q19 |
| 10 | Hardening and operations | 2 | Q09, Q11 |
| 11 | UAT and release | 0 | Q11 |
| 12 | Manual DG services and scope guards | 41 | Q02, Q05, Q08, Q09, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q25 |
How to read the order
- The primary-step mapping is an index, not proof that a full scenario can be completed there. Many scenarios need components from later steps; see Dependency-and-Regression-Table. Each step lists its deferred integration checks and the earlier scenarios it lets you finish.
- A software scenario’s full status cannot be recorded as Passed until every relevant variant has been exercised on a named integrated build (Step-11-UAT-and-Release). Purely manual portions instead use approved procedure/charter and consent-template revisions, fixture, staff roles, date and observed result; mixed cases need both evidence streams (Mixed-Evidence-Disposition).
- Manual DG services are a parallel track that needs no application build for a purely manual scenario; (Step-12-Manual-DG-Services-and-Scope-Guards). Approval of each manual procedure is a pre-sale / pre-real-data gate; DG can start reviewing charters from day one, and nothing waits for software launch.
Preconditions before any step
- A proposed default is a recommendation, never a prerequisite: policy-independent scaffolding may start after the overall start conditions, but decision-dependent behaviour and its final oracle stay blocked until DG chooses.
- Option selected and statement of work agreed; Balanced remains proposed. Fees and dates open (Delivery-Options-Comparison, Provisional-Schedule).
- Ready-to-start kickoff checklist met: decisions affecting the first milestone resolved, funded DG-owned accounts, region and identity provider chosen, domain/DNS authority, named acceptance reviewer and launch approver, sanitised examples, review windows.
- Staffing confirmed (two dedicated engineers is an assumption, not a fact).
Rules for every step
- Test first; keep scenario IDs stable.
- Deny by default; check authorisation on every read, mutation, search, count, export and job.
- A scenario with a pending decision is not given an invented oracle.
- Software evidence names the build and fixture; authored Gherkin is not a passing suite. Purely manual evidence names the procedure/charter and consent-template revisions, synthetic fixture, staff roles, date and observed result, with no application-build requirement. Mixed evidence stays split; neither stream substitutes for the other.
- Software scope changes need a written change request (Scope-Balanced-Manual-Additional).
Traceability: Traceability-Matrix.