At a glance
- A constraint is hard only if breaking it is physically impossible or the institution can't waive it; everything else is a soft-constraint candidate.
- A three-question classification table, plus a two-factor weight-tier table for soft constraints, keeps the classification consistent and defensible when someone asks why.
- Soft constraints still need weights, and setting them is a policy choice for the registrar's office, not the solver.
- Every constraint needs a named owner and a place waivers get logged, or the classification goes stale once the facts change.
What makes a constraint hard or soft in course scheduling
In course scheduling, a hard constraint is a rule every accepted schedule must satisfy, and a soft constraint is a rule a schedule can break at a cost the solver tries to minimize. Breaking a hard constraint means the result doesn't count as a solution; breaking a soft one just adds to a cost the process is asked to keep low.
That split shows up directly in the software built to solve these problems. In his ITC 2007 solver-description paper, hosted by UniTime, Tomáš Müller writes that his solver library's local-search algorithms [1] "operate over feasible, though not necessarily complete, solutions," where some variables may be left unassigned, but [1] "[a]ll hard constraints on assigned variables must be satisfied however." A complete schedule that breaks one hard rule is not a solution, even against an incomplete one that respects every other rule.
The same paper states its rules for curriculum-based course timetabling directly, not by inference. A hard rule reads, [1] "two lectures cannot take place in the same room in the same period" — no exception, no weight. A soft rule in the same track is scored instead of enforced: a requirement that [1] "the lectures of each course must be spread into the given minimum number of days" adds to a penalty total the solver minimizes, not a rule it must never cross.
The classification decision table
| Question | If yes: class and owner | If no |
|---|---|---|
| Does violating it create a physical or logical impossibility (the same instructor, room, or student in two places at once)? | Hard. No weight tier: hard constraints are never traded off. Owner is whoever maintains the data (the registrar's system of record for rooms, instructors, students). | Continue to the next question |
| Is it set by a law, accreditation standard, or written institutional policy the registrar's office has no authority to waive? | Hard. Owner: the policy office that issues the rule (financial aid, accreditation, counsel); the registrar applies it, not interprets it. | Continue to the next question |
| Can it be waived case by case — by a single named role's own authority, or through a formal exception process that ends in one accountable approver? | Soft. Owner: that role, or the process's accountable approver. Set its weight tier using the table below. | Not yet classifiable: assign an interim owner and log occurrences for a term before setting a weight. |
For every rule that comes out soft, set its weight tier from two factors: what one violation costs, and how often it was waived last term.
| Factor | High weight tier | Medium weight tier | Low weight tier |
|---|---|---|---|
| What does one violation cost, and who bears it? | High cost, borne by students or the institution (e.g., separates a lab section from its paired lecture) | Moderate inconvenience, recoverable within the term | Low cost, easily absorbed by whoever is affected |
| How often was it waived or overridden last term? | Rarely (a handful of cases) | Occasionally, with a clear pattern | Frequently: reconsider whether it belongs in the model at all |
- List every candidate rule
Pull rules from department requests, registrar policy, facilities constraints, and any rule an office has enforced by hand for two terms, even unwritten ones.
- Run each one through the classification table
Apply the three questions in order and record which one resolved it, not just the final class. The reasoning makes the classification defensible later.
- Set a weight tier for every soft constraint
Score cost and waiver frequency from the weight-tier table, and take the higher.
- Review the hard list with department chairs before building anything
Every hard constraint you add can only remove valid schedules, never add one back. An unreviewed hard list can leave you with no feasible schedule.
- Freeze weights before you see the first proposed schedule
Weighting a rule that should have been hard, or vice versa, is a policy error the solver can't catch: it satisfies your instructions and still misses the schedule anyone wanted.
Common scheduling rules, classified (Illustrative example)
| Rule | Class | Why | Typical owner |
|---|---|---|---|
| No instructor teaches two sections at the same time | Hard | Physical impossibility | Registrar |
| Instructor availability: unavailable at certain times (another course, outside contract hours) | Hard | Physical or contractual impossibility if scheduled anyway | Department chair |
| Room capacity not exceeded | Soft, high weight | Facilities can approve an over-enrollment case by case (question 3); hard under question 2 only for a fire-code or safety rule facilities can't waive. ITC 2007's curriculum-based problem, as described in [1], penalizes a shortfall instead of forbidding it. | Facilities |
| A student's two required courses in the same program don't overlap | Hard | Logical impossibility for a student enrolled in both (question 1) | Registrar |
| Accessible seating or room features are available for a student who requires them | Hard | Policy input owned by the institution's disability-services office; not a scheduling preference to trade off | Disability services |
| Credit-load pattern preserves a cohort's financial-aid eligibility | Hard | Set by an office outside scheduling; the solver applies it but doesn't interpret it | Financial aid |
| Back-to-back classes on different campuses allow enough travel time | Hard | Physical impossibility below a minimum gap; facilities supplies the campus travel-time data the registrar applies | Registrar |
| Lab sections are adjacent in time to their paired lecture | Soft, high weight | Strongly preferred, rarely waived | Department chair |
| Instructor's stated time-of-day preference | Soft, medium weight | Waived when department staffing requires it | Department chair |
| Sections spread across the week rather than clustered | Soft, medium weight | Quality preference; waived for small programs with few sections | Registrar |
| Student elective conflicts minimized | Soft, low-to-medium weight | Not achievable for every student at scale; treated as an optimization target using institutional research's conflict data | Registrar |
| Instructor's preferred building | Soft, low weight | Convenience preference, waived often | Department chair |
| New sections avoid the least popular time blocks | Soft, low weight | Enrollment-management preference, not owed to anyone | Registrar |
How do you weight soft constraints without endless debate?
Weighting is where scheduling projects can stall: it looks technical, but it's a policy negotiation between departments, each certain they're right.
- Weighted-sum: every soft violation adds its weight to one running total the solver tries to minimize, so several low-weight violations can outweigh a single high-weight one.
- Lexicographic: satisfy the top-priority tier as fully as possible first, then optimize the next tier only among schedules that are equally good on the tier above.
Use lexicographic ordering when leadership says a tier must never be traded off for any amount of a lower tier; use weighted-sum otherwise.
- Weight by consequence, not by volume. A rule broken rarely but at high cost (separating a lab section from its paired lecture) can outweigh a rule broken often at low cost (an instructor's preferred building), even though the second generates more complaints.
- Set weights before you see the first proposed schedule. Once people see a schedule, it's tempting to adjust weights until it looks better, defeating their purpose. Freeze them, run the solver, and review the output against those frozen weights.
Where two offices genuinely disagree, escalate to academic leadership rather than deciding it yourself, and document who decided, next to the weight.
Who owns each constraint and how waivers are recorded
A classification without an owner goes stale as facts change: equipment, financial-aid rules, and staffing shift. Two habits keep the list current.
- Every constraint, hard or soft, has one named owner who confirms it's still accurate each cycle, not a committee.
- Every waiver of a soft constraint, and every exception to a hard one, is logged with who approved it and why, where the constraint list lives. If a rule is waived every term, revisit its class in the decision table.
- Some tools separate the two: UniTime's course-timetabling solver has an optional "Allow breaking of hard constraints" setting that lets staff [2] "assign a prohibited time or room to a class" by hand from its Suggestions page, while "the solver would still not be allowed" to do so automatically. An override like that is exactly the exception to log.
Mistakes that make a schedule infeasible or unfair
| Mistake | What it causes | Guard |
|---|---|---|
| Too many rules marked hard | No valid schedule satisfies every hard rule. Some solvers return a partial, feasible schedule with sections left unplaced instead of failing outright [1]; others report no feasible schedule exists | Re-run the decision table; anything that isn't physically impossible or externally mandated is a soft-constraint candidate |
| A genuinely hard rule left soft | The solver produces an optimal schedule that still gets rejected, because it silently broke something nobody would trade off | Ask department chairs: is there any weight at which this could be broken? If not, it's hard |
| Weights set to match a schedule people already like | The weighting stops reflecting institutional priority and starts reflecting whoever spoke last | Freeze weights before the first draft schedule is generated |
| No owner named for a constraint | Nobody catches it when the fact changes, and the schedule quietly optimizes against stale data | One named owner per constraint, reviewed each cycle |
| Waivers granted but never logged | What's enforced diverges from what's on paper, and nobody can explain why two similar cases were handled differently | Log every waiver in the same place the constraint list lives |
When a spreadsheet or your current tool is enough
- Your hard-constraint list is short and stable, and one experienced planner already keeps it correct.
- Your student information system already includes a scheduling optimizer you haven't configured yet; classify constraints with the table above, then configure it following the scheduling optimization workflow.
- The classification itself, not the solving, is where your process breaks down: departments disagree constantly about what's negotiable. A decision table makes that disagreement visible faster; it won't resolve it.
Frequently asked questions
What is a hard constraint in timetabling?
A hard constraint is a rule a schedule can never break and still count as valid: it defines feasibility, not quality. Typical examples are physical impossibilities, like one instructor teaching two sections at once, and rules the registrar's office has no authority to waive, such as an accreditation requirement.
What is a soft constraint?
A soft constraint is a rule a schedule can break and still be usable, at a cost the solver is asked to minimize. Preferences and quality goals, like spreading sections across the week or honoring an instructor's building preference, are typical soft constraints: violating one is unpopular or costly, never impossible.
Is instructor preference a hard or soft constraint?
Usually soft. If it can be waived case by case — by a single role's own authority or a formal exception process ending in one named approver — classify it soft and give it a weight tier. Treat it as hard only if the institution genuinely has no discretion to override it, which is rare for a preference.
How are soft constraints weighted?
Set each weight from two factors: the cost of one violation, including who bears it, and how often the rule was actually waived last term. Where the two disagree, use the higher tier. Freeze every weight before the first proposed schedule is generated, then review the output against those frozen weights.
What happens when hard constraints make a schedule infeasible?
Some solvers return a partial, feasible schedule with sections left unplaced instead of reporting failure, because no complete assignment satisfies every hard rule at once; others report that no feasible schedule exists. Either way, it's an over-constrained model, not a solver bug. Re-run the classification and check whether every hard-list rule is truly unavoidable.
Should room capacity ever be soft?
It can be. Under the decision table, room capacity is soft when facilities can approve an over-enrollment case by case, and the ITC 2007 curriculum-based benchmark, as described by one of its winning solvers, penalizes each student over the seat count. Make a posted occupancy limit hard only when it's a fire-code or safety rule facilities can't waive.
Related reading
- For the workflow this feeds into, see academic scheduling optimization, which covers inputs, steps, and acceptance criteria.
- For why manual, one-constraint-at-a-time scheduling breaks down at scale, read academic scheduling optimization at universities.
- If scheduling competes with other priorities for budget, the 360° AI Blueprint ranks it against them.
Sources
- [1] — Tomáš Müller, "ITC2007 Solver Description: A Hybrid Approach" (UniTime), Track 3 curriculum-based course timetabling hard and soft constraints (accessed 2026-09-28)
- [2] — UniTime, "Course Timetabling Solver" (help.unitime.org), "Allow breaking of hard constraints" solver parameter (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.