Consolidated Milestone Summary — Verified Digital Credentials Platform (M1–M10)¶
As of: 13 Aug 2026 — kickoff held, POC demo delivered, client satisfied. Full task breakdown audited line-by-line against SOW Appendix 1 (Requirements Specification) and Appendix 2 (Deliverables/Milestones) on 13 Aug 2026. Source: SOW v0.3 (10 Aug 2026) Appendix 1 & 2, cross-checked against the earlier v3 High-Level Requirements document and the current POC codebase.
Overall picture¶
| Milestone | Feature Area | Requirement Clarity | Build Status |
|---|---|---|---|
| M1 | Planning & onboarding | ⚠️ 12 open items below | ⚪ Process milestone |
| M2 | Platform & client admin | 🟡 1 open item (KYB phasing) | 🟢 Largely built in POC |
| M3 | Issuing functionality | ✅ clear | 🟢 Best-covered area overall — bulk credential issuance gap closed 2026-08-17 (see below) |
| M4 | v0.1 Beta release | ✅ clear | 🟡 Live on a single AWS EC2 instance since 2026-08-17 — client-testable, but the final production hosting target (this vs. ECS/Elastic Beanstalk) is still unconfirmed |
| M5 | Disclosure & Verification | ⚠️ 7 open items (4 from SOW text, 3 found via wireframe cross-check) | ❌ Not started |
| M6 | v0.2 Beta release | ✅ clear | ❌ Depends on M5 |
| M7 | Reclaim Protocol | ⚠️ new scope, needs sign-off | ❌ Not started |
| M8 | v0.3 Beta release | ✅ clear | ❌ Depends on M7 |
| M9 | Hardening & Compliance | 🟡 4 open items | ❌ Not started |
| M10 | Go-live & Handover | ⚠️ acceptance-sequencing ambiguity | ❌ Not started |
Corrections from code audit (not requirement ambiguity — verified against actual code)¶
- The formally-numbered SOW cited throughout these milestone docs (FR1–FR8, NFR1–NFR6, OR1–OR3, INT1–INT8, Appendices 1–6, deliverables D1–D8, a named Acceptance Lead) could not be located anywhere in this repository — found 2026-08-20 while researching M5. Both PDFs present in the repo (
REC Verifiable Credentialing Platform High-level Requirements v3.0.pdfandREC_Platform_RFP_For Distribution_6 Mar 2025.pdf) were checked directly, including the v3.0 doc's image-only Appendix pages (read via OCR-equivalent visual inspection, since they're embedded as pictures, not text). Neither contains that numbering scheme or the named individuals cited in the milestone docs' "per SOW Appendix 3, FR2 acceptance criteria"-style references. This means every such citation across all ten milestones is currently unverifiable against any file in the repo — it may describe a real, separate formal SOW document that was never committed here, or the numbering may have been introduced by whoever first wrote these task breakdowns without a source file to check against. Worth confirming with Curo/NeuralRays which is the case; see M5-00 for where this was found. - M3-03 — CSV batch credential upload: gap identified 2026-08-16, closed 2026-08-17. The original gap was real:
employee.service.ts'sbulkUploadCsv()only ever createdEmployeeDB rows, with no call into Velocity/CIH. That's now superseded by a dedicatedBulkIssuanceService/BulkIssuanceProcessorpipeline (app/backend/src/issuer/services/bulk-issuance.service.ts,.../processors/bulk-issuance.processor.ts, migration1784100000000-CreateBatchIssuanceTables.ts) that queues each row as a BullMQ job and calls the sameManualCredentialService.createManualCredential()the single/manual issuance form already used — so bulk-issued credentials go through identical CIH calls, validation, and claim-email delivery as a manually issued one. This is a different architecture than the@velocitycareerlabs/data-loader/Handlebars pipeline originally spec'd in M3-03, but it satisfies the underlying FR1 requirement (bulk credential issuance) and is wired end-to-end in the frontend (BulkIssueCredentialsForm.tsx: upload → confirm → issue → poll status → retry failed rows).
The open requirement items that matter most¶
- M7 — Reclaim Protocol scope. Not in the original requirements doc at all; internal notes show a client-confirmation request may still be unanswered. This is the single largest block of unscoped work in the plan.
- M10 — Go-live vs. Final Acceptance definition. As written, it's unclear whether "go-live" at M10 refers to the same event as "Final Acceptance," which is separately defined to only occur after the Beta Programme completes.
- M5 — Disclosure policy configuration depth. Original doc deferred this to post-MVP with a default-only policy; SOW reads as full configuration in scope.
- M5 — Credits/vouchers mechanism. Referenced as a milestone line item but never fully specified in the SOW's Requirements Specification.
- M5 — General payment/invoicing capability (NFR5). A distinct requirement from item 4 above — confirm whether manual invoicing is acceptable for MVP; if so, this item may need no development at all.
- M4 — AWS hosting target. A working deployment now exists (single EC2 instance, Docker Compose, Caddy for TLS/routing) as of 2026-08-17 and is being used for client testing — but confirm whether this is the intended long-term production target or a stepping stone to a managed AWS service (ECS, Elastic Beanstalk), since that still affects the CI/CD deploy step and several other tasks (backups, WAF, IaC, monitoring).
- M2 — KYB MVP-vs-Beta phasing. SOW text implies the in-platform KYB web form may only be required by "full Beta release," not the MVP milestone — the current task breakdown builds it outright with no phasing distinction.
- M9 — Regulatory compliance scope (UKDIATF, CCPA, SOC2, UK data retention). Each is named once in NFR3 with no further specification of what compliance activity is actually expected within this SOW.
- M9 — SAML 2.0. Listed as a supported standard in Appendix 6 but not otherwise referenced — confirm it's genuinely required for MVP.
- M9 — D5e release packaging. Unlike M4/M6/M8, M9 has no defined beta version number for its own deployment package.
- M10 — SOW-internal D7/D8 numbering inconsistency. Appendix 3 references a "D8" deliverable that Appendix 2's Deliverables table never defines.
- M2/M9 — Minor dropped specifics. Passkey support, SMS gateway integration, Zendesk-specific help tooling, backup retention/geo-distribution detail, and standalone DDoS requirement status all quietly disappeared between the original doc and the SOW.
- M5 — Verification configuration templates & audit log. A wireframe exists for this (
verification-configuration.html) but nothing in the SOW's written text — confirm whether it's in scope or a later-phase design. - M5 — Batch verification. A wireframe exists (
batch-verification.html) for verifying many credentials at once; the SOW only describes verification generically, with no single-vs-batch distinction. - M5 — Notification preferences. A wireframe exists (
notification-preferences.html) covering event types, delivery channel (including SMS), frequency and quiet hours — none of this is in the SOW text, and it reopens the SMS-channel question from item 12.
Coverage note¶
Every FR (FR1–FR8), NFR (NFR1–NFR6), Other Requirement (OR1–OR3), Integration (INT1–INT8), and Deliverable (D1–D7, plus the D8 inconsistency noted above) in the SOW's Appendix 1 and Appendix 2 has a corresponding task file under one of the ten milestones — including the Functional/Technical Design and Test Evidence deliverables (D2a–d, D4a–d), which were missing from the first pass of this breakdown and have since been added to M2, M3, M5 and M7. Where the SOW itself doesn't give enough detail to define a task with confidence, that's recorded as an open item above and in the relevant task file, rather than filled in with an assumption.
Wireframe cross-check (20 Aug 2026): the SOW/requirements-doc comparison above only covers written text. Cross-checking the docs/design/ui-designs/ wireframe folder against M5 and M7 found three additional M5 features with a real wireframe but no corresponding SOW text or task (items 13–15 above), and confirmed M7 (Reclaim Protocol) has zero wireframes anywhere — nothing to cross-check there, which is itself worth noting given M5's folder turned out to have more content than first accounted for.
Where effort is genuinely already banked¶
M2 and M3 (platform admin + credential issuing) are in good shape — most of their sub-features already have a working prototype from the POC, which is exactly what was demonstrated today.
Where nothing has been built yet¶
M5 through M10 — six of the ten milestones — have no code today, and most of those milestones also carry open requirement questions listed above. Resolving those questions early is the cheapest way to remove ambiguity before build work starts on them.