A learning platform for courses, institutional enrollment and accountable assessment.
This student information system case study centres on a gradebook that takes marks from teachers, quizzes and external learning tools. Every source uses the same grading method. That method keeps each later change on the record, so it can show who or what gave a mark. Courses hold their own assignments, schedules and grading policies. Each course sits inside the institution's account and enrollment structure.
The challenge
An unpublished mark may need a check before the student is allowed to see it. A provisional mark is different again. It may need a named grader and a moderation slot. Recording the number alone would leave both of those decisions unsettled.
What we built
Teachers manage assignments and rubrics, set due dates and can also run peer review on student work. That review can be anonymous or moderated. A student submission accepts only permitted fields, and a student-supplied grade is not one of them. Group work creates a submission record for each member.
The shared grading route checks enrollment and permission, records the change and recalculates the course score. A mark that meets a module requirement can also move progression forward. Enrollment imports, API requests and self-enrollment all run through one routine that reuses or creates the right enrollment record.
Retain the origin and visibility of a mark
Grade changes are versioned and audited once a prior version exists. The grader record separates a person, a quiz and an external tool. Moderated grading claims an allowed grader slot, while any provisional mark still requires a clearly named grader. Posted and unposted scores are worked out separately.
Repeated recalculation requests are folded into background work, and hidden marks stay outside the student's visible total. External tools submit their results through time-limited tokens. Before a result enters shared grading, the route checks its scope and timestamps against the assignment's publication status. It also checks the attempt count and whether the score is still valid.
Resolve enrollment before serving course access
Course, section and term dates all feed the enrollment state. That resolved state is stored, rather than worked out from every date on each page request. Root-account identifiers carry institutional ownership through the entire shared data model.
Accounts can sit on separate database shards. A single-database deployment is also supported. Background jobs handle grouped grading updates and other work outside the interactive request.
Project success
A reviewer can follow a mark's origin and its change history, including results that came from connected tools. Students see totals that rest on published grades. The enrollment record carries the course-access context behind those assessment decisions, while teaching stays under institutional ownership and permissions.
Technology stack
Application
Ruby on Rails
Frontend
React, TypeScript, Rspack
Data distribution
Database sharding, Switchman
Integrations
REST, GraphQL, LTI
Event delivery
Amazon Kinesis
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.