Audience: product, domain, backend
Status: specced
Owns: product
Depends on: Lifecycle, Domain entities, System architecture
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-03 |
Stage time limits / SLAs |
Business numbers TBD; measurement via stage dwell metrics is accepted — Observability |
| POL-04 |
NIN verification provider |
Which API / vendor (Orchestrator hosts the port) |
| 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 |
| 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 |
| POL-11 |
One app per trade |
Candidate may not create another application for the same trade while status is DRAFT or IN_PROGRESS; allowed again after REJECTED / WITHDRAWN / CERTIFIED. INV-02 (global in-progress limit) still applies. |
| Topic |
Decision |
| POL-02 Interview scheduling |
Preassigned templates + per-application frozen copy. Centre panel/interview templates (/centre/panels, /centre/interviews); POST /centre/interviews/{id}/schedule copies sitting + panel onto one application. Template edits do not update existing copies. Ad-hoc application panel/schedule remains. Not live-sync; not multi-candidate cohorts. |
| Primary database |
PostgreSQL per service (not MongoDB) — Backend stack ADR |
| Storage |
Centralized in Orchestrator (signed upload URLs; Cloudinary) |
| Messaging |
RabbitMQ + transactional outbox; gRPC for sync |
| Workflow |
Config-driven sequencing + closed handler strategies — Workflow abstraction |
| CI/CD |
GitHub Actions — CI/CD |
| Observability |
OTel → SigNoz — Observability |
| Payment |
Pricing in CAP / LMS; processing in Orchestrator — Payment architecture |
| Auth |
Orchestrator JWT + JWKS; CAP cap_users anti-corruption layer |
| NSQ |
Documented alongside RPL — NSQ overview |
- Orchestrator issues shared JWT; CAP/LMS/WorkMasters validate locally via JWKS.
- Identity and storage services live in Orchestrator; payment processing in Orchestrator, pricing in CAP — Payment architecture; competency stays in CAP.
- Recommendations: CAP → LMS via gRPC.
- Org CRUD v1: Assessor / Centre / Awarding Body writes are platform-admin scoped.
- Full topology: System architecture.