Why academic operations are hard to run today
1. Demand never reaches the people building the schedule
Degree audits, waitlists, and admits live apart from the schedule.
2. Full here, half empty there
Sections fill unevenly, so waitlists and empty seats sit side by side.
Students wait a term, and instructional cost goes to empty seats
3. Bottlenecks are predictable months out
Prerequisite chains and degree plans show them a term ahead.
2 · The ontology we build
The academic operations model
We bring your systems, outside data, and policies together, model the domain, and compute what it runs on.
A slice of the full model: the labeled objects are the ones this work runs on most.
Program
A degree program and the requirements it defines.
- degree
- enum
- catalog_year
- integer
- Æ’longest_chain
max(prerequisite chain length across required courses)
- definesRequirementmany
- is pursued byStudentmany
Requirement
A rule the degree must satisfy: a course, a set of choices, or a credit total.
- kind
- enum
- credits_required
- decimal
- is defined byProgramone
- is satisfied byCoursemany
- is still needed byStudentmany
Course
A catalog course, the sections it runs as, and the courses it unlocks.
- credits
- decimal
- level
- integer
- next_term_demand
- Seats needed next term, from what each student still needs and how students progress. From student, requirement, section, and admits and waitlists.
- Æ’unmet_demand
next_term_demand − sum(sections.capacity)- ƒbottleneck_score
unmet_demand × count(courses it unlocks)
- satisfiesRequirementmany
- prerequisite forCoursemany
- is owned byDepartmentone
- offered asSectionmany
Department
An academic department: its courses, its faculty, and its teaching budget.
- college
- string
- teaching_budget
- money
- Æ’load_gap
sections_needed(courses) − sum(instructors.load_target)
- ownsCoursemany
- employsInstructormany
Student
A student whose remaining requirements drive next term's demand.
- credits_earned
- decimal
- expected_grad_term
- term
- pursuesProgramone
- still needsRequirementmany
Section
One offering of a course in a term, with a room, a time, and a capacity.
- capacity
- integer
- enrolled
- integer
- census_fill
- Enrollment expected at census, from registration pace and past terms. From term.
- Æ’safe_to_merge
census_fill < 0.5 × capacity and no enrolled student needs it to progress this term
- offersCourseone
- is taught byInstructorone
- scheduled inTermone
- meets inRoomone
Instructor
A faculty member or lecturer with a teaching load target.
- rank
- enum
- load_target
- decimal
- Æ’assigned_load
sum(sections.credits)
- teachesSectionmany
- belongs toDepartmentone
Term
An academic term and its registration calendar.
- starts_on
- date
- census_date
- date
- schedulesSectionmany
Room
A teaching space, its seats, and what it can support.
- seats
- integer
- building
- string
- features
- enum
- hostsSectionmany
What it enables
3 · What we deploy on top
Applications, agents, and workflows on the model
Each one reads the model and changes it only through governed actions.
Academic Operations HQ
For the provost’s office, deans, and chairs: next term’s demand against seats, bottlenecks, sections at risk, and teaching load by department.
Add section: Dean approves, registrar publishes
Scheduling agent
Drafts schedule changes: sections added where demand exceeds seats, and merges for sections that will not fill.
Chairs and deans approve every change
Schedule changes
Carries each approved change through: rooms, instructors, and notices to the students affected.
Merge sections: Dean approves; enrolled students are notified
4 · Outcomes
What the academic operations model lets you do
1. Add sections where demand exceeds seats
Proposals go out with room, instructor, and cost
RegistrarWhat the model sees
Next term’s demand from every student’s degree progress
2. Unblock bottleneck courses
Fixes land before registration opens
Registrar and deansWhat the model sees
Critical courses students cannot get into
3. Consolidate under-filled sections
Sections merge and faculty time is redeployed
Department chairsWhat the model sees
Sections that won’t fill, with no progression risk
4. Rebalance teaching load
Assignments shift within workload rules
DeansWhat the model sees
Teaching capacity against demand, by department
5. Fix prerequisite chains that delay graduation
Schedule or catalog changes are proposed
Curriculum committeeWhat the model sees
Sequences that add terms for students
Projected value when a change goes live, and realized value against a holdout, a matched group, or the prior cycle, reported separately.
Seats short in required courses, found before registration
Seat utilization at the same instructional cost
Schedule changes approved and posted
Start with Academic Operations
We scope the first domain with your team and agree on the outcomes to measure.
