RPL policies
RPL policies & open decisions
Section titled “RPL policies & open decisions”Audience: product, domain, backend
Status: specced
Owns: product
Depends on: Lifecycle, Domain entities
Document decisions here before encoding them in CAP app code. Items marked Open need business input.
| ID | Topic | Notes |
|---|---|---|
| POL-01 | Concurrent applications {x} days |
Days before candidate may start another app if centre silent |
| POL-02 | Interview scheduling model | Ad-hoc panel vs cohorts vs preassigned panelists |
| POL-03 | Stage time limits / SLAs | Not defined yet |
| POL-04 | NIN verification provider | Which API / vendor |
| POL-05 | EV sampling depth | How many fields EV must review |
| POL-06 | Certificate generation | System-generated vs manual issue by awarding body |
| POL-07 | Evidence type mapping | Candidate labels ↔ assessor labels |
Proposed (working)
Section titled “Proposed (working)”| ID | Topic | Proposal |
|---|---|---|
| POL-08 | Identity on User | Means of identification tied to User (multiple IDs over time), not only role entities |
| POL-09 | Assessor per centre | One assessor type per centre; platform vets then assigns to centres |
| POL-10 | EV conflict | EV must not be an assessor at the same centre as the application |
Architecture notes (from discovery)
Section titled “Architecture notes (from discovery)”- Orchestrator issues shared JWT; CAP/LMS/WorkMasters validate locally.
- Identity verification service likely in orchestrator; competency verification stays in CAP.
- Recommendations: CAP → LMS via gRPC.