Exam setup workflow

Split this into two passes. The first is one-off school configuration - the Examination committee, the venue master and the notification events - and is done when examinations are first switched on. The second repeats for every cycle: create the session, set its dates, then schedule papers. /exam-setup is a read-only checklist that reports which one-off items are done and links to the screen that does each job; nothing is configured on that page itself.

Committee membership is the access mechanism, not a role. With strict RBAC on, which is the default unless the EXAM_STRICT_RBAC environment variable is explicitly set to false, exam coordination is limited to school leadership and members of a committee whose name, code or type identifies it as the Examination committee. Everyone else with a teaching assignment gets only the participant surfaces: their setter tasks, marking tasks, invigilation duties and homeroom exam view.

One-time setup

1. Create the Examination committee at /committees with a chair and the exam-cell members; the chair is the account that will publish papers and release results.
2. Define halls at /exam-venues with a name, optional code and location, and a seating capacity the seating generator can use.
3. Configure per-event email and in-app toggles at /settings/exam-notifications and verify SMTP; only Platform Admin, Principal and Vice Principal can edit these.
4. Leave strict exam RBAC on unless you deliberately want the legacy behaviour where any assigned teacher may coordinate.
5. Wire the exam cron jobs on the server if you rely on timed exam reminders.

Per-cycle session creation

1. Create the session at /exam-schedule with a name, the academic year, a start and end date, and optionally a term, a type such as summative or board, a board name and a default pass percentage.
2. Session dates must fall inside the linked academic year; a range that spills outside it is rejected outright.
3. If the range overlaps configured holidays or non-working days the request comes back as a clash needing confirmation - confirm deliberately or move the dates.
4. Bind the session to the Examination committee so chair-gated actions apply; any coordinator can bind it, and an inactive committee is refused.
5. Optionally require class teacher sign-off before results publish; turning it on notifies the class teachers.
6. Optionally set a minimum number of working days between two papers for the same class.
7. Set the schedule publish date once the paper timetable is firm, since families see nothing before it.

Who can do what

What breaks if you skip a step

• No Examination committee: exam-cell staff who are not leadership never see the full exam navigation, and chair-gated actions fall back to any coordinator.
• No venues: papers can be created but not allocated a hall, so seating and hall tickets cannot be generated.
• Notification events left off: setters, invigilators and families get nothing, and the workflow silently depends on people checking screens.
• Session not bound to a committee: publish and results release stay open to every coordinator rather than the chair, which is legal but removes the governance boundary.
• Session archive-frozen too early: the session and its papers, marks and seating become read-only and publishing is refused.

Handoff and limits

Setup hands off to scheduling, which places papers on dates and allocates venues and invigilators, and to paper setting, which authors the content. It also hands off to the academic calendar, which records examination days. Once sessions exist, leadership dashboards show upcoming session counts and a comparison chart of pass rate and average across recent sessions.

• There is no exam session template - each cycle is created from scratch, though papers can be added in bulk.
• Venues carry a capacity number but no room layout editor; seating is generated from capacity.
• The committee is identified by name, code or type matching Examination, so a committee named something else will not grant exam access.