Domain entities
Domain entities
Section titled “Domain entities”Audience: domain, backend, ux, qa, frontend
Status: specced
Owns: product + backend
Depends on: Domain overview, RPL lifecycle, RPL policies
Entities below are the shared vocabulary. Attributes are business-facing, not database columns. Stage/status codes come from the lifecycle.
Core entities
Section titled “Core entities”| Entity | Definition | Notes |
|---|---|---|
| User | Authenticated person on the platform | Holds identity records over time (POL-08); roles attach via persona / org membership. Deactivate via OL POST /auth/delete-account (user.deleted) |
| Candidate | Persona applying for RPL | Owns applications; must verify identity before submit |
| Assessor | QAA, IQA (IQM), or EV | Platform-vetted (AssessorProfile approve / reject / suspend); one assessor type per centre (POL-09); marketplace and retained requests require approved status |
| Centre | Assessment centre that runs RPL applications | Platform-created (approved + SUPER_ADMIN invite) or self-serve org onboarding (pending → approve); payout details; assigns reviewers, facilitators, panels |
| AwardingBody | Issues certificates; runs external verification | Assigns EV |
| Application | Candidate’s RPL application for a trade/units | Aggregate; moves through lifecycle stages |
| Sector | Platform grouping for trades | v1 attrs: name, description, auto slug; has many Trades |
| Trade | NOS trade the application targets | v1 attrs: name, description, auto slug, status (active|archived); has many NOS versions (one active); units hang under qualification levels on a NOS, not directly on Trade |
| Unit | NOS unit within a qualification level | v1 attrs: referenceNumber, title, isMandatory, structure (LO→PC); belongs to QualificationLevel → NosDocument → Trade |
| EvidenceFolder | Evidence collected for the application | Facilitator-assisted in EVIDENCE stage |
| Payment | Candidate payment to the centre | Required before facilitator assignment (PAYMENT stage) |
| Interview | Panel interview for the application | Panel of three (one head); can lead to appeal or GAP_TRAINING |
| Certificate | Credential issued after successful path | Generation model open (POL-06) |
| Recommendation | LMS course suggestion for competency gaps | CAP → LMS via gRPC RecommendCourses |
| LmsUser | LMS anti-corruption layer for an OL account | Multi-persona: learner / instructor / staff |
| Course | Published or draft training offering | Native items + optional SCORM 1.2 package; optional CAP linkage |
| Entitlement | Why a learner may access a course | self_pay / admin_grant / cap_recommendation / sponsor |
| Enrollment | Learner progress on a course | Distinct from entitlement |
| LmsCertificate | LMS completion credential | Independent of CAP Certificate |
Related actors (not always separate aggregates): Facilitator, Reviewer, Interview panel, Platform staff. See Personas.
Key invariants
Section titled “Key invariants”| ID | Rule | Refs |
|---|---|---|
| INV-01 | NIN (or current identity method) verified before application leave DRAFT for submit |
Lifecycle, Identity module |
| INV-02 | At most one active (non-draft) application path per concurrent-application policy | Lifecycle, POL-01 |
| INV-03 | Centre payment completed before facilitator assignment for evidence | Payment module, lifecycle |
| INV-04 | One assessor type per centre | POL-09 |
| INV-05 | EV must not be an assessor at the centre whose application they verify | POL-10 |
| INV-06 | After unsuccessful interview with gaps, application may CLOSED with reason GAP_TRAINING and LMS recommendations shown |
Recommendations, lifecycle |
Stage vocabulary (pointer)
Section titled “Stage vocabulary (pointer)”Do not redefine stages here. Canonical codes: DRAFT → CENTRE_REVIEW → PAYMENT → EVIDENCE → INTERVIEW → INTERNAL_VERIFICATION → EXTERNAL_VERIFICATION → CERTIFICATION → CLOSED. Full tables: RPL lifecycle.
Glossary bridge
Section titled “Glossary bridge”Platform and acronym terms: Glossary. Prefer entity names from this page in OpenAPI, UX, and tests.