Control Plane
Applicant portal
Document: SDD-04
Status: Working draft
Date: 18 September 2026
Milestone: Admissions launch (M2)
1. Purpose
Let a prospective student create an account, submit an application with evidence and declarations, track status, view an offer, and accept enrolment. Registry remains the decision owner. Marketing may publish announcements; it does not issue offers.
2. Actors
- Applicant (unauthenticated visitor → authenticated applicant)
- Registry (staff, old CMS or new staff screens)
- Marketing (communications only)
3. Primary flow
sequenceDiagram
actor A as Applicant
participant P as Applicant portal
participant API as Portal API
participant CMS as Existing CMS
actor R as Registry
A->>P: Sign in / create account (CAP-01)
P->>API: Provision applicant
API->>CMS: Create or match identity
A->>P: Complete application (CAP-02)
A->>P: Upload evidence (CAP-03)
A->>P: Accept policies (CAP-55)
P->>API: Submit application + files
API->>CMS: Persist application
R->>CMS: Review, qualification checks, offer (CAP-03/05/06/07)
A->>P: Track status, view offer, accept (CAP-07)
P->>API: Accept enrolment
API->>CMS: First enrolment record4. Capabilities
| ID | Feature | Frontend | Design notes |
|---|---|---|---|
| CAP-01 | Applicant sign-in and account access | Not started | Same identity family as student login; role = Applicant until enrolment. Confirm old CMS auth. |
| CAP-02 | Online application form | Not started | Minimum journey and required fields per campus/programme. Campus requested. |
| CAP-03 | Upload documents and English-entry evidence | Not started | Evidence rules are programme/country specific. Bytes must persist. |
| CAP-07 | Track application, view offer, accept enrolment | Not started | Confirm whether old CMS already exposes this to applicants. |
| CAP-16 | Applicant announcements and admissions updates | Not started | Campus requested. Marketing publishes; Registry owns decisions. |
| CAP-35 | Accessible application forms and assistance | Not started | Keyboard, assistive tech, assistance path. |
| CAP-36 | Mobile online-registration shell | Not started (mobile) | Launch requirement. Not a native app. |
| CAP-55 | Applicant policies and declarations | Not started | Campus requested. Capture acceptance, version, timestamp. |
Staff counterparts live in SDD-07: CAP-03, 05, 06, 07, 16, 44.
5. Data (logical)
| Entity | Key fields | Source |
|---|---|---|
| ApplicantAccount | identity, contact, auth subject | CMS / IdP |
| Application | programme, intake, campus, status | CMS |
| EvidenceObject | type, file id, checksum, uploaded at | File store + CMS metadata |
| Declaration | policy version, accepted at | CMS |
| Offer | conditions, expiry, decision | CMS |
| Enrolment | student id, programme, start | CMS |
Statuses at minimum: draft, submitted, under review, offer, accepted, enrolled, rejected, withdrawn.
6. Rules
- No application is complete without the campus-required evidence set for that programme.
- Foreign qualification checks (CAP-05, 06) are staff-owned. The portal must not auto-equate credit systems.
- Offer acceptance is the only applicant action that creates first enrolment.
- Announcements never change application status.
7. Current baseline
No applicant signup, application, intake-choice, or
application-status route exists (src/app/routes.ts).
Enrolled-student qualification records in Profile are not an admissions
flow.
Working frontend preview (2 October 2026): the unpaid fee summary uses the shared orange warning variant. Submitted Application Fee displays Transfer Proof only, while bank instructions remain in the editor. The two-row review table displays Department (Finance for Payment Proof, Registry for Document Check) as preview labels; Live reviewer routing is not implemented or confirmed by this UI. The completed Documents Checklist offers Create Application beside Edit Answers, opening the new application UI while retaining checklist state in memory. See Applicant preview guidance.
8. Acceptance (M2)
- An applicant can complete apply → upload → declare → submit on a phone-width viewport.
- Registry can complete review → offer using verified old CMS or new staff screens.
- Applicant sees the same status the CMS holds.
- Files opened by Registry are the files the applicant uploaded.
- CAP-53 admissions mapping is Live for this path.
9. Open blockers
Confirm minimum applicant journey, evidence matrix per programme, old-CMS applicant tracking, and account provisioning. Owners TBC.
Local admissions/profile increment — 5 October 2026
Applicant's existing draft/submission/messages flow now uses a validated session-only mock Portal API. Student schema v4 aligns Personal, Academic and Documents through an explicitly accepted, versioned handoff; submission alone never enrols a student. Shared UI remains 0.6.1. Lesotho is the acceptance-pilot priority; existing Malaysian sample rules are retained without asserting Lesotho policy. Details: Applicant mock API, accepted handoff and backend prerequisites. Automated local gates do not establish hosted HTTP, physical-device or CMS integration. No hosted reseed is authorized by this increment. Validation errors remain beside fields with focus on the first invalid control; no page-wide validation list is shown.
Local development review increment — 5 October 2026
Applicant provides one development-only Admin Actions page with three isolated applicant scenarios (Fresh, completed unsubmitted draft, submitted approved), a shared dropdown, payment/document SummaryCards and reviewer conversation. Switching retains saved work and invalidates stale operations. Payment verification precedes document verification; completion sets Approved without offers, accepted-enrolment context or Student provisioning. Admin viewing never reads messages for the applicant; approved conversations are read-only on both sides. Production excludes its route, navigation, commands and synthetic fixtures. No HTTP/CMS integration is asserted. See Applicant mock operations.
Local enrolment acceptance increment — 6 October 2026
Approved Applicant applications can explicitly accept their first-preference Design enrolment through the shared confirmation popup. Submission starts with no automatic reviewer messages. The next simulated development login transfers accepted serializable data into a new isolated first-semester Student mock account/enrolment and opens existing Module Registration. Both portals use the same captured intake reference and existing curriculum/rules. No offer screens, live authentication, CMS provisioning, durable evidence transfer or backend deployment is implemented. Production and HTTP sessions exclude the simulation. Shared UI stays 0.6.1; Student schema stays 4 and admissions handoff stays version 1. See accepted handoff.
Automatic post-acceptance logout — 6 October 2026
Successful enrolment acceptance automatically logs out Applicant development mock sessions to the existing Sign in screen. The applicant explicitly clicks Sign in to open the existing new Student tab at Module Registration. Failed acceptance stays in its popup; failed logout preserves accepted status with Retry Sign Out, without accepting again. Session/scenario guards prevent stale transitions. Records, files and drafts remain until refresh. Production and HTTP sessions exclude this simulation; shared 0.6.1, contracts and Student bootstrap remain unchanged.
Review and letter actions — 8 October 2026
Document verification releases Eligibility while overall enrolment remains orange and Under review. Application Progress uses Step as the first column. Four ordered checks show Bursary payment, Quality Assurance documents, applicant confirmation and Registry Offer release. Only final enrolment acceptance completes the summary. Equal-width letter actions include icons; Preview opens a separate browser PDF tab and Download retains the issued filename. The generated PDF retains its DEMO marking. No hosted workflow or schema changes are introduced.
Prepared original-document synchronization — 12 October 2026
Original uploads and applicant-specific Student continuation are prepared and verified locally behind Demo capabilities. No hosted migration or deployment was performed. Admissions v2, DEV transport v3, Student schema 4 and shared 0.6.2 remain. The Bursary shortcut stays On hold.