Contents
1. Executive snapshot
Raisd is building four modern portals (Applicant, Student, Lecturer, Staff) on the existing campus CMS through a single Portal API. The Working Group selected Lesotho as the first acceptance campus (M4) on 3 Oct 2026. Product sequence remains admissions-first: confirm rules (M1) → admissions Live (M2) → core student journeys (M3) → Lesotho acceptance (M4) → other campuses (M5).
0%
Checklist Live
0 of 112 rows Live
31%
Frontend started
32 of 103 applicable
~65%
Platform readiness
Schema · API · docs · inventories
~20%
Lesotho pilot (M4)
Decided · analysed · not Live
Leadership tension: Student UI is deepest (~31% FE started on M3), but product priority is still
M2 admissions on real records. Do not treat student Demo polish as admissions progress.
2. Progress charts
Same figures as the Overview progress board on the docs site
(portal-api-docs/diagrams/#progress). Charts below are print-safe (no interactive Mermaid).
2.1 Bar — milestone progress %
Frontend started % (sheet) vs estimated platform readiness % (not Live). M1 and M4 have almost no frontend rows.
FE started %
Platform readiness %
Live = 0% on every milestone
| Milestone | FE started | Platform | What it means |
|---|---|---|---|
| M1 Confirm rules & integration | 0% | ~45% | Operating / rules milestone. ADR-1, Schema v3 Demo, CAP-53 Partial, architecture docs exist; owners and target weeks still TBC. |
| M2 Admissions launch | 22% (4/18) | ~20% | Student-side starts only. Applicant + staff admissions halves not started. No Live apply→enrol on CMS. |
| M3 Core student portal | 31% (16/51) | ~40% | Deepest student Demo/Partial. Lecturer and staff paths for the same capabilities still 0. |
| M4 Lesotho pilot acceptance | 0% | ~20% | Pilot decided 3 Oct; screenshot inventory + DB gap probe published. Live SoR path and dump still open. |
| M5 Campus expansion | 35% (12/34) | ~25% | Sheet starts + campus inventories (Cyberjaya / Botswana / Sierra Leone). Do not pull ahead of admissions Live. |
2.2 Cumulative readiness over Working Group weeks
Platform work rising; FE started flat at 31% since the 19 Sep sheet; Live stays at 0%. Dates are WG checkpoints, not a committed delivery calendar.
18 Sep
~15%Platform
31%FE started
0%Live
22 Sep
~30%Platform
31%FE started
0%Live
25 Sep
~45%Platform
31%FE started
0%Live
1 Oct
~55%Platform
31%FE started
0%Live
3 Oct
~60%Platform
31%FE started
0%Live
5 Oct
~65%Platform
31%FE started
0%Live
| WG date | Platform | FE started | Live | What changed |
|---|---|---|---|---|
| 18 Sep 2026 | ~15% | 31% | 0% | WG kickoff context; FE snapshot already ~31% from student Demo/Partial. |
| 22 Sep 2026 | ~30% | 31% | 0% | Campus inventories and dump analysis underway. |
| 25 Sep 2026 | ~45% | 31% | 0% | Schema v3 Demo and Portal API / CAP-53 Partial strengthen platform. |
| 1 Oct 2026 | ~55% | 31% | 0% | Docs and campus baselines deepen. |
| 3 Oct 2026 | ~60% | 31% | 0% | Lesotho pilot decided; screenshot inventory and DB gap probe start. |
| 5 Oct 2026 | ~65% | 31% | 0% | Current cut: platform ~65%; FE sheet still flat; Live still 0%. |
2.3 Pie — work mix (applicable frontend rows)
103 applicable M2+M3+M5 frontend rows. Live = 0 omitted. Totals: started 32 · not started 71 · 32÷103 ≈ 31%.
Started — Student · 31 — includes 4 M2 student-side starts; not Live
Started — Shared (CAP-53) · 1 — Portal API Partial
Not started — Student · 9 — of 40 student applicable
Not started — Applicant · 7 — entire applicant set (M2 critical path)
Not started — Lecturer · 18 — publish / attendance / marking
Not started — Admin/staff · 37 — including admissions staff review
3. Projection, intentions, and goals
3.1 Intended delivery sequence (order only)
Agreed milestone order. Kickoff week and every target week on the sheet remain TBC.
M1
Rules & integration
→
Rules & integration
M2
Admissions Live
→
Admissions Live
M3
Core student
→
Core student
M4
Lesotho accept
→
Lesotho accept
M5
Expansion
→
Expansion
Ideal
Distributed CMS
Distributed CMS
| Order | Milestone | Intention | Release condition (goal) | Target |
|---|---|---|---|---|
| 1 | M1 Confirm rules & integration | Name owners, campus rules, API access, operating responsibilities | Rules and integration access agreed — unblocks later Live work | TBC |
| 2 | M2 Admissions launch | Applicant apply → evidence → offer → enrol on real CMS records; Portal API first slice (CAP-53) | End-to-end admissions Live; staff path via verified old CMS or new screens | TBC |
| 3 | M3 Core student portal | Learning, records, fees, registration with lecturer/staff support paths | Student + staff journeys Live with durable records (Demo alone insufficient) | TBC |
| 4 | M4 Lesotho pilot acceptance | First campus acceptance; parity with Lesotho newer CMS; training & ops | Lesotho campus accepts the integrated pilot | Pilot decided |
| 5 | M5 Campus expansion | Cyberjaya, Eswatini (proposed), Botswana, Sierra Leone, …; progressive CMS consolidation only on verified gaps | Each campus accepts its rollout; no silent SoR rewrites | After M4 |
| Ideal | Distributed Raisd CMS | One product · country/region DBs · white-label · feature flags | Longer-term target after pilot and expansion evidence | Beyond M5 |
3.2 Near-term intentions (next engineering focus)
Protect admissions-first priority
- Freeze non-critical student Demo polish unless it is on the M2 path (auth, accessibility, mobile shell).
- Prioritise CAP-53, applicant CAP-02/03/07/55, and Registry old-CMS verification.
- Keep student demos labelled Demo until wired to durable SoR.
Close leadership blockers (M1)
- Named owners for rules, API access, and operating checks.
- Agree kickoff and first target weeks (currently TBC).
- Confirm backend commitment path for CMS bridge.
Lesotho pilot readiness (M4 path)
- Secure agreed Live SoR path / old CMS dump (no PII in repos).
- Map NMDS, LGCSE, Loti, and newer-CMS parity gaps.
- Treat CAP-41 training/ops as part of acceptance, not an afterthought.
Projected outcome for leadership
- This phase (M1–M4): modern portals on existing CMS; Lesotho accepts first.
- Success metric: Live checklist moves off 0% on admissions, then core journeys.
- Not the goal yet: rewriting every staff desk or pulling M5 ahead of M2 Live.
3.3 Goals by horizon
| Horizon | Goal | Evidence of success | Current state (5 Oct) |
|---|---|---|---|
| Immediate | Leadership lock on M1 owners, access, and target weeks | Named owners + dated plan on the Timeline tab | Open / TBC |
| First Live product | M2 admissions end-to-end on real records | Apply→enrol Live; CAP-53 bridge past stub; staff path verified | Demo started · Live 0% |
| Core campus journeys | M3 student + lecturer/staff paths Live or verified on old CMS | Durable records; paired role actions accepted | Student Demo deepest |
| Pilot acceptance | M4 Lesotho campus acceptance | Campus sign-off; parity with newer CMS for accepted journeys; ops ready | Pilot decided · ~20% |
| Scale | M5 multi-campus rollout + careful CMS consolidation | Per-campus acceptance; migration strategy before retiring desks | Inventories only |
| Ideal end state | Distributed Raisd CMS (country DBs, white-label) | Architecture accepted; no premature rewrite of working SoR | Documented target |
3.4 Definition of done (any capability)
- Real data from the system of record (not a mock session).
- Durable save where the user can mutate data.
- Server-enforced permission for that role and campus.
- Paired staff/lecturer action exists in new UI or is verified in the old CMS.
- Accountable owner named.
- Core mobile accepted if the capability is in the mobile product set.
- Country/campus operating checks closed or explicitly waived.
4. Leadership asks
| # | Ask | Why it matters | Blocks |
|---|---|---|---|
| 1 | Confirm named owners for campus rules, Portal API access, and operating checks | M1 release condition; unblocks “Needs checking” backend rows | M2–M4 planning |
| 2 | Set kickoff and first milestone target weeks (even provisional) | Sheet targets are all TBC; sponsors need a calendar signal | Weekly % credibility |
| 3 | Commit CMS bridge / Live SoR path for Lesotho (and dump access without PII in repos) | Without this, Live stays at 0% regardless of UI polish | M2 Live and M4 acceptance |
| 4 | Reaffirm admissions-first priority over further student Demo expansion | Current build gravity is M3 student UI | M2 critical path focus |
| 5 | Confirm who receives weekly progress PDFs and Demo credentials | Governance cadence for senior review | Reporting rhythm |
5. Sources and reading notes
| Source | Use in this pack |
|---|---|
| SDD-13 Progress timeline (sheet 19 Sep 2026) | FE started / applicable / Live counts |
| SDD-03 Delivery milestones (updated 3 Oct 2026) | M1–M5 sequence, Lesotho M4, definition of done |
| Overview progress board (docs site, 5 Oct 2026) | Charts, platform readiness estimates, WG-week series |
| Working Group 3 Oct 2026 | Lesotho selected as pilot acceptance campus |
| ADR-1 (Aslam, 23 Sep 2026) | Existing CMS family remains SoR this phase |
| Weekly pack 2026-10-03 | Baseline delivery detail for engineering estate |
Companion weekly engineering pack:
docs/reports/weekly-progress-2026-10-03/.
Live board:
https://raisd-campus.github.io/portal-api-docs/diagrams/#progress.