Inspiration
A classroom suddenly becoming unavailable sounds like a simple problem:
Move the affected class to another empty room.
But the best replacement room may already contain another class. That class might be able to move somewhere else, which may require moving another class again.
One unavailable classroom can create a chain reaction.
That led us to build ClassShift:
When a classroom goes offline, repair the schedule—not the whole school day.
Instead of rebuilding an entire timetable, ClassShift asks one focused question:
What is the smallest set of room changes that keeps every class in the affected period running without breaking any modeled requirement?
For school timetable or operations staff, that means recovering from a disruption while changing as little of the school day as possible.
What it does
ClassShift is a decision-support tool for classroom disruption recovery.
The workflow is simple:
Select a period → Mark unavailable rooms → Preview impact → Find recovery → Review changes
ClassShift considers every class in the affected period, not only the class whose room failed.
It respects modeled constraints including room availability, capacity, required room features, verified step-free metadata when required, locked classes, and same-period room conflicts.
Keeping a class in its original room costs 0. Moving it to another valid room costs 1.
The objective is therefore:
Find a complete valid schedule with the fewest room changes.
If no complete assignment satisfies all hard constraints, ClassShift returns INFEASIBLE instead of silently weakening a requirement.
The idea that makes ClassShift different
Our main demo begins when LAB_A becomes unavailable during Monday Period 3.
Chemistry must leave LAB_A, but the room it needs is already occupied.
ClassShift discovers:
Chemistry: LAB_A → LAB_B
Biology: LAB_B → LAB_C
Physics: LAB_C → ROOM_D
Only one room failed, but the minimum valid recovery requires three coordinated room changes.
A simple tool that only searches for another room for Chemistry can miss this solution.
ClassShift instead solves the whole affected period, allowing it to discover relocation chains while still minimizing overall disruption.
That is the core idea behind the project.
How we built it
ClassShift uses Python 3.11, Flask, Google OR-Tools, Waitress, vanilla HTML/CSS/JavaScript, and pytest.
We modeled classroom recovery as an exact assignment problem.
For every lesson-room pair, ClassShift determines whether the room satisfies the modeled constraints. OR-Tools then assigns one room to every lesson while preventing conflicts and minimizing the number of changes.
We deliberately kept the scope narrow.
ClassShift does not regenerate a school's entire timetable and does not change lesson times or periods. It repairs room assignments within the disrupted period, making the proposed recovery easier for an administrator to understand and review.
Building for trust
Finding an optimized answer was not enough.
After OR-Tools proposes a recovery, ClassShift sends it through a separate validator that independently checks that lessons were not dropped, invented, duplicated, or moved to another period; that unavailable or incompatible rooms were not used; that locks were preserved; that rooms were not double-booked; and that the reported move count is correct.
Only a proposal that passes this validation can be displayed as a successful recovery.
For tiny test cases, we also created an independent brute-force oracle and compare the optimizer's feasibility and minimum move count against the exact answer.
This gives ClassShift three different correctness layers:
constraint modeling → exact optimization → independent validation
When the right answer is “no solution”
Our second demo makes ART_1 unavailable during Monday Period 1.
The affected class requires a specialized room feature that no remaining valid room provides.
ClassShift returns:
INFEASIBLE
It does not remove the requirement, assign an invalid room, change the lesson time, or pretend that a software error means there is no solution.
That became one of the principles behind the project:
ClassShift doesn't invent a schedule when the constraints can't be satisfied.
Challenges we faced
The biggest challenge was realizing that the problem was global rather than local.
At first, moving only the directly affected class seems reasonable. But a valid recovery can require moving classes that were never directly affected by the outage. That insight transformed the project from a room lookup into an assignment-optimization problem.
A second challenge was distinguishing “no valid recovery exists” from “the software failed.” We created separate states for invalid input, genuine infeasibility, optimizer errors, validator failures, and unexpected internal errors.
We also deliberately avoided making the optimizer and validator depend on exactly the same eligibility logic. Otherwise one shared bug could make both components agree on the same incorrect result.
Finally, we handled frontend race conditions so an old recovery response cannot overwrite the interface after the user changes the selected outage.
Accomplishments we're proud of
The final RC8 release passed 171 automated Python tests and 34 mandatory release-critical checks.
Testing includes exact optimizer scenarios, differential checks against an independent brute-force oracle, property and edge-case tests, validator-corruption tests, API and multi-period tests, adversarial release-verifier checks, real Waitress endpoint smoke tests, and 16 measured OR-Tools benchmark scenarios.
More importantly, the exact demonstrations we show judges are protected by release tests:
LAB_A / Monday Period 3 → minimum three-move recovery
and
ART_1 / Monday Period 1 → genuine infeasibility
What we learned
The biggest lesson was that a problem can look simple locally while being difficult globally.
We learned how assignment optimization can model interacting decisions, how to use OR-Tools for exact optimization, why optimizer output should still be independently validated, and why INFEASIBLE must be different from a software failure.
We also learned that correctness extends beyond the algorithm. Input validation, API behavior, asynchronous frontend state, adversarial testing, and honest limitations all affect whether users can trust a system.
Most importantly:
Building a useful solution is not only about finding an answer—it is about making the answer understandable, verifiable, and safe to review.
Design and impact
ClassShift hides the optimization complexity behind a simple workflow:
Select outage → Preview impact → Find recovery → Review changes
A timetable administrator can immediately see which classes move, where they move, how many changes are required, and whether all modeled constraints passed validation.
Unexpected classroom closures can disrupt lessons and labs, while rebuilding an entire timetable would be excessive for a temporary room problem.
ClassShift explores a narrower approach:
Preserve the school day and change only what needs to move.
We have not yet tested the prototype with real schools or operations staff, so we do not claim adoption or measured time savings. Real workflow validation would be the most important next step.
Privacy and responsible use
The bundled timetable is completely synthetic and contains no real student records.
ClassShift is a decision-support prototype: a human reviews the proposed recovery before it would affect a real timetable.
Accessibility-related decisions refer only to supplied room metadata. We do not claim regulatory compliance or guaranteed real-world accessibility.
AI use
We used ChatGPT and OpenAI Codex / Terra during development for brainstorming, implementation assistance, debugging, adversarial testing, edge-case analysis, test design, release hardening, and documentation.
AI does not generate ClassShift recovery plans at runtime.
Runtime recovery uses exact OR-Tools optimization, and successful proposals are checked by the independent programmatic validator.
What's next
The next step is not adding more features.
It is testing ClassShift with school timetable or operations staff using synthetic or non-sensitive schedules to learn which constraints matter most in real disruption recovery.
For this hackathon, we kept the goal focused:
When a classroom becomes unavailable, find the minimum-disruption room recovery—and verify it before showing it.
Log in or sign up for Devpost to join the conversation.