the certification client Group — AI-Native Platform Master Plan
**Prepared for:** Khurram — review-before-execute planning document
**Scope:** Three AI-native websites — the school, the school (schools) and the certification client (board) — built security-first.
**Status:** PLAN. Nothing in here is executed until you approve it.
---
0. The one principle this whole plan is built on
> Build the secure frame first, then build everything else *inside* it.
The demo sites were built without a security harness. This plan reverses that: the
harness is laid down first, and every dashboard, form, and login is constructed
within it. Retrofitting security is expensive and leaky; building inside it is
cheaper and safe.
---
1. The honest timeline position (read this first)
You have two real pressures that pull against each other:
- **Summer school starts in days** → something must go live very soon.
- **You want it done properly, security-first** → a real harness for children's
data is not a two-day build.
**The resolution is a two-tier launch.** Not everything carries the same risk, so
not everything needs the same security bar before it ships.
| Tier | What it is | Holds student data? | Security bar | Can launch in days? |
|------|------------|---------------------|--------------|---------------------|
| **Tier 1 — Public** | Marketing pages, chatbots, multilingual content, admissions *enquiry* forms | No | Standard web hardening | **Yes** |
| **Tier 2 — Authenticated** | Parent/student/teacher dashboards, LMS, grades, fees, attendance | **Yes** | Full harness + testing | **No — follows in the grace window** |
This lets summer school launch on Tier 1 immediately, while Tier 2 is built
properly behind the harness. Launching parent/student logins on an unhardened site
in two days would repeat the original mistake — and the stake is children's data.
---
2. The regulatory frame the harness must satisfy
The UAE **Child Digital Safety Law (Federal Decree-Law No. 26 of 2025, "CDS Law")**
took effect **1 January 2026** and applies to any platform operating in or
targeting users in the UAE. Your sites are in scope. Full enforceability arrives
**January 2027** — a one-year grace window. That window is the time to build Tier 2
properly, not an excuse to skip it.
**Hard requirements that shape the architecture:**
1. **No processing of under-13 data without explicit, documented, verifiable
parental consent**, plus an always-available way to withdraw it.
2. **Privacy-by-default for children** — the safe setting is the default, not opt-in.
3. **Access restricted to authorised personnel only** — this is row-level security.
4. **No commercial use, targeted ads, or tracking** beyond the authorised purpose.
5. **Clear privacy disclosures** to both child and guardian.
6. **Records retention** (KHDA/ADEK): student records — personal, academic,
medical, behavioural — retained securely for **at least 5 years** after a student
leaves; graduation records indefinitely.
The tension to engineer around: **protect tightly, yet retain durably and
auditably.** Both at once.
---
3. The security harness (the heart of the plan)
The harness is nine layers. Each one is a checkpoint; together they form the frame
everything else is built inside.
Layer 1 — Identity & Authentication
Layer 2 — Roles & Authorisation
Layer 3 — Row-Level Security (RLS) — the single most important layer
Layer 4 — Encryption
Layer 5 — The Under-13 Consent Engine (CDS Law core)
Layer 6 — Audit Logging
Layer 7 — Session & Access Management
Layer 8 — Data Retention & Lifecycle
Layer 9 — Operational Security
---
4. Architecture — how it all fits together
```
┌──────────────────────────────────────────┐
│ THE SECURITY HARNESS │
│ (auth · roles · RLS · encryption · │
│ consent · audit · sessions · retention) │
└──────────────────────────────────────────┘
every request passes through it
│
┌────────────────────────────┼────────────────────────────┐
│ │ │
┌─────────┐ ┌─────────┐ ┌─────────┐
│ the school │ │ the school │ │ the certification client │
│ (school)│ │ (school)│ │ (board) │
├─────────┤ ├─────────┤ ├─────────┤
│ Public │ │ Public │ │ Public │ ← Tier 1
│ site + │ │ site + │ │ site + │ (launch now)
│ chatbot │ │ chatbot │ │ chatbot │
│ (Iqra) │ │ (Sage) │ │ (Rashid)│
├─────────┤ ├─────────┤ ├─────────┤
│ School │ │ School │ │ Board │ ← Tier 2
│ Schema A│ │ Schema A│ │ Schema B│ (behind harness)
│ dashbd │ │ dashbd │ │ portal │
└─────────┘ └─────────┘ └─────────┘
own DB own DB own DB
│ │ │
└───────── report up ────────┴────── report up ────────────┘
(periodic summaries only, no live student data)
```
- **Two schema shapes:** Schema A (school: students/parents/teachers) deployed for
the school and the school; Schema B (board: documents/oversight/governance) for the certification client.
- **Separate databases** per site → data isolation by design.
- **the certification client gets roll-ups, not raw data:** schools *publish* periodic summaries
(enrolment counts, KHDA status, fee-collection rates) up to the board. The board
never queries a school's student records directly. This keeps walls intact and is
the CDS-safe design.
- **Content layer (Sanity)** sits beside, not inside, the secure data layer — brochure
content is public and separate from student records.
---
5. UI / UX plan
5.1 Public layer (Tier 1)
5.2 The login & consent flow (the gateway to Tier 2)
5.3 The four school dashboards (the school / the school)
**Parent dashboard** — the most-used screen:
- Child selector (if more than one child)
- At-a-glance: attendance %, fees due, recent grades, unread announcements
- Tabs: Academics · Attendance · Fees · Messages · Announcements
**Student dashboard:**
- Today's lessons & timetable
- Assignments due (sorted by deadline)
- My grades & feedback
- Starky (AI tutor) entry point
**Teacher dashboard:**
- My classes
- Work to mark (queue)
- Class register / attendance entry
- Announcements to my classes
**Admin dashboard:**
- School-wide: enrolment, staff, fees overview
- User management (invite/disable)
- Reports that feed the the certification client roll-up
5.4 The the certification client board portal (Schema B)
**Design language:** carries the existing design tokens / three skins. Dashboards
stay calm and information-first — two font weights, sentence case, generous space,
no SaaS clutter — consistent with the showcase already built.
---
6. Phased timeline (realistic)
Phase 0 — Now → 2 days: SAFE PUBLIC LAUNCH (Tier 1)
Phase 1 — Week 1–2: HARNESS FOUNDATION
Phase 2 — Week 3–4: the school DASHBOARDS
Phase 3 — Week 5: SECURITY VALIDATION
Phase 4 — Week 6–7: the school GO-LIVE (Tier 2) + replicate to the school
Phase 5 — Week 8+: the certification client BOARD PORTAL (Schema B)
> Comfortably inside the **January 2027** full-enforceability deadline.
---
7. Hand-off spec for NewWorldEdu
Give them this plan and require, in writing, answers to:
1. **"How do you enforce row-level security per role, in the database?"**
(If the answer is "in the app code only" — that's not good enough.)
2. **"Show the under-13 consent record design and the withdrawal flow."**
3. **"Where is data hosted, and is it UAE-region?"**
4. **"What is encrypted at rest, and how are field-level sensitive items handled?"**
5. **"What does the audit log capture, and is it immutable?"**
6. **"What is the data-retention/purge mechanism for the 5-year rule?"**
7. **"Will you run a penetration test before the authenticated layer goes live?"**
These seven questions separate a safe build from a leaky one. If NewWorldEdu can
answer all seven concretely, you're in good hands.
---
8. Open decisions for you (small, but they shape execution)
1. **Registration model:** open self-registration vs. school-invites-parents.
(Invite-based is materially safer — recommended.)
2. **Auth foundation:** Supabase vs. custom vs. another managed provider.
3. **Hosting region:** confirm UAE-region data residency with NewWorldEdu.
4. **Does the certification client ever need individual student data,** or strictly summaries?
(Summaries-only is safer and recommended.)
5. **Starky's data:** does the AI tutor write back into grades, or stay a separate log?
None of these block Phase 0. They sharpen Phases 1+.
---
9. What I can build next (on your word)
- The **simplified per-site School Schema (Schema A)** ready for the school, with RLS policies written in.
- The **Board Schema (Schema B)** for the certification client.
- **Wireframes** for the parent/student/teacher dashboards.
- The **Phase 0 public-launch hardening checklist** as a concrete go-live list.
- A **consent-flow design** (screens + data model) for the under-13 requirement.
Tell me which, and I'll go.
```
```