Contents
1. Executive snapshot
Raisd is delivering four modern portals — Applicant, Student, Lecturer and Staff — on the existing campus CMS through one 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).
Since the 5 Oct pack, the Demo estate has taken a material step on the admissions path: the hosted Portal API now runs Student schema v4 and exposes Applicant Demo HTTP, with the Applicant portal wired to that API in production Demo hosting. That improves platform readiness and admissions Demo depth. It does not move Live %.
| Measure | 5 Oct | 7 Oct | Executive read |
|---|---|---|---|
| Checklist Live | 0% | 0% | Unchanged — Demo persistence is not Live. |
| Frontend Demo depth | ~31% (sheet only) | ~36% | +5 Applicant Demo capabilities counted; WG sheet export still 19 Sep. |
| Platform readiness | ~65% | ~72% | Schema v4 reseed, Applicant HTTP, CORS/applicant SPA, OpenAPI 0.4.2. |
| M2 Admissions FE / platform | 22% / ~20% | ~50% / ~40% | Largest relative gain this cut — still Demo, not Live apply→enrol. |
| Lesotho pilot (M4) | ~20% | ~22% | Slight platform lift only; Live SoR path and dump access still open. |
2. Progress charts
Print-safe charts aligned to the Overview progress board
(portal-api-docs/diagrams/#progress), cut 7 Oct 2026.
2.1 Bar — milestone progress %
Frontend Demo depth % vs estimated platform readiness % (not Live). M1 and M4 have almost no frontend rows.
| Milestone | FE Demo | Platform | What it means for leadership |
|---|---|---|---|
| M1 Confirm rules & integration | 0% | ~50% | ADR-1, Schema v4 Demo, CAP-53 Partial, and architecture docs exist. Named owners, kickoff, and backend commitment remain TBC. |
| M2 Admissions launch | ~50% (9/18) | ~40% | Applicant Demo UI + hosted HTTP now started alongside earlier student-side placeholders. Staff admissions review and Live CMS apply→enrol remain open. |
| M3 Core student portal | 31% (16/51) | ~45% | Deepest student Demo. Lecturer and staff paths for the same capabilities remain 0. Schema v4 strengthens the academic/profile model only. |
| M4 Lesotho pilot acceptance | 0% | ~22% | Pilot decided; analysis published. Live SoR path, dump access, and NMDS/LGCSE/Loti parity still block acceptance. |
| M5 Campus expansion | 35% (12/34) | ~28% | Inventories and dumps analysed for later rollout. Do not pull ahead of admissions Live. |
2.2 Cumulative readiness over Working Group weeks
Platform work continues to rise. FE Demo depth moves on 7 Oct with Applicant Demo counted. Live stays at 0%. Dates are WG checkpoints, not a committed delivery calendar.
| WG date | Platform | FE Demo | Live | What changed |
|---|---|---|---|---|
| 18 Sep 2026 | ~15% | 31% | 0% | WG kickoff; student Demo/Partial already on the sheet. |
| 25 Sep 2026 | ~45% | 31% | 0% | Schema v3 Demo and Portal API / CAP-53 Partial. |
| 3 Oct 2026 | ~60% | 31% | 0% | Lesotho pilot decided; inventories begin. |
| 5 Oct 2026 | ~65% | 31% | 0% | Prior executive cut; FE still sheet-flat. |
| 7 Oct 2026 | ~72% | ~36% | 0% | Current cut: Schema v4 + Applicant Demo HTTP hosted; FE Demo depth lifts on admissions. |
2.3 Pie — work mix (applicable frontend rows)
103 applicable M2+M3+M5 frontend rows. Live = 0 omitted. Engineering cut 7 Oct: started 37 · not started 66 · 37÷103 ≈ 36%.
3. What moved since 5 October
/v1/auth/applicant/login, /v1/applicant/:method).
Still not Live: CMS-acknowledged writes, durable evidence bytes, production applicant identity, Registry/staff admissions desks, and Lesotho government-parity acceptance.
4. Projection, intentions, and goals
4.1 Intended delivery sequence (order only)
Agreed milestone order. Kickoff week and every target week on the sheet remain TBC.
Rules & integration
Admissions Live
Core student
Lesotho accept
Expansion
Distributed CMS
4.2 Near-term intentions
Convert Applicant Demo into M2 Live path
- Bridge CAP-53 from stub CMS to agreed Live SoR path.
- Close applicant identity / auth for Live (Q3).
- Verify Registry / Finance review path on old CMS or new staff screens.
Close leadership blockers (M1)
- Named owners for rules, API access, and operating checks.
- Agree kickoff and first target weeks (currently TBC).
- Confirm backend commitment for the CMS bridge.
Lesotho pilot readiness (M4 path)
- Secure Live SoR path / dump access (no PII in repos).
- Map NMDS, LGCSE, Loti, and newer-CMS parity gaps.
- Treat CAP-41 training/ops as part of acceptance.
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.
4.3 Goals by horizon
| Horizon | Goal | Evidence of success | Current state (7 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 past stub; staff path verified | Applicant Demo HTTP · 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 · schema v4 |
| Pilot acceptance | M4 Lesotho campus acceptance | Campus sign-off; parity for accepted journeys; ops ready | Pilot decided · ~22% |
| Scale | M5 multi-campus rollout + careful CMS consolidation | Per-campus acceptance; migration strategy before retiring desks | Inventories only |
4.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.
5. Leadership asks
| # | Ask | Why it matters | Blocks |
|---|---|---|---|
| 1 | Confirm named owners for campus rules, Portal API access, and operating checks | M1 release condition; moves backend off “Needs checking” | 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% despite Demo HTTP | M2 Live and M4 acceptance |
| 4 | Reaffirm admissions-first priority now that Applicant Demo is hosted | Protect focus on CAP-53 + Registry path over non-critical student polish | M2 critical path focus |
| 5 | Refresh the Working Group checklist export to recognise Applicant Demo starts | Keeps FE % reporting aligned with the estate sponsors see in Demo URLs | Sheet / executive number consistency |
6. Sources and reading notes
| Source | Use in this pack |
|---|---|
| SDD-13 Progress timeline (sheet 19 Sep 2026) | Baseline FE / applicable / Live counts |
| SDD-03 Delivery milestones · SDD-04 Applicant increments (7 Oct) | Sequence, admissions Demo HTTP narrative |
| Overview progress board (docs site, 7 Oct 2026) | Charts and platform readiness estimates |
| Portal API / Neon Demo (7 Oct 2026) | Schema v4 reseed; Applicant HTTP; CORS applicant origin |
| Working Group 3 Oct 2026 | Lesotho selected as pilot acceptance campus |
| ADR-1 (Aslam, 23 Sep 2026) | Existing CMS family remains SoR this phase |
| Prior executive pack 2026-10-05 | Comparison baseline for this cut |
Live board:
https://raisd-campus.github.io/portal-api-docs/diagrams/#progress.
Demo Applicant:
https://applicant-portal-lemon.vercel.app
· API meta:
https://raisd-portal-api.vercel.app/v1/meta.