Tracks & streams.

Read this before you build anything, because the word "track" carries more weight in conversation than it does in the data. In YESS a track is a tag — a named, colour-coded label with an optional description, created at /dashboard/tracks and pinned onto a section. "Sciences," "Arts," "Commercial," "Bilingual" are just values you type. A track has no subject list of its own, no higher-level / standard-level setting, and no table that assigns students to it directly. A student is "in" a track only because they sit in a section that carries it.

The substantive part — which subjects a student commits to — is a different, genuinely built machinery that hangs off the programme, not the track: subject groups with pick counts and levels, named paper combinations, a rules engine that validates a proposed set, and an elective self-service flow with parent consent and add/drop windows. That is where the real work happens, and most of this handbook is about it.

One honest caveat up front: the tagline's promise that tracks are "modelled as tracks the timetable and transcript both understand" is aspirational. Today the timetable solver and the transcript builder do not read the track tag — it is a label for humans, not yet a key the engines consume. The roadmap at the end says so plainly.

The label is light; the machinery beneath it is not.

Tracks are managed at /dashboard/tracks — a grid of cards with summary tiles for total, active, and inactive. A track carries a name, a short code (unique within the school), a colour swatch, a description, a display order, and an active flag. Deleting one is a soft delete, and a track that is switched off simply stops appearing as a choice. That is the entire model.

A track becomes visible on a section through the class and section editor at /dashboard/classes: a section's form shows a track picker only when the school has created at least one track, and choosing one stamps the track onto that section. From then on the coloured track badge rides alongside the section wherever it appears. Schools that don't stream simply never create a track, and the picker never shows up.

The first real piece of the combination machinery is the subject group, managed per programme at /dashboard/programs/[id]/subject-groups. A subject group is a "pick from these" set with a minimum and a maximum number of choices — the IB-style structure where a student must choose, say, one subject from the sciences group and two from the humanities.

Each subject in a group carries its allowed levels — higher or standard — as a set of values, and the group can hold richer level constraints (for example, "at least one higher-level pick, at most three") as a structured rule alongside the pick counts. This is how the school encodes the shape of a valid choice before a single student picks.

Where subject groups describe rules, a paper combination describes a named, ready-made bundle — the GCE A-level world's PCM (Physics, Chemistry, Maths), CMB (Chemistry, Maths, Biology), and the like. They live per programme at /dashboard/programs/[id]/paper-combinations.

A combination is a name and code, a set of subjects (each marked required or optional), and — usefully for guidance — the career targets and example university courses it opens up. So a student choosing a combination isn't reading a bare list of subject codes; they see "this is the science-and-engineering path, and here is where it leads."

A school's subject-choice policy is enforced by a rules engine. Each rule has a type — drawn from ten, including must-include, must-exclude, mutually-exclusive, pair-required, count limits within a group, and age, grade, language, and capacity gates — and an enforcement mode that decides how hard it bites.

Every rule must carry a written rationale, so a policy is never a mystery constraint — the reason travels with the rule. When a student proposes a set of subjects, the validator evaluates every applicable rule and returns one result per violation, marked block, warn, or info, so the choice screen can show exactly what is wrong and how seriously.

All of the above is scaffolding for the one thing that is per-student: the set of subjects a student is actually enrolled in. Core subjects are enrolled for them; electives are a choice — and YESS runs that choice as a proper, consented workflow rather than an admin typing it in.

A student (or their linked parent) opens /portal/electives and requests an elective. The request runs through the validator, honours the programme's parent- consent setting, and lands as active or pending parent approval depending on policy; a parent then approves or rejects it. Dropping an elective is equally governed — it respects an add/drop window and refuses to drop a subject that has been locked for an exam. A single view resolves each student's effective subjects and tells you, for each, whether it is enrolled, pending approval, an opt-in still owed, or auto-enrolled.

The subject-combination machinery is real; the track tag is deliberately light, and a few of the connections implied by the marketing are honest roadmap. Here is the straight picture.

Tracks and combinations sit on top of the academic structure and feed the exam and reporting spine. Here is what connects to what.