HandbookAdmissions & lifecycle03b

The student journey.

Most school systems serve the administration. The data is correct, the reports compile, the registrar is happy — and the student living inside that data sees almost none of it. This handbook is the other half of the academic spine: the same admission→exit journey, made legible to the student and the parent, on the web and on the phone, in the family's own language. Every event the school records, the people living it get to see — and where they should act, they can.

  • 7lifecycle stages
  • 8mobile parity screens
  • 9chapters
  • ≈16 minto read

Prologue

The journey, and who it's for#

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.

Chapter one

Enrolment, announced#

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.

Chapter two

Subjects the student chooses#

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.

Chapter three

Conduct, with a name attached#

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.

Chapter four

Exams, in the hand#

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; tapping one opens the taker. An access-code gate, a live countdown that already includes a SEN student's extra-time allowance, per-answer autosave, flag-for-review, a question palette, and six question types 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.

Chapter five

The finish line, visible the whole way#

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.

Chapter six

Graduation, celebrated#

When Amina's status flips to graduated, three things happen at once: her alumni profile is created, her diploma is issued by the registrar, and — the part most systems forget — she is told. She and her parents get “Congratulations, you've graduated. Class of 2027,” deep-linking to /portal/my-alumni-profile, where she reaches her alumni profile, her transcripts, and her diploma.

Chapter seven

The parent's one screen#

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, recent graded work, quizzes, and recent average — each card deep-linking into report cards, grades, and conduct for that child. An action banner surfaces the approval queue first.

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.

Chapter eight

Mobile parity as a contract, not a courtesy#

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.