At a glance: the prototype and the system it came from
Step through the prototype I worked on. Switch to the legacy system to see what the team started from.
Help Sam plan a semester
The point of the whole project is to help a student choose courses that actually move them toward their degree. Sam is a made-up student. Pick his courses and watch his reaction: some count, some are wasted, some are not part of his major, and some pairs are a heavy load together. Then ask the school to approve the plan, and revert if it goes wrong.
Whose work is whose. Matching courses to degree requirements is the job of the platform's engine, which the university team built as an integer linear program solved with Gurobi. The matching here is a small stand-in I wrote for this page. My prototype is the version history panel: every plan is stored as a version, and revert returns to the previously approved one. The program, courses, credit minimum, and the "tough combination" warning are invented to show the project's goal, a plan that counts without being too heavy, and nothing here reads or writes university systems.
Overview01
The University of Arizona runs an analytics platform that compares credits earned against expected pacing and classifies each student as On Track, Behind, or Ahead, so advisors can spot patterns across a whole cohort. That system already existed when I joined.
Our student team was asked to restructure it and prototype a new approach, so that data science and machine learning work could be added to the pipeline later. We did not build that data science work ourselves. Our job was the bedrock it could be built on. I studied the existing architecture from its design documentation, then built and tested one piece of the new backend.
The rule behind the legacy platform02
Open the interactive pace check
To understand the legacy system, I re-implemented its central rule myself. Move the sliders on a made-up student and watch the status change.
Illustration only. The student and the tolerance setting are invented, and no university data or code is used. The platform's version was written by the university team and is not part of my prototype. This one is my own re-implementation of the documented rule, available as tested Python in the repo; this page runs a JavaScript copy that matches it on all 6,384 shared test cases.
My part03
I worked on this in spring 2026 as a student contributor on a University of Arizona Vertically Integrated Projects (VIP) team. VIP is a university program in which faculty-led teams of undergraduate and graduate students work on long-term, multidisciplinary projects. Our team was led by Kristina Manasil, on a project overseen by Greg Heileman. My hands-on work was the backend prototype shown above: an AWS Lambda function, built and deployed in the AWS console, that takes read and write requests as JSON, a new DynamoDB table for the current plan, and version history in S3. Every plan is stored, and revert returns to the previously approved one, meaning the last plan the school cleared for credits and curriculum fit.
What worked: the function ran behind its own URL against the new table, kept every plan version in S3, and reverted to the previously approved plan. What was left: connecting the front end, and deciding how the prototype would fit into or replace parts of the existing system. It never touched the live database and was not released to production.
Student privacy: the student data used in this work was anonymized in line with FERPA, and I completed the university's FERPA training before working on the project.
What the prototype adds
| Legacy design | Prototype | |
|---|---|---|
| History of a student's plan | None. Data is static once it is loaded | Every plan is stored as its own version |
| Undoing a change | Restore a manual backup of the whole table | Revert one plan to its previously approved version |
The legacy column is taken from the platform's own design documentation. I have no measured numbers for the prototype, such as speed or usage, so none are shown.
The legacy platform, including its ETL, course-matching optimizer, pace classification, API, dashboard, and deployment pipelines, was built by the university team before this project. They describe it in a 2024 ASEE conference paper, on which I am not an author.
Tech
What I used
Legacy platform, built by the university team