the certification client Group — AI-Native School Portal Master Plan (v2, corrected)
**Prepared for:** Khurram — review-before-execute planning document
**Scope:** Three AI-native sites — the school, the school (schools), the certification client (board) — built security-first.
**Status:** PLAN. Nothing executed until you approve.
> **What changed from v1:** v1 wrongly treated these as public consumer platforms
> "targeting UAE users," and bolted on a heavy under-13 consent-acquisition engine,
> age-gating, and ad/tracking controls. **That was incorrect.** These are **closed,
> private portals for an already-enrolled school community.** Consent already exists
> in the signed, KHDA-regulated enrolment contracts. The public-platform compliance
> machinery has been removed. Security stays — not because you're a consumer
> platform, but because you hold children's school records and owe a duty of care.
---
0. The one principle
> Build the secure frame first, then build everything inside it.
The demo sites had no security harness. This plan lays the harness first and builds
every dashboard, login, and form inside it.
---
1. What this system actually is (corrected framing)
- A **closed institutional portal**, not a public platform.
- **Only three kinds of user ever log in:** enrolled students, their parents/guardians,
and school staff. No public. No acquisition funnel. No strangers.
- Every user already has an **established, contractual relationship** with the school,
governed by **KHDA-regulated enrolment agreements** they have already signed.
- **Consent already exists** in those enrolment contracts. The portal does not acquire
fresh public consent; it serves a known community. A light "you are now accessing
the digital portal" acknowledgement is reasonable, but no heavy consent engine.
This is an internal school system. Its security obligation is **duty of care over
student records** (which KHDA expects schools to keep secure), not consumer-platform
compliance.
---
2. How people get in — the registration & approval model
**Self-register → auto-match against the uploaded roll → admin approves.**
This is the backbone of the whole security model, so it's worth stating precisely:
1. The school admin **uploads the enrolment roll** (the school already holds this from
its KHDA records). The roll contains, per student: student name, student ID,
year/class, and the linked guardian name(s) + contact. A staff list does the same
for teachers.
2. A parent/student/teacher **self-registers**, entering identifying details (e.g. a
parent enters their child's student ID or name + DOB, plus their own details).
3. The system **auto-matches** the registration against the roll and flags it:
- **Green** — clean match → admin approves in one click.
- **Amber** — partial match → admin reviews.
- **Red** — no match → rejected.
4. On approval, the account goes **active**.
**Why this is strong:** the enrolment roll — the school's own source of truth — is the
gatekeeper, not a human guess. An impostor who self-registers simply isn't on the roll
and never gets approved. Identity verification = matching to records the school already
trusts.
**Bonus:** the roll upload does double duty. The parent↔child links in the roll
directly seed the **guardian_link** (the single most important relationship — it's what
lets a parent dashboard show their child). One upload both verifies identity *and*
builds the relationships the dashboards run on.
---
3. The security harness (scoped to a closed school portal)
Six layers. Lean, because the system is private — but every layer here is genuinely
needed for children's records.
Layer 1 — Login + the Approval Gate
Layer 2 — Role Separation (the core duty-of-care control)
Layer 3 — Encryption
Layer 4 — Audit Logging
Layer 5 — Session Management
Layer 6 — Data Retention (KHDA rule)
**Removed from v1 (did not belong):** the under-13 consent-acquisition engine,
age-gating, privacy-by-default consumer toggles, and ad/tracking prohibitions. Those
target public commercial platforms. This is a closed school portal where consent lives
in the enrolment contract.
---
4. Architecture
```
┌──────────────────────────────────────┐
│ SECURITY HARNESS │
│ login + approval gate · role/RLS · │
│ encryption · audit · sessions · │
│ retention │
└──────────────────────────────────────┘
every request passes through
│
┌──────────────────────────┼──────────────────────────┐
┌─────────┐ ┌─────────┐ ┌─────────┐
│ the school │ │ the school │ │ the certification client │
│ school │ │ school │ │ board │
├─────────┤ ├─────────┤ ├─────────┤
│ Public │ │ Public │ │ Public │ ← public layer
│ + Iqra │ │ + Sage │ │ + Rashid│
├─────────┤ ├─────────┤ ├─────────┤
│ Portal │ │ Portal │ │ Board │ ← behind harness
│ Schema A│ │ Schema A│ │ Schema B│
└─────────┘ └─────────┘ └─────────┘
own DB own DB own DB
└────────── report up (summaries only) ──────────────┘
```
- **Schema A** (school: students/parents/teachers/classes/grades/attendance/fees) →
deployed for the school and the school, each its own isolated database.
- **Schema B** (board: documents/oversight/governance) → the certification client only.
- **Separate databases** → cross-site leakage impossible by design.
- **the certification client sees summaries, not raw student data** — schools report up periodic figures
(enrolment, KHDA status, fee collection). Board never queries student records.
- **Sanity content layer** sits beside the secure data layer for public brochure content.
---
5. UI / UX plan
5.1 Public layer
5.2 Registration & approval screens
5.3 School dashboards (the school / the school)
5.4 the certification client board portal (Schema B)
**Design language:** existing design tokens / three skins; calm, information-first
dashboards (two font weights, sentence case, generous space).
---
6. Timeline
Phase 0 — Now → 2 days: PUBLIC LAYER LIVE
Phase 1 — Week 1–2: HARNESS + the school FOUNDATION
Phase 2 — Week 3–4: the school DASHBOARDS
Phase 3 — Week 5: SECURITY VALIDATION
Phase 4 — Week 6–7: the school GO-LIVE + replicate to the school
Phase 5 — Week 8+: the certification client BOARD PORTAL
---
7. Hand-off questions for NewWorldEdu
1. How is **row-level security enforced in the database** (not just app code)?
2. Show the **roll-upload → auto-match → approval** design.
3. Where is data hosted — is it **UAE-region**?
4. What is **encrypted at rest**, including sensitive fields?
5. What does the **audit log** capture, and is it immutable?
6. What is the **retention/archive/purge** mechanism for KHDA records?
7. Will you run a **penetration test** before the portal goes live with real data?
---
8. Open decisions for you
1. **Auth foundation:** Supabase (managed auth + RLS built in) vs. custom vs. other.
2. **Hosting region:** confirm UAE-region residency with NewWorldEdu.
3. **Roll format:** what columns can the school export? (Shapes the match logic.)
4. **MFA for parents:** mandatory or optional? (Mandatory for staff regardless.)
5. **Does the certification client ever need individual student data,** or strictly summaries? (Summaries recommended.)
6. **Starky:** writes back into grades, or stays a separate tutoring log?
None block Phase 0.
---
9. What I can build next (your word)
- **Schema A (school)** for the school, with the approval-gate + RLS policies written in.
- **Schema B (board)** for the certification client.
- **Wireframes** for the registration/approval flow and the four dashboards.
- **Phase 0 public-launch hardening checklist** (concrete go-live list).
- **Roll-upload + matching spec** (columns, match rules, green/amber/red logic).
Tell me which, and I'll go.