The student journey.

The student-information book next door is the static record — the names, the documents, the family. This book is the moving part: what happens to a student over a year, and how YESS makes each step visible to the person it happens to. A school runs the spine from the registrar's chair; the student and parent ride it from a phone. Both see the same truth, scoped by the same row-level security — a parent sees only their children, a student only themselves, a graduate reaches their own alumni record by their own login.

We follow one student, Amina, through a year at Greenwood — the school this handbook uses as its example — from the day her application converts to the day she graduates.

A producer with no consumer is a silent bug. This book closes the loops.

The registrar converts Amina's application. In most systems that is the end of the story for her — she finds out which class she's in by reading a printout taped to a wall. In YESS, the conversion writes a student_enrollments row, and that insert fans out: Amina and every linked parent get a notification — “You have been enrolled in Form 5 Sciences, 2025/26” — deep-linking to /portal/enrolment, where she sees her current program, class, and section, her status, and her full year-by-year placement history.

Promotions at year-end carry their own fanout, so the rollover never double-notifies. The two producers — fresh enrolment and rollover — are deliberately separated so each speaks once.

Placement auto-enrols Amina's core subjects the moment her section is set. Her electives are hers to pick: she opts in or drops on /portal/electives or on the mobile subjects screen. Where the school requires it, a parent approves the choice before it sticks — the same RPC, a different actor.

Every write flows through the opt-in / withdraw / decide RPCs, and the write-side row-level security is permission-gated, not school-wide — a student can only move their own enrolment, a teacher needs electives.manage or students.edit.

Conduct is not a single hidden number. Every mark — a deduction or a bonus — carries the teacher who recorded it and the reason. On /portal/conduct (and the mobile conduct screen) Amina sees her per-subject standing for the term and can tap any subject to read the timeline: teacher X removed two marks for lateness; teacher Y added one for helping a peer. Attendance-sourced events are labelled as such.

Discipline records — warnings, suspensions, expulsions — are a parent's responsibility to acknowledge. On /portal/discipline and on mobile, the parent acknowledges or disputes each one; a dispute notifies the school to review it.

A “computer-based” exam should not require a computer. The proctored online-exam taker runs natively on the phone: /portal/online-exams lists the section's exams; Start Exam opens the taker. An access-code gate, a live countdown that already includes a SEN student's extra-time allowance (from an active extra_time accommodation), per-answer autosave, flag-for-review, a numbered question palette, and answer inputs for multiple choice, true/false, short answer, fill-in-the-blank and essay — all graded by the same engine as the web.

Integrity is handled honestly for the medium. The web's tab-switch detector maps to the one signal a phone can give — leaving the app — which is counted, written into the attempt's suspicious-activity log, and auto-submits at the school's limit. Webcam and browser-lock are desktop-only, and the taker says so rather than pretending.

A university student should never wonder how far they are from the degree. The live degree audit on /portal/degree-audit (and on mobile) renders every requirement, credits earned against target, year-by-year GPA, per-subject attendance, and a ready-to-graduate banner — computed by one RPC so the student and the registrar read the same numbers.

Final-year students see their capstone or thesis on /portal/capstone: the project, its status and abstract, the supervisor, the milestone timeline with a completed count, and the defense — scheduled date, score, pass. The supervisor side lives at /dashboard/capstones; the student sees a read-only window onto their own.

When Amina's status flips to graduated, three things happen at once: an alumni_profiles row is created by the graduation trigger, her diploma is issued by the registrar, and — the part most systems forget — she is told. She and her linked parents get “Congratulations, you've graduated! 🎓,” deep-linking to /portal/my-alumni-profile, where she sets up and edits her alumni profile (saving lands her on the public /portal/alumni directory). Her transcripts live one route over at /portal/transcripts.

A parent with three children should not open three apps. The children-overview dashboard (web /portal/parent, and the mobile My-Children overview) gives one card per child: pending logbook approvals, assignments due this week and overdue, recently graded work, a term-grade and 14-day-average badge, today's attendance and absences this week, open conduct incidents, and the child's canteen wallet with a top-up dialog — each card deep-linking into report cards, grades, and conduct for that child. An “Approvals pending” KPI heads the strip.

Every parent surface in this book uses the same multi-child picker and the same row-level security as the web portal — there is no second security model for the phone.

Discipline, conduct, the degree audit, the exam taker, the parent dashboard, My-Enrolment, and capstone all exist on Expo with the same data, the same RLS, and the same multi-child picker as the web portal. The mobile screens query the same tables and policies directly; a fix to a policy fixes both platforms at once.