Outcomes Intelligence in Higher Education: A Student-Journey Ontology

Ask a registrar, a financial aid officer, and an academic advisor to each describe "an at-risk student" and you'll get three different, mutually inconsistent answers — not because any of them is wrong, but because each is looking at a different slice of the same person through a system that was never designed to talk to the other two. The registrar sees attendance and course withdrawal patterns. Financial aid sees payment status and award renewal risk. Advising sees grades and advising-session history. None of these views is false. None of them, alone, is the student.

The usual response to this is a new dashboard that pulls a metric from each system into one screen. This helps, briefly, and then stops helping, because a dashboard that shows three systems' outputs side by side hasn't actually resolved the underlying problem: the three systems still don't share a definition of what a "student" or an "intervention" or an "outcome" is, so the moment you want to ask a cross-cutting question — "which students who received a specific advising intervention in week 4 subsequently had improved attendance" — the dashboard can't answer it, because that question requires a shared model, not a shared screen.

What a student-journey ontology actually is

A small, deliberately explicit data model that defines the entities and relationships every downstream system agrees to use, even if their internal schemas differ:

• Student — one canonical identity, resolved across every source system, with a defined process for what happens when systems disagree (a name change processed in the registrar but not yet in financial aid, for instance).
• Milestone — a defined set of events that constitute progress or risk: course completion, GPA threshold crossings, financial-aid status changes, advising touchpoints — each with a timestamp and a source system, so "when did this happen" is never ambiguous.
• Intervention — anything done in response to a signal: an outreach email, an advising appointment, a financial aid adjustment — logged with enough structure to later ask "did this work," which almost no institution's current systems can answer with confidence, because interventions are recorded as case notes, not structured events with defined outcomes to check against.
• Signal — the model's or rule's output that triggered a review (a risk score crossing a threshold, an unusual attendance pattern) kept distinct from the milestone it was predicting, so you can evaluate the signal's accuracy against what actually happened afterward.

Why this is worth building before the predictive model, not after

The common failure pattern: an institution builds a churn/attrition prediction model first, gets a risk score per student, and only then discovers that acting on the score is hard, because the systems that would need to receive an alert and log a response don't share a data model with the system that produced the score. The model becomes a number nobody can act on cleanly, or worse, an action gets taken but never gets logged in a form that lets anyone check later whether it worked.

Building the ontology first reverses this. It's less exciting than a predictive model and it's the piece that makes the predictive model usable rather than decorative — because once milestones, interventions, and signals share a structure, you can ask the question that actually matters for improving student outcomes over time: not "can we predict risk" (usually yes, reasonably well, from attendance and engagement data alone) but "which interventions, for which risk profiles, actually change the outcome" — which is a causal question about intervention effectiveness, answerable only once interventions are logged as structured, comparable events rather than free-text notes scattered across three systems that were never meant to be read together.