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 12 · Manual DG services and scope guards
Goal. Not software to program. DG staff procedures that need rehearsal and evidence, plus tests that stop service ideas from expanding software scope. This is a parallel track with its own pre-sale / pre-real-data gate, not a stage after software launch.
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
Parallel track; it does not wait for software steps. Each procedure stays blocked until DG decides the rules that apply to it (Q12–Q25) and approves storage, access and retention for any real data (Q16) and a staff owner and alternate (Q15). Proposed defaults are recommendations, never prerequisites.
Changes (illustrative, not a final schema)
No software change. Charters, consent forms, receipt templates, complaint routes and staff rehearsal scripts.
Build items:
- Charters, consent forms, receipts and complaint routes
- Staff rehearsal with synthetic cases
- Scope guards DG24 and DG44 enforced in review
Expected outputs and invariants
DG must approve each procedure before any service is sold or any real company data is used; software scope stays unchanged unless a change request is approved.
Tests-first subset
Primary scenarios of this step (write these tests first): DG01, DG02, DG03, DG04, DG05, DG06, DG07, DG08, DG09, DG10, DG11, DG12, DG13, DG14, DG15, DG16, DG17, DG18, DG19, DG20, DG21, DG23, DG24, DG27, DG28, DG29, DG30, DG31, DG32, DG33, DG34, DG35, DG36, DG37, DG38, DG39, DG40, DG41, DG42, DG43, DG44.
Assertions to write first: DG01–DG21, DG23, DG24, DG27–DG44 as staff rehearsals and review checks, not application tests. A purely manual service scenario needs no application build.
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:
- Manual/document assertions may be rehearsed independently after procedure approval. Full mixed scenarios also need the linked application evidence; see Mixed-Evidence-Disposition and Dependency-and-Regression-Table.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- None.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Q02, Q05, Q08, Q09, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q25
Exit evidence
Per-procedure approval record and rehearsal evidence: the approved procedure/charter revision, consent-template revision, synthetic fixture, staff roles, date and the recorded observed result. This track starts in parallel with software step 01: DG can review charters from day one, and nothing here waits for software launch. No application build is required for a purely manual service scenario.
Evidence for a manual service scenario is the approved procedure/charter revision, the consent-template revision, the synthetic fixture, the staff roles, the date and the recorded observed result. No application build is required for a purely manual service scenario, and calling a manual procedure implemented software is wrong. All manual/software evidence splits are listed in Mixed-Evidence-Disposition, including indirect ranking, publication, admin-access and revocation dependencies. The manual portion is still rehearsed by staff; linked software assertions require their own named-build evidence. Software UAT and acceptance stay limited to the agreed Balanced annex; these cases are not a software payment gate.
Navigation: Step-11-UAT-and-Release ← this step → — · Implementation-Order-Overview