Grades in, report cards out — every change on the record.

How grades move from entry to report card

The reporting stack has a clear data flow. Every step projects forward from the previous one; nothing is fabricated or re-keyed at the output stage.

1. A teacher opens the gradebook for a class and term. The gradebook class record is the anchor: it names the class, the teacher, the term, and the default grading mode (points or standards). Weighted categories are defined once per class — Tests at 40%, Homework at 20%, and so on, in exact integer basis points so the weighted average carries no float error across a term.
2. Assignments are entered and scored. Each assignment is a record on the class: a title, a mode (points or standards), and a point denominator if points-mode. When a teacher scores an assignment for a student, the score lands in the gradebook score table as a projected value from the collaborative editing surface. The score carries CRDT provenance — which document, which edit sequence — so a stale or out-of-order sync is a no-op rather than a silent overwrite.
3. The projected term grade is computed deterministically. The pure grade calculator reads the class’s category weights, the assignments in each category, and the student’s scores, applies the weighted average in exact integer arithmetic, and writes the result into the gradebook grade table as an integer percentage (tenths of a percent, stored as an integer to avoid float drift). For a standards-mode class, the proficiency projector applies the configured rollup rule per standard and writes per-student proficiency levels alongside.
4. At term close, the term grade is posted. A posted term grade moves to ‘posted’ status and becomes transcript-eligible. The grade carries the course code and title, the letter grade, the grade points on the school’s configured scale, and the credit value — all the fields the cumulative transcript projection reads.
5. The cumulative transcript is updated. The transcript projection reads all of the student’s posted, GPA-counting term grades, recomputes the cumulative GPA in integer milli-points, and updates the transcript row. The transcript is the permanent record: it defaults to the permanent-retention floor defined by state statute (transcripts are permanent in most U.S. states). The COPPA finite-clock sweep that applies to other student records does not auto-expunge a transcript below its state retention floor.
6. A report card is assembled and issued. The report card snapshot is assembled from the student’s posted term grades and the adviser comment. It moves from draft to issued status when the school releases it; that status change is the disclosure event, and it routes through the consent substrate at the boundary — not in the database. A draft report card is internal; an issued one is the record the family receives.
7. The issued report card prints or mails. A printed copy is generated through the publications print pipeline and the VDP flat-paper rail. A mailed copy routes through mailing.software. The print-ready generation is built; the postal-send leg is early-access.

FERPA posture: the school stays the custodian

Grade records are FERPA education records — the highest-sensitivity student PII the platform handles. The data model is built around that fact, not treated as an afterthought.

Every grade table is student-coupled: it carries a student identifier as a direct column, which places it in the rep_pii_wall census. Tenant isolation is enforced at the data layer with a school-leaf Row Level Security policy: a record from one school is never visible to another school’s tenant session, regardless of which application route reads it. The isolation is not a WHERE clause that a route could omit; it is a database policy that fires before the application sees any data.

The disclosure boundary is separate from storage. A grade row in the database is not a disclosure — it is an internal FERPA education record. The disclosure event is when the school emits a report card or transcript to a parent, a printed copy, or a digital credential. That emission routes through the consent substrate at the boundary: the consent check happens at the emit call, not in the database. A student’s grade record persists in the gradebook even after a consent withdrawal; the consent gate prevents the disclosure, not the record.

Reading a grade for the school’s own operational purposes is a separate path from disclosing it to a family. A defined school-official role list — teacher, adviser, school administrator, district administrator — can read gradebook records for legitimate educational-interest purposes, which is distinct from the guardian’s directory-information consent that gates an external disclosure. The two are never conflated: an internal read by a school official does not require the same consent check as an emission to a parent or a printed report card.

The platform is SIS-adjacent by design. It imports the roster from whatever student information system the school already uses; the school keeps the authoritative enrollment record in its existing system. Grade records tie to the imported roster. The platform does not replace the school’s SIS and does not claim to do so.

A commissioned rep or studio partner, operating in their normal rep-scoped session, reads zero grade rows. Not filtered rows — zero rows. The RESTRICTIVE policy at the database engine means even a route that forgot to check the role cannot surface a student’s grades to a rep. The school’s students’ grades are never visible on a rep or studio surface, by construction.

Transcripts: the permanent record

The cumulative transcript is the student’s permanent academic history: every posted course, the letter grade, the credit value, and the contribution to cumulative GPA. It is permanent by design, not by convention. The transcript row defaults to the transcript_core retention class, which maps to the permanent-retention floor by state statute: transcripts are permanent in most U.S. states, with minimum retention floors of 60 years (Illinois, Massachusetts) and 100 years (Washington) for the others. The COPPA finite-clock data-sweep that applies to other student records does not auto-expunge a transcript below its state floor.

The cumulative GPA is computed by a pure deterministic projection function: the same inputs always produce the same result. GPA is stored as integer milli-points (a 3.667 GPA is stored as 3667) so there is no float accumulation error across a student’s full course history. The GPA scale the school posts on — 4.0 unweighted, 4.0 weighted, 5.0 weighted, 100-point, or another label — is carried as a text label on the transcript record so a reader knows what scale produced the number.

Every transcript carries both a weighted and an unweighted cumulative GPA, computed from the same posted term grade rows in the same pass. The unweighted figure is the identical credit-weighted mean with the honors/AP rigor bonus stripped back to its base band value — never re-authored from a second calculation — and it is clamped so the unweighted number can never come out higher than the weighted one. A second, independently-derived engine GPA — built from its own quality-point table and its own rigor-level roll over the same cleared rows — rides alongside as a cross-check, so a discrepancy between the two calculations surfaces rather than silently resolving to one answer.

The transcript is built from term grade rows: every section the student has completed, with the section’s course code and title carried onto the transcript line directly, so the transcript is readable without joining back to a course catalog. A transfer or legacy record, entered manually rather than projected from the gradebook, is supported as a distinct source type on the term grade row (“imported” or “manual”) so a reader can distinguish a natively computed grade from one entered by hand.

Emitting a transcript to a parent, a college, or a digital credential is a disclosure event. That emission routes through the consent substrate at the boundary. The transcript row persists after a consent change; the consent gate at the emit boundary is what controls whether the disclosure is permitted.

Class rank and honor roll: cohort-wide, consent-gated

Alongside the individual transcript, the substrate projects a cohort-wide class rank and honor-roll banding for a school year: standard rank and dense rank, computed over every posted, GPA-counting term grade for the whole cohort in one deterministic pass, plus honor-roll bands keyed to school-configurable GPA floors (a High Honors floor and a Honors floor, for example). Rank and honor roll are recomputed the same way every time from the same posted rows — not hand-maintained, not a spreadsheet export.

Consent gates the rank exactly the way it gates a transcript disclosure. A student who has not cleared directory-information consent still counts toward every other student’s correct rank — removing them from the count would shift everyone else’s number — but that student is withheld from the emitted rank list itself. The gate is fail-closed and default-deny: directory information is opt-in, so a student with no consent decision on file is treated as not consented, not as silently included.

Where no grade scale is configured for a school, class rank and honor roll are honest-off: the projection falls back to a plain 4.0-unweighted label with no honor-roll banding, rather than inventing a scale the school never set.

SIS-adjacent, not a replacement

The grading-and-reporting substrate is designed to sit alongside the school’s existing student information system, not to replace it. The school imports its roster — from whatever SIS it already uses, in the format that system exports — and the gradebook reads student identifiers from that imported roster. The authoritative enrollment record stays in the school’s existing system; the platform reads from it on import and reflects changes on the next import cycle.

Grade records are tied to the roster identifiers. A student who appears on the roster can have scores, term grades, and a transcript on this system. A student who does not appear on the current roster cannot have active gradebook entries. The roster is the foundation; the grading substrate builds on top of it.

The scheduling core (schedule.software) and the student record (homeroom.software/records) are adjacent modules that share the same roster. A term in the scheduling core corresponds to the term key in the gradebook. A section in the scheduling core is the section the gradebook class record belongs to. The modules share the data model; they do not each maintain separate copies of the student list.