Skip to main content

Documentation Index

Fetch the complete documentation index at: https://cors-lau.vercel.app/docs/llms.txt

Use this file to discover all available pages before exploring further.

After you run an analysis, the Recommendation Engine produces a scored list of every course in your catalog. Each course receives a recommendation status and a set of supporting metrics that explain why the model made its decision. Understanding these fields helps you make informed scheduling choices and identify when to override the model’s suggestion.
The recommendation output is a decision-support tool, not a mandate. You retain full control over which courses to schedule.

Recommendation status

Every course is assigned one of two statuses after an analysis run:
StatusMeaning
RecommendedThe model is confident the course should be offered this semester.
De-prioritizedThe model scored the course below the offering threshold. Consider skipping it unless you have programmatic reasons to offer it.

How status is determined

The method used to assign status depends on whether you ran the analysis in standard mode or quota mode. Standard mode — Courses are marked Recommended if their offer score exceeds the model’s F1.5-score optimized threshold. This threshold balances precision and recall, with a slight bias toward recall to avoid missing high-demand courses. Strict Capacity Quotas mode — The ML threshold is bypassed. Instead, the top N courses per department-and-type slot are marked Recommended, where N is the slot limit you configured before running the analysis. This mode is useful when staffing or room constraints place a firm ceiling on how many courses can be offered.

Output fields explained

Offer score (0–100)

The offer score is the ML model’s probability that a course should be offered, expressed as a percentage. A score of 82 means the model assigns an 82% probability to the course being offered. Higher scores indicate greater model confidence. Use the offer score to rank courses within the same department when you have to choose between similarly-situated options.
An offer score close to the threshold (e.g. 48 when the threshold is 50) means the model is uncertain. Inspect the latent demand and bottleneck score before making a final decision on those borderline courses.

Latent demand

Latent demand is the estimated number of students who are ready and likely to enroll in the course during the upcoming semester. The estimate is derived from prerequisite completion rates and historical enrollment migration patterns.
LevelThreshold
HighMore than 40 students
MediumMore than 15 students
Low15 students or fewer
A course with high latent demand but a low offer score may indicate a course that many students need but that has historically had poor completion rates — worth investigating before deciding.

Bottleneck score

The bottleneck score measures how many downstream courses in the curriculum are blocked if this course is not offered. A course with a high bottleneck score is critical for degree progression: students who cannot take it this semester may be unable to enroll in several subsequent courses.
A high bottleneck score does not guarantee a high offer score. A course can be a structural prerequisite bottleneck but have low current latent demand. Review both fields together before deciding to skip a high-bottleneck course.
Use the Prerequisite Graph alongside bottleneck scores to visualize the full dependency chain and understand exactly which downstream courses are affected.

Projected sections

Projected sections is the recommended number of course sections to open. It is calculated by dividing latent demand by the typical section capacity for that course level, with an adjustment applied for 400-level courses, which typically run with smaller cohorts. Use this as a starting point when planning how many sections to create in the Timetable Scheduler.

Model confidence

Model confidence is the raw probability value output by the ensemble model, on a scale from 0.0 to 1.0. The offer score is this value expressed as a percentage. They represent the same information in different formats.

Is tech elective pool

Courses flagged as part of a technology elective pool are evaluated collectively rather than individually. The model considers the pool as a group and recommends courses within it to collectively satisfy elective requirements. The individual offer scores within a pool are still shown, but ranking within the pool matters more than the absolute threshold.

When to override the model

The recommendation output is a starting point. Override the model when:
  • A De-prioritized course is required to satisfy accreditation or graduation requirements this semester.
  • Faculty availability restricts the set of courses that can actually be staffed, regardless of demand.
  • A Recommended course conflicts with a strategic decision to phase out a program.
  • New curricular changes (course additions, requirement updates) have not yet been reflected in historical data.
Document your overrides so that future analyses can incorporate the outcome data when the next batch of historical offerings is uploaded.

Using the prerequisite graph alongside results

The Prerequisite Graph is a companion view to the recommendation results. After reviewing your results, open the graph and search for any course with a high bottleneck score. The graph shows you every course that depends on it — directly and transitively — so you can gauge the downstream impact of not offering it.

Run your first analysis

Step-by-step walkthrough for generating recommendation results.

Prerequisite graph

Visualize dependency chains and bottleneck courses interactively.