Raisd campus — what we are building

Project progress (high level)

Snapshot for sponsor weekly % reporting. Checklist Live from SDD-13 (sheet 19 Sep 2026). FE Demo depth and platform readiness include engineering work through 7 Oct 2026 (Schema v4, Applicant Demo HTTP, Lesotho inventory). Live = 0% until durable CMS-backed journeys pass acceptance. Week-by-week narrative: Reports (W01–W04 from 18 Sep).

%%{init: {'xyChart': {'width': 860, 'height': 480, 'showTitle': true, 'showLegend': false, 'chartOrientation': 'vertical', 'plotReservedSpacePercent': 40, 'titleFontSize': 16, 'titlePadding': 14, 'xAxis': {'labelFontSize': 15, 'labelPadding': 12}, 'yAxis': {'labelFontSize': 14, 'labelPadding': 12, 'titleFontSize': 15, 'titlePadding': 12}}, 'themeVariables': {'xyChart': {'plotColorPalette': '#1a4f8b, #2f9e6f'}}}}%%
xychart-beta
  title "Milestone progress %"
  x-axis [M1, M2, M3, M4, M5]
  y-axis "%" 0 --> 100
  bar "FE Demo depth %" [0, 50, 31, 0, 35]
  bar "Platform readiness %" [50, 40, 45, 22, 28]
              

%%{init: {'pie': {'textPosition': 0.5}, 'themeVariables': {'pieOuterStrokeWidth': '2px', 'fontSize': '16px'}}}%%
pie showData
  title Applicable frontend rows by portal (103 total; Live 0 omitted · cut 7 Oct)
  "Started — Student" : 31
  "Started — Shared (CAP-53)" : 1
  "Started — Applicant" : 5
  "Not started — Student" : 9
  "Not started — Applicant" : 2
  "Not started — Lecturer" : 18
  "Not started — Admin/staff" : 37
            

Lesotho pilot project

Confirmed Working Group weekly, 3 October 2026 (Read.ai). Full rationale: lesotho-pilot.md · diagram analysis: old-cms-lesotho/.

High-level architecture

Four role portals → Portal API → anti-corruption layer (CAP-53) → existing CMS. Planned Postgres holds portal maps, audit, and session — not a second copy of CMS data. Detail: Architecture review · SDD-02 · ADR-1.

flowchart LR
  subgraph People
    A[Applicants]
    S[Students]
    L[Lecturers]
    T[Staff]
  end

  subgraph Raisd["Control plane"]
    W[Role portal webs]
    API[Portal API]
    ACL["CMS bridge CAP-53"]
  end

  subgraph Campus
    CMS[(Existing CMS
system of record)]
    PG[(Postgres planned)]
    FS[(Evidence files)]
    IDP[Login / IdP]
  end

  A --> W
  S --> W
  L --> W
  T --> W
  W --> API
  IDP --> API
  API --> ACL
  ACL --> CMS
  API --> PG
  API --> FS
          

Public endpoints

Everything below is reachable from the internet today. Demo Portal API runs on UltaHost k3s at api.raisd.co / api.lesotho.raisd.co against VPS Postgres (Neon dump restored). Vercel portal SPAs call https://api.raisd.co; Lesotho campus SPAs call https://api.lesotho.raisd.co (same service). Legacy raisd-portal-api.vercel.app redirects to api.raisd.co. Checked 14 Oct 2026.

Websites

Portal API routes

Base URL https://api.raisd.co (Lesotho alias https://api.lesotho.raisd.co). Contract: Swagger UI · openapi.yaml. Browsers may call it only from the portal origins and this docs site (CORS allowlist).

Portal methods (POST /v1/portal/{method})

55 methods, all bearer-authenticated. Writes are Demo only: every response carries cms.acknowledged = true, mode = "stub" until the CMS bridge (CAP-53) is connected.

Distributed CMS — ideal end state (high level)

End goal: one Raisd CMS product with a database (and preferably API capacity) per country / region, each campus white-labelled and feature-toggled. Global control plane holds tenancy, branding, flags, and identity maps — not student ledgers. Full step-by-step: Distributed CMS architecture.

flowchart LR
  subgraph Product["One product"]
    P[Four portals]
    API[Portal API]
  end
  subgraph Control["Global control plane"]
    T[Tenant · white-label · flags · IdP]
  end
  subgraph Data["Country data planes"]
    MY[(Malaysia)]
    SG[(Singapore)]
    SL[(Sierra Leone)]
    BW[(Botswana)]
    MORE[(…)]
  end
  P --> API
  T -.-> API
  API --> MY
  API --> SG
  API --> SL
  API --> BW
  API --> MORE
          

Current state, target state, and what needs to be done

Baseline product truth: SDD-01. “Demo” on screen is not “Live” — Live needs durable save, real records, and server-enforced permissions.

Migration stages (M1–M5)

Order is admissions-first. A milestone is when something must work, not when investigation starts. Dates are TBC until the working group locks them. Full plan: Migration · SDD-03.

flowchart LR
  M1["M1 Confirm rules
and integration"] --> M2["M2 Admissions
launch"]
  M2 --> M3["M3 Core student
portal"]
  M3 --> M4["M4 Lesotho
pilot acceptance"]
  M4 --> M5["M5 Campus expansion
and remaining CMS"]
          

Explore further

Deeper technical material for architects, developers, and AI agents.