Standards-based mastery.

Standards-based grading does not replace the percentage in the gradebook. It hangs a second record off the same assessments — a per-standard proficiency rating, recorded on a scale the school authors itself. A maths test still earns 14 out of 20; it also, separately, tells you the student is Proficient on "applies the Pythagorean theorem" and Approaching on "interprets a word problem." Both records coexist on the one assessment.

One honest note up front. YESS carries two "standards" code paths. The one this handbook documents in depth — with an admin screen, a grade-entry surface, and a report-card hook — is the standards-based grading system at /dashboard/standards, built on four tables. A second, newer path tags LMS assignments with learning standards; its data layer exists but it has no screens yet, and we flag it plainly in its own chapter rather than pretend it is live.

Grade against what a student can do — on the school's own scale, standard by standard, beside the number that never quite said it.

Everything starts with a rating scale: the words a school uses to describe proficiency. A scale is a named, reusable list of levels, each a value and a label — the admin page seeds a sensible default of 1 Beginning · 2 Approaching · 3 Proficient · 4 Advanced, but the levels are entirely school-authored. Build a 4-point scale, an 8-point IB-style scale, a 3-band rubric — whatever your reporting asks for. The levels are stored as JSONB, so a scale can be any length.

Scales are defined in the first section of /dashboard/standards. One scale can be marked the school default; individual standards either inherit it or override it with a scale of their own. This is the reuse that keeps the system coherent — define "Beginning → Advanced" once and every subject can speak the same language.

A standard is one specific competency in one subject. In the second section of the standards page you pick a subject and add standards to it, each carrying a code (e.g. HSA.APR.A.1), a name, an optional description, an optional framework tag, and an optional rating-scale override. Standards are hierarchical — a standard can have a parent — and soft-deleted rather than erased, so historical ratings survive.

The framework field is a labelling convenience, not a constraint. The admin picker offers five presets — IB MYP, NGSS, Common Core, Cambridge, and Custom — but the value is stored as free text, so a school can record whichever curriculum a standard belongs to. It tags and groups; it does not enforce a fixed vocabulary.

This is the load-bearing step, and it is easy to miss. A standard only becomes rateable once it is mapped to the assessment components that measure it. The third section of the standards page is exactly this: pick an assessment component — a CA1 quiz, a term exam, a practical — and tick the standards that component assesses. Each tick writes a row into assessment_component_standards; un-ticking removes it. Mappings save instantly.

Without a mapping there is no data path: the grade-entry rating UI stays hidden, and the report-card populator finds nothing to roll up. So the standards walk is a once-per-term routine — define scales, define standards, then map each standard to the assessments it lives in. Every mapping currently carries equal weight; per-standard weighting is on the roadmap.

Teachers never leave the gradebook to do standards. The proficiency rating lives inside grade entry at /dashboard/grades. When the selected assessment component has standards mapped to it, each student row grows a small standards button; opening it brings up a dialog that lists every mapped standard and renders that standard's scale levels as buttons. The teacher clicks the level — Proficient, Advanced — and the rating is saved instantly to student_standard_ratings, one row per student per component per standard, with the teacher stamped as recorder.

Recording a rating needs the standards.rate permission, which teaching staff hold by default. There is no automatic conversion between the numeric score and the proficiency level — the teacher enters the number for the gradebook and, separately, clicks the proficiency. The two records are independent by design, so a school can run mastery reporting without re-engineering how it marks.

Report-card templates carry a show_standards_mastery toggle, set in the template builder at /dashboard/report-cards. When it is on, the report-card data populator gathers each subject's per-standard ratings — code, description, the level and label, the date recorded — and embeds them in the report-card data so the document can carry a mastery section beside the marks.

Be precise about where this stands today. The toggle and the populator are real: enabling it makes the system collect and store the mastery rollup. The final rendering — drawing that rollup onto the printed report card and the parent portal — is the piece still in flight. So a school can configure and record standards mastery now, with the visible report-card section landing in a follow-up. That honesty matters more than a tidy claim.

Alongside the grade-entry system above, YESS has a schema for tagging LMS assignments with learning standards and rolling submission grades up into a per-standard mastery view. The tables, the row-level security, and the read hooks all exist. What does not exist yet is any screen: there is no UI to tag an assignment with a standard, and nothing renders the mastery view.

We document it here only so you know the difference. When this handbook says "standards," it means the grade-entry system on /dashboard/standards. The LMS-assignment alignment path is a foundation laid for a future release, not a feature you can use today.