Selected work  /  KU-RISE Scheduling

Academic systems · Constraints · Validation    Synthetic demonstration

Making a timetable work

Turning academic constraints into a testable scheduling component.

Many constraints. One coherent week.

A timetable must coordinate courses, cohorts, faculty, rooms and campuses at the same time.

The problem

A schedule can appear complete while containing clashes, unsuitable rooms or impossible travel between consecutive classes. KU-RISE narrows a broader ERP ambition to this specific problem. It combines an academic data model, spreadsheet ingestion, preflight diagnostics, constraint-based scheduling and independent validation. Separating time-slot allocation from room assignment reduces the size of the scheduling problem.

My contribution

The institutional problem framing, requirements and technical component developed with AI assistance — together with an explicit account of its demonstration limits.

Deliverables

  • Python scheduling engine
  • Academic data model and Excel loader
  • Preflight diagnostics
  • Independent timetable validation
  • Demonstration workbook and integration roadmap

Process

Define constraintsNormalise inputs Generate scheduleValidate independently

Decisions that shaped it

Scope a usable component.

Focus on the scheduling engine and academic model within a wider integration plan. Keep its boundaries and input requirements explicit.

Diagnose inputs before solving.

Check missing data and capacity constraints before attempting a schedule. Explain why an input set cannot produce a usable result.

Validate independently.

Check the completed timetable separately from the solver. Test conflicts and practical constraints rather than assuming a generated result is correct.

Outcome

The supplied project documentation records a synthetic demonstration placing 381 weekly sessions with zero conflicts. This is a component-level demonstration result using KU-shaped sample data.

Takeaway

The ability to reduce a large transformation brief to a concrete problem, explain trade-offs, and distinguish demonstrated performance from operational impact.

Honest limits

The demonstration is not evidence of institutional adoption, measured time savings or a complete ERP. Real operational data, integration and a controlled institutional pilot remain future work.

What would come next

  • Validate the academic model with institutional users
  • Integrate authorised source data
  • Evaluate schedules in a controlled pilot

← All selected work