At a glance
- Treat overrides as a governed feature of the scheduling process, with a named requester and approver for each type, not as a workaround outside the system.
- An override governance matrix covering six override types — pinning a section, moving a room, an instructor swap, a late addition, and waiving a soft or hard constraint — makes who decides and what gets checked explicit and repeatable.
- One timetabling paper (Müller, Rudová & Barták, 2005) treats a change after publication as a minimal perturbation problem: re-solve so the new schedule stays as close as possible to the one already published, not as a fresh problem from scratch.
- A late change after publication follows a fixed procedure — request, review, automatic re-check, approval, and notification — with a freeze deadline after which only a formal exception applies.
- Every override needs a log entry with who approved it and why; when the audit log shows the same waiver recurring term after term, that pattern calls for fixing the underlying constraint, not another approval.
Why overrides are a feature, not a failure
An optimizer that can't be overridden isn't more rigorous than one that can; it just pushes every exception outside the system, into a side spreadsheet or a verbal understanding nobody wrote down. A registrar's office always has cases a general rule can't anticipate: a visiting instructor's one-week window, a lab tied to an accreditation visit, a late-approved program's new section. The question isn't whether exceptions happen. It's whether they happen inside a governed process or around one.
The failure mode isn't the override itself — it's one with no named approver, no record of why it was granted, and no check that it didn't break a hard constraint elsewhere. We'd expect that on a manual schedule too; an optimizer mainly makes it visible, since a record now exists for it to go around.
Treating overrides as a governed feature means fixing, in advance, five things for every override type:
- Who may request it.
- Who approves it.
- What the system re-checks automatically once it's applied.
- What gets logged.
- When it stops being available, because a freeze deadline has passed.
The override governance matrix
Use the two tables below as a working reference: pick the row matching the change being requested. The first table names who can ask for it and who signs off; the second names what the system checks automatically, what gets logged, and the deadline that applies. Copy them into your own procedure and adjust the named roles to your institution's structure.
| Override type | Who may request | Who approves |
|---|---|---|
| Pin a section (lock time, room, or instructor) | Department chair or scheduler | Registrar scheduling lead |
| Move a room | Department scheduler or facilities | Registrar scheduling lead (facilities co-signs on capacity or accessibility changes) |
| Instructor swap | Department chair | Department chair; registrar co-signs if the new instructor has a conflicting assignment |
| Add a section after publication | Department chair | Registrar scheduling lead and the funding office (e.g., the dean's office) |
| Waive a soft constraint | The constraint's named owner | That owner, on their own authority |
| Waive a hard constraint | Department chair or dean, in writing | The rule's owner (registrar, financial aid, accreditation, or disability services) plus academic leadership |
The second table lines up with the same six rows, this time covering what the system checks, what gets logged, and when the window closes.
| Override type | Automatic re-check | What gets logged | Deadline / freeze rule |
|---|---|---|---|
| Pin a section (lock time, room, or instructor) | Audit against hard constraints on the pinned section before the pin is accepted | Requester, approver, reason, and the re-solve run it was applied in | Open until the freeze deadline; after that, use the late change procedure |
| Move a room | Check for capacity and accessibility features against enrolled or expected size | Old room, new room, reason, and approver | Open until the freeze deadline; after that, use the late change procedure |
| Instructor swap | Check for double booking across every section the new instructor already teaches | Outgoing and incoming instructor, reason, and both approvers | Open until the freeze deadline; after that, use the late change procedure |
| Add a section after publication | Re-solve to place the new section, moving others only as strictly required | Section details, reason, and every section the re-solve moved as a side effect | Formal exception needed after the freeze deadline; routine adds close before it |
| Waive a soft constraint | None beyond the normal quality score; a soft constraint is meant to be traded off | Which constraint was waived, for which section, and why | No deadline; review waiver volume each term |
| Waive a hard constraint | Re-check that the waived instance doesn't create a second, unintended conflict | Full written justification, both approvers, and an expiration date | Rare and time boxed; a recurring waiver signals the constraint is misclassified |
Pinning and re-solving without chaos
How do you lock sections so the optimizer doesn't move them? Pin the section's assignment as fixed, then re-solve so the change ripples only as far as it has to, not across the schedule. One timetabling paper, Müller, Rudová and Barták (2005), calls this the minimal perturbation problem: real scheduling problems are dynamic, and [1] "changes in the problem definition occurring after a solution to the initial formulation has been reached" are common enough that the re-solve needs a defined goal, not just a re-run of the original solver.
That goal, as the same paper puts it, is to treat the change [1] "along with the initial solution, as a new problem whose solution must be as close as possible to the initial solution," not solved from a blank slate. The same reasoning applies to a pinned section: [2] "Once timetables are published they require many changes based on additional input. These changes must be incorporated into the problem solution with minimal impact on any previously generated solution."
A pin that forces a section into a new time, room, or instructor is the input perturbation this paper describes: a variable that must take a different value between the two problems. As the paper defines it, [3] "input perturbation means that a variable must have different values in the initial and changed problem because of some input changes." The re-solve's job is to minimize every other change beyond that forced one — judged by how few other sections moved, not only by whether the result is feasible.
Handling a change after the schedule is published
Once a schedule is published, students have registered against it, so a change costs more than one during initial build. The procedure below treats a late change as its own governed path, with a freeze deadline after which only this path applies.
- Requester submits the change with a stated reason
The department chair, instructor, or scheduler states what's changing, why, and which section it affects, before any re-check runs.
- Instructor and department review
The instructor of record and department chair confirm the change is accurate and needed before it moves forward.
- Registrar checks the request against the freeze deadline
Before the freeze, the routine override path in the matrix above applies. After it, only a formal late-change exception, with the escalated approval it requires, is available.
- System re-check: hard-constraint audit and a minimal-perturbation re-solve
The system re-checks every hard constraint against the change and re-solves to move as few other sections as possible, reporting how many sections moved beyond what the change strictly required.
- Named approver signs off
The registrar scheduling lead approves routine late changes; a change requiring a hard-constraint waiver additionally needs sign-off from whichever office owns that constraint.
- Log the change and notify affected students and instructors
Record who requested and approved the change, why, and what the re-solve moved, then notify everyone whose section, room, or time shifted as a result — not only the person who requested the change.
Keeping an audit trail of every exception
The governance matrix names what gets logged; the audit trail is where that log lives, and it only works if every override writes to the same place. A pin in a spreadsheet, a swap approved by email, and a waiver noted in department files can't be reviewed together, defeating the point of logging any of them.
- Keep one log for every override type in the matrix, not a separate record per department, so patterns are visible across the whole schedule.
- Every entry names the requester, the approver, the date, the reason, and — for a re-solve — how many other sections moved as a side effect.
- Review the log by volume each term: which overrides, and which departments or constraints, concentrate there. If the same waiver keeps showing up in that review, treat it as a signal to reclassify the constraint, not a reason to keep granting the waiver quietly.
- Treat the log as the answer to "why was this section placed here" for a department chair asking later. If it can't answer that, the logging step in the matrix isn't complete.
When to stop overriding and fix the rules
An override process that works well still has a limit: if the same constraint gets waived every term, the problem isn't that people keep needing exceptions. It's that the rule is misclassified or weighted wrong, and the fix belongs in the constraint model, not in another approval.
- A hard constraint waived more than once or twice a term is a sign it isn't actually hard — reclassify it, using a decision process like the one in hard vs. soft constraints in academic course scheduling, rather than keep approving exceptions to it.
- A soft constraint waived on nearly every section it applies to is likely weighted too high; lower its weight tier instead of treating every section as an exception.
- If overrides concentrate in one department every term, address that department's specific constraints, not the governance process for everyone.
- When your current exception process is already small, stable, and reviewed by one accountable person, a formal matrix may be more process than the volume justifies; introduce it once volume or turnover makes an informal process hard to trust.
This distinction — override the exception, or fix the rule — is itself a decision that stays with people, not the optimizer. The system can report how often a constraint gets waived; only the registrar's office and academic leadership can decide what that means.
Frequently asked questions
How do you lock sections so the optimizer doesn't move them?
Pin the section's time, room, or instructor as a fixed value the re-solve treats as a hard constraint, then re-solve so other changes ripple only as far as needed. If the pin instead moves the section to a new time, room, or instructor, one timetabling paper calls that an input perturbation. Judge it by how few sections moved, not feasibility.
Which sections should be excluded from optimization?
None by default; exclude a section only when a named requester has an approved reason to pin it — a fixed accreditation site-visit time, a visiting instructor's narrow availability, or a similar constraint the optimizer can't otherwise capture. Log the reason with the pin, and review excluded sections each term so the exclusion doesn't quietly become permanent.
Who approves a scheduling exception?
It depends on the override type. In the matrix above, the registrar scheduling lead approves pins and room moves, the department chair approves instructor swaps, and a hard-constraint waiver needs sign-off from whichever office owns that rule, plus academic leadership. The governance matrix names an approver for each type in advance, so the answer isn't decided case by case.
Should exceptions expire each term?
Yes, for anything tied to a specific term's circumstances: a pin, a room move, or a hard-constraint waiver should expire when the term it was granted for ends, with a new request required next term. An exception that silently carries forward stops being reviewed, which is how a genuine one-time case turns into an unexamined standing rule.
How do you track override volume?
Log every override in one place, regardless of type or department, with the requester, approver, and reason. Review that log each term for volume and concentration — which constraint or department accounts for the most overrides. A concentrated pattern is a signal to fix the rule, not a reason to keep approving exceptions to it.
Do accessibility accommodations override optimizer output?
Accessibility requirements are a policy input the disability-services office owns, not a preference the optimizer weighs against others; the registrar's scheduling system applies that office's determination rather than reinterpreting it. This article doesn't give legal guidance on which accommodations apply — that determination belongs to disability services and, where needed, counsel.
Related reading
- For the workflow this governance matrix protects, see academic scheduling optimization, which covers inputs, steps, and acceptance criteria.
- For where human judgment must stay in an automated process generally, read human-in-the-loop AI governance.
- For the classification decision that determines whether a rule can be waived at all, see hard vs. soft constraints in academic course scheduling.
Sources
- [1] — Müller, Rudová & Barták, "Minimal Perturbation Problem in Course Timetabling" (PATAT 2005), Abstract (accessed 2026-09-28)
- [2] — Müller, Rudová & Barták, "Minimal Perturbation Problem in Course Timetabling" (PATAT 2005), Section 1 (accessed 2026-09-28)
- [3] — Müller, Rudová & Barták, "Minimal Perturbation Problem in Course Timetabling" (PATAT 2005), Section 3 (accessed 2026-09-28)
- [4] — University of Arizona, Office of the Registrar, "Change of Schedule Information" (accessed 2026-09-28)
- [5] — University of Arizona, Office of the Registrar, "Late Change Petitions for Single Course Drops" (accessed 2026-09-28)
More in Higher education
AI Agents vs RPA in Higher Education: Choosing for Banner, Workday Student and Legacy SIS Workflows
AI agents vs RPA in higher education: a vendor-neutral decision table for CIOs choosing between RPA, AI agents or both for Banner and Workday Student workflows.
AI Transcript Processing for Admissions: Extraction, GPA Recalculation and the Exception Queue
AI transcript processing for admissions: how extraction and GPA recalculation work, an exception-routing table, and what should always reach a reviewer.
How to Automate Financial Aid Verification: Document Intake, Mismatch Flags and Where Counselors Decide
How to automate financial aid verification: a document intake and mismatch-flag workflow matrix, plus exactly where a counselor still decides.