Updated 2026-08-26 — real API sequence (CV Capture)2 open items flagged below
Everything in one place for M5: the real API sequence per Velocity's CV Capture spec (2026-08-26), what changed on the 2026-08-25 clarification call, what's still unresolved, and the proposed Org Admin UI checked against all of it.
1Key information
What changed on the 2026-08-25 clarification call
Not one generic request. Org Admin now configures named "packages" in org settings — each a combination of Disclose Credentials, Claim Right to Work (via DataChecker, Home Office-approved), and/or Reclaim Employment (via HMRC). MVP ships Disclose-only and Disclose + Reclaim Employment; RTW-involving packages are shown for info only, not built.
Reclaim Employment is claimed to be lighter to build than it sounds — our side only adds a link in the disclosure email; the Velocity Career Wallet app handles the HMRC pull itself.
Not yet confirmed: whether that's the same integration the separate M7 "Reclaim Protocol" milestone has been asking Curo to scope since 2026-04-16 (a real backend build against HMRC/Reclaim Protocol's own API), or a different, lighter mechanism. Treating the wrong one as true is expensive either way — this is the single most important open question before estimating the Reclaim Employment package.
A review dashboard exists alongside this flow: Name / Status / Status date / Actions (Resend while unanswered, View), sent-and-received items in one shared list, new returns highlighted. Re-verify is a detail-page-only action — deliberately absent from the main table.
Resolved 2026-08-26: the "4 vs 5 checks" question — it's actually 6 real checks (holder signature, tamper, trusted issuer, trusted holder, revocation, expiry) plus a timestamp, per Velocity's own "CV Capture" spec (shared directly by their team today). The public schema only ever exposed the 4 credential-level ones; the 2 missing were presentation-level checks that only exist in a disclosure context. Still to do: say this back to the client explicitly — they likely undercounted the presentation-level checks when they said "5."
Gap found in the UI mockup below: it shows the detail page well, but has no list/dashboard view at all — the client's own spec describes the table above as the primary screen, with this detail page reached by clicking into one row. Worth building that list view before treating this mockup as complete.
Package & email settings screen added per the client's own framing: Org Admin manages available request types (Velocity Credential Disclosure, Reclaim Protocol, Right to Work as a disabled future type) and creates named, reusable packages from them under org settings; the Staffing User only ever picks a package, never individual options (already true on the Create request tab). Each package's disclosure email is shown as composed, editable sections — one per included request type, assembled into a single email — matching "a single mail with one or more sections of pre-configured text."
New architectural concept, 2026-08-26: every disclosure request needs its own isolated "depot" — a storage container scoped to one application/share-attempt, keyed by an opaque reference that must never contain the candidate's name or email. Our current data model doesn't have this field yet; see the sequence diagram below for exactly where it's created.
This is the diagram sent to the client on 2026-08-25 for sign-off (still awaiting their confirmation), recreated here with the 6-check correction from Velocity's CV Capture spec (was showing a stale "5th factor TBD" note) — since it's still pre-confirmation, this corrected version is what should go back to them, not the original.
How it actually works — Velocity's CV Capture sequence (2026-08-26)
Four parties, not three — the recruiter and the employer's own backend are separate from Curo-REC's role as Inspector. The wallet never talks to our backend directly; it only ever talks to Velocity's Operator API. The decision-flow diagram below is the same process from the Org Admin's point of view, once package selection is layered on top.
All three credential lanes shown for illustration — the number of lanes matches however many credentials the candidate actually chose to disclose. Each now shows the real 6 checks (holder signature, tamper, trusted issuer, trusted holder, revocation, expiry) — if any one fails, the whole credential shows as failed, not partial. Verification (running the checks at all) is optional and separate from receiving the disclosure.
Live mockup below — package selection, per-credential verification results, and org settings for configuring request types, packages, and the disclosure email. Matches the 4-check schema and the detail-page-only Re-verify rule; does not yet include the list/dashboard view called out as a gap above.
CV
Disclosure & Verification
Org Admin workspace
Verification results
EX-2026-00124 · received from Career Wallet
Aggregate result
Based on the credentials actually disclosed by the candidate
Partial
Past EmploymentPASS
Trusted issuerPASS
UnrevokedPASS
UnexpiredPASS
UntamperedPASS
Education DegreePASS
Trusted issuerPASS
UnrevokedN/A
UnexpiredPASS
UntamperedPASS
Email VerificationFAIL
Trusted issuerPASS
UnrevokedN/A
UnexpiredFAIL
UntamperedPASS
2 of 3 credentials verified
Verification is optional and separate from receiving the disclosure.
Partial
The number of credential lanes is dynamic and matches the credentials the candidate actually chose to disclose.
Create disclosure request
Select a request package
Choose one package configured for your organisation.
Packages
Combine request types into a reusable package your Staffing Users can select
Disclose Credentials
Velocity Credential Disclosure
Disclose + Reclaim Employment
Velocity Credential DisclosureReclaim Protocol
Package name
Included request types
Disclosure email — composed sections
One section per selected request type, assembled into a single email sent to the candidate.
Section 1 · Velocity Credential Disclosure
Section 2 · Reclaim Protocol (Employment)
Process view above shows decision points and states across the whole M5 milestone. For who's involved at the protocol level (Holder, Inspector, Issuer, Registrar) and the actor-by-actor sequence, see the companion "How Disclosure & Verification Works" page.
