Course selection & degree-planning recommendations (academic advising)

Students pick courses from a catalogue of hundreds of modules under rules few of them fully understand, and advisors cannot see everyone who drifts off track. A hybrid system combines a deterministic rules engine (what is allowed and required) with ranking models (what fits this student) and an LLM explanation layer, producing a feasible plan and a prioritised advisor worklist. Documented results at US universities show faster graduation, but only when paired with more advisor capacity.

Problem & value

• Today: students use PDF regulations, a static degree audit and a drop-in appointment. Errors surface late: a missed prerequisite, a course not offered next term, credits that do not count. At the school-to-university transition (Studienorientierung), applicants choose from a very large programme landscape with little personalised guidance.
• AI value: constraint-aware plans, personalised elective ranking, early alerts, and advisor time shifted from rule lookup to conversation.
• Evidence (self-reported, not independently evaluated): Georgia State University built its GPS Advising system with EAB on ten years of course grades (about 2.5 million), with over 700 risk flags, and at the same time hired 42 advisors, reducing caseloads from roughly 700 to 300 students. The university reports students saved about 12 million USD in tuition by graduating faster [1]. The staffing change is a confounder: treat the tool as an amplifier of advisors, not a substitute.

Variants

• Degree planning inside a university: multi-semester plan, what-if for major change.
• Course registration support: ranked electives at enrolment, with seat and timetable constraints.
• Study orientation (school to university): interest and aptitude self-assessment leading to a programme shortlist; advisory only, never admission-relevant.
• Early-alert advising: advisor dashboard of off-track students (overlaps EDU-007, but here the output is a recommended path, not only a risk score).
• Community college / vocational: transfer-pathway planning, combined with EDU-014.

How it works

SIS / LMS / timetable data (pseudonymised features)
  -> degree-rule model (prerequisites, credit buckets, exam regulations as code/graph)
  -> candidate generation (all rule-feasible courses and plans)
  -> optimisation (CP-SAT/MIP: no timetable clashes, capacity, workload, on-time graduation)
  -> ranking (interest, outcome-based fit, difficulty-for-this-profile) + explanation (LLM)
  -> student view (suggestions + "why") and advisor view (off-track list)
  -> advisor confirms; student decides; feedback logged

• Rules first: feasibility is decided by an explicit rules engine or knowledge graph, never by an LLM. LLMs only parse regulation documents into rules (reviewed by staff) and phrase explanations.
• Ranking: collaborative filtering and gradient boosted models on course-taking and grade histories; course embeddings from descriptions help cold start for new modules.
• Outcome modelling: predicted grade or completion likelihood per course, used cautiously and checked for bias across groups; uplift/causal methods are preferable to raw correlation.
• Human in the loop: advisor reviews alerts and non-standard plans; students always choose.

Data preparation

Needed: student records (transcripts, grades, enrolment) from the SIS or campus management system (HISinOne, CAMPUSonline), the examination regulations (Studien- und Prüfungsordnung) as PDF or Word on department file shares, the module catalogue, timetables and seat capacities, and pseudonymised cohort histories. Data owners are usually the registrar, the examination office and the faculties.

Typical gaps: regulations exist only as prose and differ per programme and version; module descriptions are outdated or inconsistent; credit recognition is handled in spreadsheets; grade histories span several regulation versions; legacy SIS exports are hard to obtain; access rights to student data are coarse.

Steps: (1) inventory sources and owners with a data-readiness check (PREP-001, PREP-004, GUIDE-003); (2) extract SIS data via API or read-only data mart (PREP-005); (3) turn regulations into machine-checkable rules, with LLM-assisted parsing and review by the examination office; (4) harmonise module catalogue and terminology (PREP-012, PREP-015); (5) collect advisor-approved plans as gold-standard test set (PREP-016, PREP-018); (6) pseudonymise training data (PREP-022).

Effort: data and rule preparation is the largest block, roughly 50-60 percent of the project; model work is small by comparison.

Implementation paths

Which path for whom

• Enterprise (large universities, private education groups): B, because the value sits in encoding local examination regulations and integrating with the own SIS, which no standard product covers fully.
• Public (state universities, public bodies): C, because student records are sensitive, procurement favours sovereign operation, and the stack (rules engine, CP-SAT, open-weight LLM) runs on HW2.
• Developer (edtech vendors, campus IT teams): C, because open-source recommenders and solvers give full control and no per-student licence cost.

Path A - Buy (off-the-shelf)

• Advising and student-success platforms: EAB Navigate360 (US-centric; GPS-style alerts, used by Georgia State), Stellic (degree planning and audit), Ellucian (Degree Works and Journey), Civitas Learning, Anthology and Salesforce Education Cloud. These are mostly US products; check EU hosting, DPA and fit with local credit systems (ECTS, Prüfungsordnung).
• EU/DACH campus management: HISinOne (HIS eG), CAMPUSonline (TU Graz), Campusnet, with study planners and degree-audit modules; AI features vary and are often add-ons.
• Choose A when: you want proven alert workflows and have a standard rule structure.

Path B - Build on cloud APIs

• LLM for regulation parsing and explanation: Mistral (EU), Azure OpenAI in EU regions, Claude or Gemini via EU endpoints. Use structured outputs for rule extraction and a retrieval layer over the regulations.
• Embeddings and search: managed vector search in EU regions. Optimisation with Google OR-Tools CP-SAT [3] running in your own environment.
• Integrate with the SIS via its API or a read-only data mart.

Path C - Self-host (open source)

• Rules as a graph (Neo4j Community, or a typed rules library); OR-Tools CP-SAT for scheduling; LightFM, implicit or RecBole for recommenders; LightGBM for outcome models.
• Open-weight LLMs (Mistral, Qwen, Llama families, served with vLLM) for explanation and regulation parsing. HW2 suffices for a 7-30B quantised model; student data stays on campus.

Path D - Custom training

Worthwhile for large systems with years of enrolment logs: train sequence models of course-taking or fine-tune an embedding model on local catalogue text. Needs several cohorts of pseudonymised records; fairness evaluation across gender, migration background and first-generation status is mandatory before use.

State of the art (2026)

• Neuro-symbolic hybrid is the working pattern: symbolic constraint satisfaction guarantees validity; ML ranks; LLMs explain. Pure LLM planning produces plausible but invalid plans (missed prerequisites, non-existent courses).
• Conversational advising agents answer questions against the regulations with citations; they are good at lookup, weaker at judgement on exceptions.
• Predictive analytics is mature in the US; European adoption is slower because of data protection and the fragmentation of regulations per programme.
• Limits: historical data encodes past inequities (steering certain groups away from demanding majors); small cohorts per module give noisy outcome estimates; regulations change yearly; student goals are often unstated or unstable. Nudges can reduce choice diversity.

Shared resources & combinations

• Same recommender stack as REC-001, REC-002 and REC-008 (embeddings, ranking, feedback logging).
• EDU-007 supplies dropout risk features; EDU-005 sequences content inside a course, while this use case works at curriculum level; EDU-014 supplies recognised credits; EDU-015 is the admission-side counterpart and carries stricter obligations.
• REC-004 segmentation methods are reusable for advisor caseload grouping.
• LLM and vector infrastructure is shared with an internal student-services chatbot.

Effort, cost & KPIs

• Path A: 3-9 months incl. SIS integration and rule configuration; licence cost typically scales with student numbers.
• Path B/C: 4-9 months; the main cost is encoding degree regulations, not model work.
• KPIs: time-to-degree, credits earned per term, share of students with valid plan, prerequisite-error rate, advisor caseload and contact rate, alert-to-contact time, retention by group (check gaps), student satisfaction, share of recommendations accepted.

People & change

Involve management (budget, purpose, AI policy) and the vice-rectorate for studies first; the examination office and faculties are process owners and must own the rule encoding. Data owners (registrar, IT) and IT security join at the architecture stage; the data protection officer from day one, because a DPIA (Art. 35 GDPR) is needed for systematic evaluation of students, plus an AVV (Art. 28) with any vendor. Students are the affected group: involve student representatives early.

Works council: depends. Students are not employees, so BetrVG does not cover them, but advisors work with the dashboard and their usage is logged, so where a works council exists (private providers) §87(1) no. 6 BetrVG applies, and in public universities the staff council (Personalrat, BPersVG or state law) has comparable rights. Under §90(1) no. 3 BetrVG the works council must be informed when work processes are planned with AI. Bring it in before the pilot and agree on a works or service agreement that excludes performance control of advisors.

Support AI literacy of advisors and staff (Art. 4 AI Act, GUIDE-006): what rules engine, ranking and LLM explanation do, and where they fail. Communicate that the tool advises and advisor and student decide; show the reason for each suggestion and allow opting out. Pilot with one programme and a few motivated advisors as champions, and address concerns (steering, "predicted failure" labels, job fears) openly, see GUIDE-008 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: classification depends. Annex III point 3 lists education systems that determine access or admission, evaluate learning outcomes, assess the appropriate level of education a person will receive, or monitor prohibited behaviour in tests [2]. A pure elective suggester is usually not listed; a system that steers or limits access to programmes, or assigns a student to a level or track, can fall under high-risk (conformity, risk management, human oversight, logging). Documents should state the intended purpose carefully. Emotion inference from students is prohibited in education (Art. 5(1)(f)) and must not be part of engagement scoring.
• GDPR: student records are personal data; legal basis normally the university's public task (Art. 6(1)(e)) plus state higher-education law; profiling of minors at the orientation stage needs extra care. Run a DPIA, ensure transparency, and avoid automated decisions with legal effect (Art. 22); recommendations must stay advisory.
• Bias and autonomy: audit outcomes by group; show reasons; allow ignoring or opting out; never present "predicted success" as a barrier to a chosen programme.
• Data minimisation: no social-media or biometric data; pseudonymise training data.

Getting started

1. Pick one programme and encode its examination regulations as machine-checkable rules; validate against 50 real, advisor-approved plans.
2. Build a degree-audit and plan-feasibility service before adding any ranking.
3. Add recommendations in shadow mode for advisors and compare with their suggestions.
4. Run DPIA and AI Act classification with the data protection officer and student representatives.
5. Pilot with one cohort; measure time-to-degree and equity gaps against a control group.

Sources

1. NPR - How one university used big data to boost graduation rates (Georgia State GPS) - https://www.npr.org/sections/ed/2016/10/30/499200614/how-one-university-used-big-data-to-boost-graduation-rates
2. Regulation (EU) 2024/1689 (AI Act), Annex III and Art. 5 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
3. Google OR-Tools CP-SAT solver documentation - https://developers.google.com/optimization/cp
4. EAB Navigate360 - https://eab.com/solutions/navigate360/
5. Stellic - https://www.stellic.com/
6. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj