M5 — Design and Develop the Disclosure and Verification Functionality¶
SOW Deliverable(s): D2c (Design), D3c (Developed components), D4c (Test evidence) Requirement source: SOW Appendix 1 — FR2 (Disclosure of Credentials), FR3 (Verification of Credentials); INT2, INT4, INT7; NFR5 (credits/vouchers) See also: Flow & UI Reference — the CV Capture sequence diagram, the org-admin decision flow, and a live UI mockup (request creation, verification results, package/email settings), all in one interactive page.
Tasks¶
Every task below starts from zero code, so each file is a design-ahead spec rather than a "move existing doc" — none existed prior to this breakdown.
| ID | Task | SOW Ref | Requirement Clarity | Dev Status | Task File |
|---|---|---|---|---|---|
| M5-00 | (overview) Disclosure & Verification — implementation guide | FR2, FR3 | 🟢 2026-08-26: Velocity's own "CV Capture" spec gives real API endpoints + the "depot" isolation model — read that update section, not the original Part 2 | ❌ Not started | M5-00-disclosure-verification-implementation-guide.md |
| M5-01 | Disclosure request setup by Staffing Company (org-configured "packages": Disclose Credentials, + Right to Work, + Reclaim Employment) | FR2 | 🟡 Updated 2026-08-25 — no longer a single generic request; see task file | ❌ Not started | M5-01-disclosure-request-setup.md |
| M5-02 | Disclosure policy / level-of-assurance configuration | FR2 | 🔄 Reopened 2026-08-25 — was marked resolved on 2026-08-20 ("one generic request, no config"); that's now known to be wrong, Org Admin does configure package combinations | ❌ Not started | M5-02-disclosure-policy-configuration.md |
| M5-03 | Configurable disclosure email + landing page | FR2 | ✅ | ❌ Not started | M5-03-disclosure-email-landing-page.md |
| M5-04 | Follow-up / reminder emails for disclosure | FR2 | ✅ | ❌ Not started | M5-04-disclosure-followup-reminders.md |
| M5-05 | Candidate search & record view (disclosure) | FR2 | ✅ Concrete dashboard spec added 2026-08-25 (name/status/status date/actions table); no longer depends on the now-deleted M3-07 | ❌ Not started | M5-05-candidate-search-record-view-disclosure.md |
| M5-06 | CSV export of disclosure requests & verification status | FR2 | ✅ | ❌ Not started | M5-06-csv-export-disclosure-requests.md |
| M5-07 | Wallet-based disclosure integration | FR2, INT2 | ✅ | ❌ Not started | M5-07-wallet-disclosure-integration.md |
| M5-08 | Verification integration — VerifyMyCreds / Velocity Verification Platform | FR3, INT4 | 🟡 Confirm code-reuse access | ❌ Not started | M5-08-verification-platform-integration.md |
| M5-09 | Display of the Velocity verification checks | FR3 | 🟢 Resolved 2026-08-26 — 6 real checks (not 4 or 5), any single failure marks the whole credential unverified | ❌ Not started | M5-09-display-verification-checks.md |
| M5-10 | PDF verification report generation & download | FR3, INT7 | ✅ Concrete rules added 2026-08-26 (1 credential/page, no printing, no dead download links) | ❌ Not started — no PDF library present anywhere in the codebase yet | M5-10-pdf-verification-report.md |
| M5-11 | Credits / vouchers mechanism for verification | NFR5 | 🟡 Spec exists (requirements doc Appendix 1, p.14) — needs Curo re-confirmation, not a missing spec | ❌ Not started — empty stub only | M5-11-credits-vouchers-mechanism.md |
| M5-12 | Functional/Technical Design Document | D2c | ⚠️ Blocked on M5-11 confirmation | ❌ Not started | M5-12-functional-technical-design-document.md |
| M5-13 | Test Evidence | D4c | ✅ Concrete acceptance-test checklist added 2026-08-26 (happy path / access isolation / protocol correctness / failure states) | ❌ Not started | M5-13-test-evidence.md |
| M5-14 | General payment/invoicing capability (distinct from M5-11) | NFR5 | ✅ Resolved — requirements doc Appendix 1 (p.15): MVP is manual/offline invoicing, Stripe deferred | ❌ Not started | M5-14-general-payment-invoicing-capability.md |
| M5-15 | Verification configuration templates & audit log | FR3 | 🟡 Still needs its own confirmation — distinct from M5-02/M5-01's "packages" (this is about which checks run, not which disclosure types get requested); do not assume 2026-08-25's package clarification resolves this too | ❌ Not started | M5-15-verification-configuration-templates.md |
| M5-16 | Batch verification of multiple credentials | FR3 | 🟡 Out of MVP scope for now — not mentioned in 2026-08-20 client feedback, found via wireframe only | ❌ Not started | M5-16-batch-verification.md |
| M5-17 | Notification preferences (personal + team) | FR3 | 🟡 Out of MVP scope for now — found via wireframe; also raises the SMS-channel question | ❌ Not started | M5-17-notification-preferences.md |
Wireframe cross-check (13 Aug → 20 Aug 2026)¶
docs/design/ui-designs/credential-disclosure/ and credential-verification/ contain 9 wireframe pages in total — more than the task breakdown originally accounted for. Cross-checking them against the SOW surfaced three features (M5-15, M5-16, M5-17) with a real wireframe but no SOW text and no task, plus two refinements folded into M5-04 (multi-stage follow-up sequence) and M5-06 (PDF export option; confirmed no JSON/XML option exists in the actual export wireframe). None of these are inside the SOW's written requirements — they're designed but unwritten, so each needs a scope confirmation with Curo before being built, same treatment as the SOW-only open items above.
Client feedback (20 Aug 2026) — superseded 25 Aug 2026, see below¶
"Disclosure & Verification: MVP will use one generic disclosure request. Verification should support multiple credentials with clear status/results. Existing Verify My Credentials UI will be used as a reference."
This was believed to resolve M5-02 and substantially narrow M5-01/M5-15/M5-16/M5-17. A follow-up clarification call on 2026-08-25 replaced the "one generic request" framing — see immediately below.
Client feedback (25 Aug 2026) — request packages, not one generic request¶
Source: 2026-08-25 Disclosure and Verification clarification.pdf, shared on a follow-up clarification call. Full detail in M5-00's 2026-08-25 update section — read that before any individual task file below.
Headline changes from the 20 Aug framing: - Org Admin configures named packages — combinations of Disclose Credentials, Claim Right to Work (RTW, via DataChecker), and Reclaim Employment (HMRC) — not one fixed request. MVP ships "Disclose only" and "Disclose + Reclaim Employment"; RTW combinations are info-only, not built. - Reclaim Employment (HMRC) needs reconciling with M7 before its cost is known. M7-01 has been asking Curo since 2026-04-16 whether "Reclaim Protocol" means a real, separate backend integration with HMRC/Reclaim Protocol's own API, or something lighter. Today's framing ("just add a link, Velocity's wallet handles the rest") may answer that — or may be describing a different, simpler mechanism that doesn't actually cover what M7-01 scoped. Not yet confirmed either way — see M7-01. - A concrete dashboard/list spec now exists for M5-05 (name/status/status date/actions), and precise verification UI rules for M5-09 (single green/red per disclosure at list level; full per-check breakdown only on the detail page; Re-verify is detail-page-only). - The 4-vs-5-verification-checks discrepancy (Velocity's real schema has 4 fields, the client's spec says 5) has now been raised twice by the client without resolving which the 5th is — needs a direct question back to them.
Vendor update (26 Aug 2026) — Velocity's own "CV Capture" implementation spec¶
Source: velocitycareerlabs/credential-platform wiki — CV Capture, shared directly by Velocity's team. This is the actual technical pattern to build M5 against — more precise than anything pieced together from marketing pages up to this point. Full detail in M5-00's 2026-08-26 update section.
Headline changes:
- Real API endpoints, different from what Part 2 of M5-00 assumed: relying-party-services/create (org setup), depots/create, presentation-links/refresh, presentations/get, presentations/verify.
- New architectural concept: the "depot" — an isolated storage container created per application/share-attempt (not per org, not per candidate), keyed by an opaque HMAC-derived reference that must never contain candidate PII. Our current PresentationRequest entity has no field for this yet.
- Resolves the long-open 4-vs-5-checks question: it's actually 6 checks (holder signature, tamper, trusted issuer, trusted holder, revocation, expiry) plus a timestamp — the public schema only ever exposed the 4 credential-level ones, missing 2 presentation-level checks that only apply in a disclosure context.
- Concrete authorization rules (never trust the browser for tenantId/depotId/presentationId), a protocol gotcha around deep-link parameter forwarding that can silently misroute a disclosure, concrete PDF rules (M5-10), a ready-made acceptance test plan (M5-13), and a hard constraint on GDPR erasure promises (M9-01) — Velocity has no presentation-deletion endpoint today.
Notes¶
Every item in this milestone starts from zero code — the POC deliberately focused on issuance and admin first (per the original delivery-drop plan). Three TypeORM entities exist as an unused scaffold (app/backend/src/verification/entities/) but nothing else — no controller, no service, and the module doesn't even register them. This is the first milestone where "requirement clarity" and "nothing built yet" overlap. M5-02 and M5-11 were briefly considered resolved/de-risked after the 20 Aug feedback; M5-02 has since been reopened (25 Aug) and should not be treated as settled — see M5-00 for detail.