Delivery milestones

Document: SDD-03
Status: Working draft
Date: 18 September 2026 (updated 3 October 2026)

Nomenclature: M1–M5 anchors below. Capability IDs: SDD-11 · index SDD-15.

1. Sequence

Milestone order follows the admissions-first decision and working-system dependencies. It is not prescribed by government. All unagreed dates remain TBC. A milestone describes when a capability must work, not when investigation begins.

flowchart LR
  M1[1. Confirm rules<br/>and integration] --> M2[2. Admissions launch]
  M2 --> M3[3. Core student portal]
  M3 --> M4[4. Lesotho pilot<br/>acceptance]
  M4 --> M5[5. Campus expansion<br/>and remaining CMS]

SoR posture across milestones: M1–M4 deliver modern portals on the existing campus CMS family via the Portal API (ADR-1, confirmed Aslam 23 Sep 2026). M4 acceptance campus is Lesotho (Working Group, 3 Oct 2026 — supersedes Cyberjaya-first gate). M5+ expands to other campuses (Cyberjaya, proposed Eswatini, …) and is where progressive unified one-stop CMS consolidation may begin — only for verified gaps and with an agreed migration strategy. M5 is not a licence to rewrite every working desk.

Kickoff: TBC. Backend commitments: TBC.

2. Milestone definitions

M1 — Confirm rules and integration

Target TBC
Scope Campus rules, named owners, legacy capabilities, integration access
Dependencies Campus and backend owners identified; kickoff TBC
Release condition Rules, API access and operating responsibilities agreed
Primary CAP CAP-42 (copyright / provider operating controls)

This is not a UI milestone. It unblocks every later “Needs checking” row.

M2 — Admissions launch

Target TBC
Scope Applicant registration, evidence, tracking, offers, Registry review, core applicant/student sign-in, mobile shell foundations
Dependencies Agreed rules; working old-CMS admissions/authentication integration
Release condition Application-to-enrolment works with real records; required staff workflows available through verified old CMS or new screens

Must work end to end:

  1. Applicant account (CAP-01).
  2. Application + documents + declarations (CAP-02, CAP-03, CAP-55).
  3. Track / offer / accept (CAP-07).
  4. Registry review, qualification checks, offer, first enrolment (CAP-03, CAP-05, CAP-06, CAP-07).
  5. Marketing communications without owning the decision (CAP-16).
  6. Staff access via existing CMS unless a gap is verified (CAP-44).
  7. Portal API first slice (CAP-53).
  8. Auth, privacy, monitoring, backups (CAP-01, CAP-37, CAP-38, CAP-39).
  9. Accessible forms and mobile shell (CAP-35, CAP-36).

Student portal demo screens are not the release condition for M2.

M3 — Core student portal

Target TBC
Scope Learning resources, timetable, assignment delivery, policies, core records, semester registration, with lecturer and staff support
Dependencies Required student, teaching, file-delivery and finance APIs; approved content; staff workflows
Release condition Student and staff journeys work end to end with durable records and agreed core mobile access

Student-only demo UI is insufficient. Lecturer publish/mark and staff approval paths for the same CAP IDs must be Live or explicitly served by the old CMS.

M4 — Lesotho pilot acceptance

Target TBC
Scope Test the integrated Lesotho pilot, train staff, obtain campus acceptance. Capability parity with Lesotho’s newer CMS (screenshot benchmark) and applicable government / ODL requirements.
Dependencies Integrations, content, security, recovery, operational support ready; Lesotho old-CMS dump and/or agreed Live SoR path; sanitized materials (no live student PII in repos)
Release condition Lesotho campus accepts the pilot and confirms applicable requirements, including verified existing-CMS or manual alternatives. Raisd must be at least equivalent to the campus’s current newer CMS for accepted journeys.
Primary CAP CAP-41 staff training and operating readiness

Pilot approach and inventory: docs/ai/architecture/lesotho-pilot.md, docs/ai/backend/old-cms-lesotho.md.

M5 — Campus expansion and remaining CMS

Target TBC
Scope Expand campus coverage (Cyberjaya, proposed Eswatini, Botswana, Sierra Leone, …); remaining approved CMS/staff capabilities; start progressive consolidation toward a unified one-stop CMS where gaps are verified
Dependencies Lesotho pilot accepted; campus-specific rules and existing capabilities verified; migration plan per domain before retiring a legacy desk
Release condition Each campus accepts its rollout. Deferring new software never defers an applicable operating requirement. Any SoR move needs ownership, cutover, rollback, and training agreed

Includes quizzes/exams, live class, library, visa, accommodation, scholarships, online payment gateway, study centres, remaining staff desks — prefer Portal API + verified old CMS first; rebuild or migrate only when the gap and migration strategy are explicit (SDD-11).

flowchart TB
  subgraph phase ["This phase — M1 to M4"]
    P[Four portals] --> API[Portal API]
    API --> CMS[Campus CMS family SoR<br/>Lesotho pilot first]
  end
  subgraph later ["Longer term — M5+"]
    G[Verified gap] --> MIG[Migration strategy]
    MIG --> U[Progressive unified CMS]
    CMS -.->|retire desk only when ready| U
  end
  phase --> later

3. Tension with current build

The student portal v1 frontend is deepest on M3 student screens. Product priority still puts M2 before M3.

Design rule for the next two weeks:

  1. Freeze new student demo screens unless they are on the M2 critical path (auth, mobile shell, accessibility).
  2. Prioritise CAP-53, CAP-01, applicant CAP-02/CAP-03/CAP-07, and Registry old-CMS verification.
  3. Keep existing student demos, but label them Demo until wired.

4. Definition of done (any capability)

A capability is Live only when all of the following are true:

  1. Real data from the system of record, not a mock session.
  2. Durable save where the user can mutate data.
  3. Server-enforced permission for that role and campus.
  4. The paired staff/lecturer action exists in new UI or is verified in the old CMS.
  5. Accountable owner named.
  6. Core mobile accepted if the CAP is in PRODUCT-MOBILE.
  7. Country/campus operating checks in the next-action column are closed or explicitly waived.

5. Counts (detailed checklist)

Re-counted from the live sheet on 19 September 2026. Same figures as 18 September. Progress, the sequence chart, and the open tasks are in SDD-13.

Milestone Rows Dominant frontend status Live
Confirm rules & integration 1 Not applicable 0
Admissions launch 23 Mostly not started. 4 of 18 applicable rows started, none Live 0
Core student portal 51 16 started (student Demo/Partial). 35 not started, including lecturer and staff 0
Lesotho pilot acceptance 1 Not applicable (training) 0
Campus expansion & remaining CMS 36 12 started. 22 applicable rows not started 0

Portal breakdowns: SDD-04 through SDD-08.