Student Outcome Intelligence Platform

University context

• 35,000 students across 8 faculties.
• Different programmes, study modes, and engagement patterns.
• Advisors need early signals before official records show risk.

Data and governance challenge

• SIS, LMS, ERP, and campus systems do not share identifiers or update rhythms.
• Student status changes over time, so current-state tables create bad history.
• The platform must be accurate, explainable, fair, auditable, and durable after launch.

Build the foundation first

• Canonical student identity across all systems.
• Type-2 history for mutable student status and programme data.
• Data quality contracts, Purview lineage, and schema-drift detection.
• Point-in-time features that only use data known at scoring time.

Then make risk useful

• Weekly scoring during the semester.
• Risk bands selected by advisor capacity and released with the Azure ML model version.
• Concrete reason codes, not black-box flags.
• Fairness monitoring and complete access audit.

Feature rule

Why it matters

• Late-arriving records cannot sneak into historical training.
• Future withdrawals cannot leak through current SIS status.
• Programme changes are joined as they were known then.
• Predictions can be reproduced for a student or regulator.

Baseline model

• Calibrated logistic regression or explainable gradient boosted trees.
• Train on historical term snapshots from the same weeks used in production.
• Exclude protected attributes from default model inputs.
• Version model, features, thresholds, and training data in the Azure ML release package.

Evaluation

• Recall and precision at advisor capacity.
• Calibration by risk band and by faculty.
• Responsible AI cohort review before each release.
• Lead time before official dropout signal.
• Stability and drift across terms.

Design choices

• Compare engagement within programme, study mode, and term week.
• Do not treat low campus presence as uniformly risky.
• Keep sensitive attributes out of reason codes.
• Review advisor feedback for bias, not just model scores.

Monitoring

• Flag rate, recall, false-positive rate, and calibration by group.
• Reason-code distribution by group.
• Intervention offer and acceptance rates.
• Term-by-term drift in population and outcomes.

Data foundation

• Four independent systems: source-specific contracts through Data Factory/Fabric and Event Hubs.
• Inconsistent identifiers: canonical identity map with match confidence.
• Changing student status: type-2 history and effective-dated joins.
• Schema changes: quarantine, contract tests, profiling, and promotion gates.

Decision safety

• Early warning: weekly in-semester scoring before official dropout records.
• No leakage: event_time and available_at must both be before scoring date.
• Fairness: calibration, FPR, recall, flag-rate, and reason-code checks by group.
• Auditability: explanation, model version, threshold policy, and access log.

Start daily batch with event capture

Advisor intervention does not require millisecond latency. Data Factory batch plus Event Hubs capture preserves detail without overpromising real-time action.

Store raw and expose aggregates

Raw data supports audit and backfill, while aggregated features reduce privacy exposure in the advisor workflow.

Prefer explainability over small accuracy gains

An unsupported black-box score is less valuable than a slightly weaker model advisors and regulators can understand.

Use protected attributes for audit

You cannot prove fairness while refusing to measure outcomes across groups.

Run locally

Generated files

• source_samples/*.csv
• feature_student_week_and_predictions.csv
• advisor_risk_list.csv
• fairness_report.csv
• access_audit_sample.csv
• risk_distribution.png