Student Outcome Intelligence Platform
Case study response

One governed path from student signals to advisor action.

An Azure and Microsoft Fabric reference design that turns fragmented university data into explainable advisor action.

A Norwegian university with 35,000 students across 8 faculties needs to flag risk of non-continuation early enough for advisors to intervene. The signals exist in SIS, LMS, ERP, and campus systems, but they rarely line up — different identifiers, different update rhythms, and current-state tables that quietly erase history. The answer below is a governed Azure data spine, point-in-time features, calibrated risk bands tied to advisor capacity, and an audited advisor queue.

Open presentation Written solution Demo dashboard
Walkthrough

Five steps from raw signals to advisor action

The same five-stage spine the deck uses to navigate Acquire, Govern, Model, Deploy, and Operate.

  1. Acquire
    • SIS, LMS, ERP, campus signals
    • Data Factory + Event Hubs ingestion
    • ADLS Gen2 bronze landing
    Brief & thesis
  2. Govern
    • Canonical student identity
    • Type-2 mutable history
    • Purview lineage + contracts
    Architecture
  3. Model
    • Calibrated risk score
    • Capacity-anchored bands
    • Fairness + validation gates
    Model & math
  4. Deploy
    • Azure ML registry release
    • Power BI advisor queue
    • Row-level security + reason codes
    Action & ethics
  5. Operate
    • Drift + freshness monitors
    • Immutable audit log
    • Roadmap + trade-off review
    Deployment
Chapter 1 · Brief & thesis

The brief is a platform design problem, not a model-only task

Trustworthy history is the hard part. The model only earns the right to score after identity, type-2 status, and point-in-time features are in place.

Industry expectation
Data~20% Model~80%
Production reality
Trustworthy data spine — identity, history, point-in-time features, lineage~80% Model~20%

Build the foundation first

  • Canonical student identity across all systems.
  • Type-2 history for mutable 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, released with the model version.
  • Concrete reason codes — not black-box flags.
  • Fairness monitoring and complete access audit.
If the foundation is wrong, every model retrained on top of it inherits the same blind spots — calibration, fairness, and explainability all collapse on bad history.
Assumptions

Scope the target so the model can be defended

Outcome

Predict non-continuation next term, excluding graduation, exchange completion, and approved leave.

Decision

Advisor prioritization only. No automated punitive, academic, or financial decision.

Cadence

Score in weeks 4, 6, 8, and 10 so support can happen before grades reveal the issue.

Privacy

DPIA, purpose limitation, data minimization, student transparency, and strict access control.

Fairness

Use demographics for auditing and monitoring — not advisor-facing reason codes.

Capacity

Optimize recall and precision at the number of cases advisors can actually work.

Chapter 2 · Architecture

Azure lakehouse plus governed ML workflow

Five-step operating model from acquire through act, anchored on Purview, Azure ML registry, and Power BI with row-level security.

Student Outcome Intelligence Platform reference architecture diagram

Ingest & store

Data Factory and Event Hubs land raw evidence into ADLS Gen2 / Fabric OneLake bronze.

Govern

Purview catalog and lineage, Entra groups, Key Vault, Monitor wired across the spine.

Model & act

Azure ML registry with calibration and Responsible AI review; Power BI advisor queue with RLS.

Chapter 3 · Data model

Bronze, Silver, Gold — one lineage for the entire platform

Raw evidence enters bronze unchanged; silver resolves identity and type-2 history; gold emits point-in-time student-week features ready for scoring.

Bronze · raw

Source landing

SIS, LMS, ERP, and campus signals land as parquet in ADLS Gen2 with original keys, timestamps, and source watermarks preserved.

Silver · conformed

Identity & history

Canonical student_id map, type-2 status and programme history, contracts and quality checks before any feature build.

Gold · features

Student-week features

Point-in-time joins enforced by event_time ≤ t and available_at ≤ t; ready for the model and advisor queue.

Chapter 4 · Model & math

The minimum math needed to defend the design

Four formulas: risk, leakage, capacity, fairness. Each one ties directly to a control in the spine.

Risk

ri,t=P(Yi,t+h=1|Xi,t)

Next-term non-continuation probability for student i at week t.

Leakage

event_time≤t∧available_at≤t

Only historically available records enter features — reproducible from the lake.

Capacity

τred=quantile(r, 1−Cred / N)

Thresholds match advisor capacity per faculty, re-tuned with each model release.

Fairness

gap=max(metricg)−min(metricg)

Audit recall, FPR, calibration, and flag rate across faculty / gender / age bands.

Model & validation

Calibration first, threshold second

Validation gates

  • Time-aware split — train on past terms, validate on the next.
  • Brier score and reliability curve before any threshold is set.
  • Confusion matrix evaluated at τred, not at 0.5.

Release controls

  • Azure ML registry pin — model version, calibration, thresholds bundled.
  • Reason codes generated per prediction, persisted in the queue.
  • Drift and freshness monitors on every weekly score.
Chapter 5 · Action & ethics

Advisor queue with reason codes, fairness audit beside it

A red / amber / green queue scoped to advisor capacity. Demographic groups are audited — never used as features.

Advisor experience

  • Power BI queue grouped by faculty advisor, scoped via row-level security.
  • Each row carries top reason codes and a link back to source evidence.
  • Advisors can dismiss with a reason — logged for the next review cycle.

Fairness audit

  • Recall, FPR, calibration, and flag-rate gaps reviewed per release.
  • Cuts: faculty · gender · age band · international status.
  • Findings feed back into the threshold and feature review.
Risk distribution chart
Risk distribution Open
Fairness flag-rate chart
Fairness flag rates Open
Chapter 6 · Deployment

Trade-offs you can defend, a roadmap you can execute

The platform ships in slices — spine, scoring, queue, audit — with each slice tied to a measurable control.

Trade-offs

  • Weekly batch over real-time — matches advisor cadence and cuts cost.
  • Calibrated logistic / GBM over deep model — better calibration, simpler reason codes.
  • Capacity-anchored thresholds over fixed 0.5 cut — queue fits actual headcount.

Roadmap

  • Q1 — Bronze landing, identity map, type-2 history, Purview lineage.
  • Q2 — Gold features, baseline calibrated model, capacity bands.
  • Q3 — Power BI queue, RLS, reason codes, fairness review.
  • Q4 — Drift monitors, automated retrain, post-mortem cadence.
Deliverables

Open the detailed material only when needed

Written solution Full Azure architecture, assumptions, data model, ML, fairness, audit, roadmap, and trade-offs.
HTML Markdown
Presentation deck 20-30 minute interview walkthrough across the same six chapters.
Slides PDF
Demo dashboard Risk distribution, advisor list, fairness checks, validation, and audit samples.
Dashboard
Case prompt Original brief and extracted text.
PDF Text
Architecture Standalone Azure / Fabric reference diagram.
SVG
Source Demo generator, render script, server file, and package metadata.
Demo Server
Data artifacts

Generated CSVs and source samples

Advisor risk list Feature snapshots Fairness report Validation metrics Data dictionary Access audit SIS sample LMS sample Finance sample Campus sample Status history Identity map