At a glance
- The checklist below covers eight inputs, each with a system of record, an owner, a validation check, and a common error.
- Check the data before you evaluate a solver: a checklist and a short dry run on last term's data catch problems before go-live.
- Validation checks map to plain data-quality dimensions — completeness, uniqueness, consistency, timeliness, validity, and accuracy — so a non-specialist can run them.
- A cross-listed section is worth checking by hand: a discrepancy can appear even when each department's own record is correct but the two halves were never compared.
- When the checks fail broadly, fix the data before configuring anything, and re-test on one college or term before scaling up.
Why data, not the solver, sets the pace
A course-scheduling optimizer is only as good as what it's told. It can't know a room seats fewer students than the space-management system records, and it can't respect an instructor's contract hours if that availability lives in an email thread instead of a system. If source data is wrong, stale, or missing, the schedule will be wrong the same way.
Treat a data-quality report as the first deliverable, not the schedule itself: what's missing, what contradicts itself across systems, and what nobody currently owns. That's different from what a solver needs, covered in the academic scheduling optimization overview; this is how a registrar's office checks whether the data it already has is ready to use before a project starts.
The readiness checklist
Work through each row before a scheduling project begins. The two tables below cover the same eight inputs — the first names the system of record and who's responsible for each, the second states the check and the bar to clear; mark each row ready or fix-first as you complete the check.
| Input | System of record | Owner |
|---|---|---|
| Course catalog (descriptions, prerequisites, corequisites) | Catalog or curriculum management system | Registrar's curriculum office |
| Sections and meeting patterns | Student information system (SIS) | Registrar's scheduling team |
| Instructor assignments and availability | Department records, plus the SIS for assignments | Department chair |
| Rooms, capacity, and features | Facilities or space management system | Facilities office |
| Enrollment history or demand forecast | SIS enrollment records, institutional research | Institutional research |
| Program and degree requirements | Degree audit or curriculum system | Academic affairs or program directors |
| Cross-listings | SIS, cross-referenced against the catalog | Registrar's scheduling team, with both listing departments |
| Scheduling policy (hard rules, exceptions) | Registrar policy documentation | Registrar's office |
The same inputs, checked against your systems:
| Input | Validation check | Common error | Status |
|---|---|---|---|
| Course catalog (descriptions, prerequisites, corequisites) | Every active course has a current description and machine-readable prerequisites (not free text) | A prerequisite footnote number no longer maps to any current course | — |
| Sections and meeting patterns | Every section has a meeting pattern in a standard days, times and location format | A section with no meeting pattern, or one recorded as a note in a comments field | — |
| Instructor assignments and availability | Every assigned section has a named instructor, each assigned section falls within that instructor's stated availability, and no two of an instructor's assignments overlap, other than sections of the same cross-listing | A section is assigned before anyone confirms the instructor is available that term | — |
| Rooms, capacity, and features | Capacity, features (lab, accessible, AV), and room identifier all match between the SIS and the facilities system | The room code in the SIS doesn't match the facilities system's code for the same space | — |
| Enrollment history or demand forecast | Section-level enrollment for at least the last comparable term is available and tied to the right section | Demand estimated from department requests rather than actual prior enrollment | — |
| Program and degree requirements | Required course sequences for each active program are current and don't reference retired courses | A program's sequence still requires a course under a number that no longer exists | — |
| Cross-listings | Every cross-listed section shares one meeting pattern and room across all its subject codes; confirm your own policy on instructor | Two subject codes for the same class recorded with different meeting patterns | — |
| Scheduling policy (hard rules, exceptions) | Every rule staff enforce by hand appears in policy documentation with an owner | A written rule exists but was never updated after the policy behind it changed | — |
Validation checks you can run this week
Each check above maps to a data-quality dimension used well beyond higher education. The UK Government's own Data Quality Framework, developed with DAMA UK, defines six of them in plain terms [1], each giving a non-technical reviewer a concrete test to run against last term's data.
| Dimension | Definition [1] | Scheduling check |
|---|---|---|
| Completeness | "Completeness describes the degree to which records are present." | Every section has a meeting pattern, an instructor, and a room; nothing is blank. |
| Uniqueness | "Uniqueness describes the degree to which there is no duplication in records." | No section, room, or instructor record is entered twice. |
| Consistency | "Consistency describes the degree to which values in a data set do not contradict other values representing the same entity." | Room capacity in the SIS matches the facilities system's own figure for the same room, and no instructor or room is booked to two sections at once, other than sections of the same cross-listing. |
| Timeliness | "Timeliness describes the degree to which the data is an accurate reflection of the period that they represent, and that the data and its values are up to date." | Instructor availability and room features reflect this term, not one carried over from a prior year. |
| Validity | "Validity describes the degree to which the data is in the range and format expected." | Meeting patterns use a standard days/times/location format the solver can parse, not free text. |
| Accuracy | "Accuracy describes the degree to which data matches reality." | A room's recorded capacity and features match what's physically in that room today. |
Cross-listings are worth a manual pass beyond the six checks above: a record can be complete, unique, and correctly formatted in each system, and still be wrong because two departments' records disagree. Duke University's registrar data dictionary states that [2] "Cross-listed classes are offered under different subject codes on the Schedule of Classes but share the same content matter."
The same source adds that [2] "all sections of a cross-listed course meet in the same classroom during the same meeting pattern, as the class content is uniform." That's Duke's own practice, not a universal rule: pull every subject code sharing a cross-listing, confirm meeting pattern and room match, and check your own registrar's policy on instructor.
Who owns each input
The checklist above names one owner per row, and that's deliberate: a shared owner is no owner. Each office already keeps its own piece of this data, so the readiness work is mostly about getting each office to confirm its piece is current before the project starts.
- The registrar's office owns the checklist itself: convening other owners and deciding when the data is clean enough to start.
- Facilities and department chairs own two inputs that drift without anyone else noticing — room data and instructor availability.
- Cross-listings need two owners to agree, since a discrepancy can happen even when each department's own half is entered correctly and never compared with the other.
- Institutional research is a natural owner for enrollment history where it already reconciles SIS enrollment figures for other reporting.
Running a data dry run on last term
Before committing to a scheduling project, run the checklist against last term's actual schedule — a closed, known dataset, so failures point at the data process, not anything new about the coming term.
- Export last term's data from every system of record
Pull the course catalog, sections and meeting patterns, instructor assignments, room list, enrollment, program requirements, cross-listings, and policy documentation from the systems named in the checklist's "system of record" column.
- Run the six validation checks against the export
Check completeness, uniqueness, consistency, timeliness, validity, and accuracy, and count how many records fail each one.
- Check cross-listings by hand
Pull every cross-listed section and confirm meeting pattern and room agree across every subject code, then check your own policy on instructor.
- Sort failures into fix-first and solver-flagged
A missing meeting pattern, or a room or instructor booked to two sections at once (other than sections of the same cross-listing), blocks any usable schedule and is fix-first. A stale instructor preference the solver can simply deprioritize isn't.
- Assign each fix-first item to the row's named owner
Send each failure to the office that owns that input, with the specific record, not a general request to "clean the data."
- Re-run the checks once fixes land
Confirm the fix-first items clear before treating the data as ready.
What to do when the data isn't ready
Expect some rows to fail on a first run — better to find out from a dry run than partway through configuring a solver:
- Fix the highest-failure-rate rows first. A handful of exceptions is manageable manually; a row where most records fail needs a process fix, not a one-time cleanup.
- Narrow scope before narrowing the timeline: running the dry run on one college surfaces the same gaps on a dataset small enough to fix quickly.
- Give every fix-first item a named owner and a recheck date, using the checklist's owner column.
- Where an input has no current owner (cross-listing agreement or policy, for example) resolve ownership first, or the gap reappears next term.
When this doesn't apply
- Your term schedule is small and stable enough that one experienced scheduler already catches these errors by hand.
- You're not yet planning to run an optimizer. The checklist is still useful as a data-quality exercise, but the dry run is built for readiness ahead of a scheduling project specifically.
- Ownership of these inputs is itself unresolved. Settle who owns cross-listing agreement and policy first, or the dry run will surface an ownership gap instead of data errors.
Frequently asked questions
What data do you need before running a course schedule optimizer?
Eight inputs: the course catalog, sections and meeting patterns, instructor assignments and availability, rooms with capacity and features, enrollment history or a demand forecast, program and degree requirements, cross-listings, and written scheduling policy. Each needs a named system of record and owner before a solver can use it reliably.
Where does room capacity data come from?
Check the facilities or space-management system, which may be a separate system from the student information system that holds sections and enrollment capacity. Two checks matter: a section's enrollment capacity shouldn't exceed its assigned room's physical capacity, and the SIS and the facilities system should record the same capacity for that room.
How do you clean instructor availability data?
Move it out of email and into a system every reviewer can check. Then confirm each assigned section falls within the instructor's stated availability, and that no two of an instructor's assignments overlap, other than sections of the same cross-listing. Look for availability only ever communicated informally, never recorded anywhere a solver, or a person, can read it.
How long does data preparation take?
It depends on how many systems the data lives in and how many checks fail in the dry run, so there's no single figure to promise. Running the dry run first tells you the real scope: a handful of failing rows is a different job than several systems that disagree with each other.
What are the most common scheduling data errors?
Errors worth checking first include meeting patterns saved as free text instead of a structured format, a section with no name in the instructor-of-record field, a room code that doesn't match between the SIS and the facilities system, and cross-listed sections whose subject codes disagree on meeting pattern or room.
Can you import straight from the SIS?
Not without checking first. A student information system export can be complete (every section is there) while still failing consistency (room capacity disagrees with the facilities system), validity (meeting patterns as free text), or accuracy (a room's features don't match reality). Run the six checks before treating it as ready.
How do you validate cross-listed sections?
Pull every subject code sharing a cross-listing and confirm they agree on meeting pattern and room. At Duke, all sections of a cross-listed course meet in the same classroom during the same meeting pattern; check your own registrar's policy, including whether instructor should match.
Related reading
- For what the solver does with this data once it's ready, see academic scheduling optimization, which covers the workflow, constraints, and where a solver fits.
- For why manual, spreadsheet-based scheduling breaks down as an institution grows, read academic scheduling optimization at universities.
- If data readiness competes with other priorities for budget or attention, the 360° AI Blueprint ranks it against them.
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.