
For an academic who spent most of his career teaching Shakespeare, Theatre and Performing Arts I find myself strangely drawn to datasets these days.
I have also been an academic registrar and university system transformation lead – so maybe it’s not that strange. When we started building the Student Journey Management System (SJMS) using new coding tools one key challenge to creating an effective system was : how do you model a UK University dataset properly – so it becomes the foundation for everything else – your integration layer, process design, reporting and UI?
That question is what led to the SJMS 2.5 — the Student Journey Management System UK Data Model – an attempt to map the full end-to-end UK student journey as a coherent, regulatory-grounded data model — and then build the system from that model outward.

The numbers matter less than the structure. Every entity sits inside one of 25 bounded contexts — Identity, Curriculum, Admissions, Enrolment & Registration, Assessment & Marks, Progression & Awards, Student Finance, Attendance, Teaching & Timetable, Student Support, EC & Appeals, Disability & Wellbeing, UKVI, Placements, Accommodation, Graduation, Change of Circumstances, Documents, Communications, HESA & Statutory Reporting, Governance, Audit, Calendar, Reference Data — each context owning its own canonical truth and exposing only what other contexts need.
The Data Anchor
A data model is only as credible as the regulators it has to satisfy. SJMS 2.5 is anchored against the actual statutory reality:
- HESA Data Futures — every field that goes into the Student record return is traceable from its operational source.
- OfS — regulatory conditions, B3 metrics, transparency returns.
- UCAS — applicant lifecycle, choices, decisions, confirmation, clearing, adjustment.
- SLC — fee status, tuition fee loans, maintenance, sponsored study, repayments interface.
- UKVI / SMS — CAS issuance, sponsor compliance, ATAS, attendance monitoring, BRP/eVisa.
- QAA — degree classification rules, academic regulations.
Every entity that touches a statutory return is tagged with the return it serves. When HESA changes a definition, you can find every field affected in seconds — not weeks.
The spines
Inside the model, there are four end-to-end spines — the journeys that matter most to the people who actually use a student record system:
- Applicant → Graduate. UCAS application through enrolment, registration, modules, marks, progression decisions, award classification, ceremony, alumni handoff.
- Module-leader workflow. Curriculum approval → cohort allocation → marks entry → moderation → board → publication → appeals window.
- Compliance lifecycle. CAS issuance → enrolment confirmation → attendance monitoring → engagement triggers → UKVI reporting.
- Finance lifecycle. Fee assessment → invoice → SLC interface → tuition payments → sponsorship → write-off / debt management.
Each spine traces cleanly through the bounded contexts. None of them require a god-table. Every step is a real entity with real fields and real regulators backing it.

What the viewer actually does
The interactive map lets you do four things that are hard to do in any other UK HE data artefact I’ve seen:
- Switch between spines and see the same model from different angles — the applicant journey looks different from the module leader’s, but it’s the same underlying graph.
- Search any field, any entity, any relation. Type “HESA” — every entity that feeds the statutory return lights up. Type “CAS” — every entity in the UKVI compliance chain.
- Trace cross-context links. Click Enrolment → see the seven other contexts it touches. This is the conversation that’s normally locked in someone’s head.
- Open the source citations. Every entity carries the standard, regulator, or reference document it derives from. The model is not opinion; it’s evidenced.
Why this matters now
The UK HE sector is mid-transition on three fronts at once:
- Data Futures is settling into steady state, and the cost of misalignment between operational systems and statutory returns is biting institutions that didn’t model the dependency.
- Lifelong Learning Entitlement lands in 2027 and breaks the assumption that a “student” is enrolled on one programme at one provider — modular, transferable, stackable credit forces a richer entity model.
- AI is being grafted onto old forms of SRS that don’t have a coherent data model underneath. Without that foundation, agentic workflows generate confident nonsense.
Try it
🔗 Interactive UK / SJMS 2.5 data model: https://future-horizons-education.github.io/Higher-Education-Data-Model/
If you work in registry, planning, admissions, compliance, finance, student systems, or anywhere the student record touches operational reality — I’d value your feedback. Particularly: where is the model thin, where is it overbuilt, and where are we modelling something that has already moved on?
· Future Horizons Education designs Academic Management Systems grounded in people first, process-second and only then technology thinking. The Global HE Data Atlas is part of our reference work for the sector.
