Skip to content
Elimi Docs

Identity verification

Identity verification

Section titled “Identity verification”

Audience: domain, product
Status: specced
Owns: product + backend
Depends on: Domain entities, Policies, Orchestrator overview

Product intent

Section titled “Product intent”
  • Candidates must verify identity (initially via NIN) before submitting an application.
  • After verification, identity-linked personal details become immutable for that application path.
  • Module should stay provider-agnostic so NIN is not hard-wired forever.
  • Provider/API choice is open — see Policies POL-04.

Identity records belong on the User (Orchestrator), with support for multiple identification methods over time (POL-08). CAP gates submit on verified status via gRPC/events — it does not call the NIN vendor directly.

GET /me includes identityVerified for every persona (not only candidates). After verification, identity-linked personal details (firstName, lastName, middleName, dob, gender, nationality) on GET/PATCH /me/profile are locked the same way as onboarding save (422 identity_fields_locked). Contact, address, currentOccupation, accessibility, and photoAssetId remain patchable. Do not reopen PATCH /onboarding/{persona}/save after COMPLETED (409) — settings write through /me/profile (personal) or PATCH /centre/profile (org).

Ownership

Section titled “Ownership”

Orchestrator hosts the identity verification service. CAP consumes verification status for application invariants (INV-01).

See also

Section titled “See also”