For developers and for the Board

Enterprise Architecture

Every office connected through workflows rather than operating independently — the blueprint developers build from.

Governance

Authority runs down. Data runs through one system.

1
Board of Trustees
Adopts the Statutes. Confers no degrees, admits no students.
2
Chancellor
Head of the university.
3
Vice Chancellor
Leads academic administration. Chairs Senate.

Registrar

Academic records, admissions, enrolment, transcripts, graduation.

Finance Office

All money. No admissions decisions.

Academic Affairs

Programmes, timetable, teaching allocation, quality.

ICT Services

Accounts, availability, audit, integration. Access is not authority.

University Management System

AdmissionsStudent ERPLearning LMSResearch ERP

One record, thirteen stages

The student lifecycle

Every step updates the same student record. Nothing is duplicated. That sentence is the architecture. It also stops being true in most university systems the same way each time: an office finds the master record has no field for something it needs, keeps a spreadsheet, and six months later two systems disagree about who is enrolled. The defence is not discipline — it is that every stage below names the one record it writes to, and there is nowhere else to write.

Prospective student

Admissions Office

Nothing yet — an enquiry, not a record.

Application

Admissions Office

The master record is created. Every later stage writes to this same row.

Payment

Applicant

Payment reference, amount and currency.

Finance verification

Finance Office

Payment status → verified. This is the gate.

Registrar review

Office of the Registrar

Decision, decision reason, and any conditions attached.

Admission

Office of the Registrar

Student number, account, programme, faculty, department, adviser.

Student

Faculty and Department

Enrolment status, tutor group, orientation.

Course registration

Student, checked by the ERP

Registered courses for the semester.

Learning

Lecturer

Attendance, assignment submissions, coursework marks.

Assessment

Examination Office

Grades, once moderated and approved through the chain.

Graduation

Senate, on the Registrar’s audit

Award, classification, graduation date.

Alumnus

Alumni Office

Employment, membership, giving. The same record, with a different view.

Postgraduate recruitment

Admissions Office

A new application against the same person, not a new person.

The Registrar's four outcomes

Including conditional admission

Full admission

Creates account

Admitted with nothing outstanding. The account is created and the welcome email sent.

Conditional admission

Creates account

Admitted, and studying, with named conditions that must be met by a stated date. The account is created; the conditions stay on the record and stay visible to the student, the adviser and the Registrar until each is discharged.

Deferred admission

No account

Admission held over to a later intake. No account is created yet.

Rejected

No account

Not admitted. A reason is always recorded and sent.

Conditional admission is built and live. Conditions are stored against the master record with a due date each, not written into a note — so “students with outstanding conditions” is a query rather than a reading exercise, and the welcome email states the conditions and their deadlines. The status is distinct from Approved for the same reason.

Seven offices

What each controls, and what it may not

Admissions Office

Attracting and processing applicants.

Admissions Officer

Responsibilities

Receive applications
Verify completeness
Communicate with applicants
Forward paid applications to Finance
Produce admission statistics

Dashboard

New applications
Draft applications
Incomplete applications
Applications by country
Applications by faculty
Applications by intake
Conversion rate, application to admission

Cannot

Decide an application
Verify a payment

Finance Department

Money. Not admissions.

Finance Administrator · Finance Director

Responsibilities

Verify application fees
Process tuition payments
Manage invoices
Administer scholarships
Process refunds
Financial reports

Dashboard

Today’s payments
Pending verification
Verified payments
Failed payments
Refund requests
Outstanding fees
Revenue

Cannot

Admit a student
Alter an academic record

Office of the Registrar

Academic records.

Registrar Administrator

Responsibilities

Review academic qualifications
Verify uploaded documents
Approve admissions
Create student records
Manage enrolment
Issue transcripts
Approve graduation

Dashboard

Pending reviews
Approved today
Rejected
Deferred
Conditional admissions
International students
Transfer students

Cannot

Edit a payment
Verify a fee

Faculty Office

The faculty’s students, once they exist.

Faculty Dean

Responsibilities

See new students arriving in the faculty
Approve transfers
Monitor academic progress
Faculty reporting

Dashboard

New students
By department and programme
Advisers assigned
Progress and retention

Cannot

Create a student — the ERP has already done it

Department

Teaching allocation and the student’s first contacts.

Head of Department · Programme Coordinator

Responsibilities

Receive notification of a new student on a programme
Assign an academic adviser
Assign a tutor group
Assign an orientation session
Allocate lecturers to courses

Dashboard

New students awaiting an adviser
Course allocation
Teaching load
Research outputs

Cannot

Admit a student
Publish a result without moderation

Academic Adviser

The student’s academic progress. The first academic contact.

Lecturer

Responsibilities

Advise on course selection
Monitor grades and attendance
Watch graduation progress
Refer to support services

Dashboard

Advisees
Grades
Attendance
Financial holds — read only
Course registration
Graduation progress

Cannot

Alter a fee or clear a financial hold — the adviser sees holds so they can advise around them, and changing one is Finance’s act
Alter a grade

ICT Services

The system itself.

System Administrator

Responsibilities

Accounts and access
Availability and backup
Audit logging
Data protection
Integration between modules

Dashboard

Uptime
Failed logins
Audit volume
Integration failures

Cannot

Make an academic or financial decision. Administrative access is not authority, and every use of it is logged.

Approval chains

Three workflows, declared

Grade approval

A mark becomes a result only after it has passed moderation and three approvals. Every action is timestamped and attributed.

1
LecturerCannot be skipped
Submits marks for the courses they teach. Submitting closes the class to further editing.
Requires: The lecturer is allocated to the course; Marks are saved
2
Head of DepartmentCannot be skipped
Moderates the marks.
Requires: All marks for the course are submitted
3
DeanCannot be skipped
Approves the moderated marks for the faculty.
4
RegistrarCannot be skipped
Approves for publication and writes the result to the academic record.
5
SystemCannot be skipped
Publishes results to students and recalculates GPA.

Writes

Course result · Semester GPA · Cumulative GPA · Audit entry per step

No step may be skipped, including by an administrator. A result published without moderation is a result the university cannot defend on appeal.
A lecturer may not alter a mark after step 1 without the chain being restarted, and the restart is itself recorded. A class is sent back by the office holding it, never recalled by the lecturer — the person prevented from editing cannot lift the prevention.
Four DIFFERENT people are required. One person may perform any one step; nobody may sign the same class twice, whatever offices they hold. This is enforced by the API and again by a database trigger, so it holds for anything using the service-role key.

Graduation

The degree audit is run by the system, not assembled by hand. Three clearances and three approvals stand between completing the credits and being awarded.

1
SystemCannot be skipped
Runs the degree audit: every required course passed, credit total met, residency met.
2
FinanceCannot be skipped
Financial clearance — no outstanding fees.
3
LibraryCannot be skipped
Library clearance — nothing on loan, no fines outstanding.
4
DepartmentCannot be skipped
Departmental approval.
5
FacultyCannot be skipped
Faculty approval.
6
SenateCannot be skipped
Senate approval. The award is conferred here and nowhere else.
7
SystemCannot be skipped
Adds to the graduation list; issues certificate and transcript; converts the portal to the alumni view.

Writes

Award and classification · Graduation date · Certificate record · Transcript record · Alumni record

Classification cannot be computed until the Academic Board adopts the classification bands. Until then the audit can confirm completion but not the class of the award.
The student record is not copied into an alumni record — the same record changes view. That is what keeps a transcript request from an alumnus resolving against the same history the university graded.

Course registration

The student clicks once. The system already knows their faculty, programme, department, level and semester, and checks the rules before accepting.

1
StudentCannot be skipped
Requests registration for the semester.
2
SystemCannot be skipped
Checks programme and level to build the eligible course list.
3
SystemCannot be skipped
Checks prerequisites for each course.
Requires: Prerequisites are recorded against courses
4
SystemCannot be skipped
Checks outstanding fees and any financial hold.
Requires: Finance holds a ledger per student
5
SystemCannot be skipped
Checks the maximum credit load for the level.
6
SystemCannot be skipped
Registers the courses and notifies each lecturer.

Writes

Enrolment rows for the semester · Lecturer class list

Steps 3 and 4 cannot run yet: no course carries prerequisites and Finance holds no per-student ledger. Both are recorded against the modules that must supply them.
Registration is approved automatically when every check passes. An approval queue here would add delay without adding a decision anyone actually makes.

Proposed, with conditions

The AI layer

None of this is built. Each assistant is recorded with the conditions it must meet first, because the distance between “suggests approvals” and an unaccountable admissions decision is one default setting. The general rule for all five: the model may sort, flag and draft; a person decides, and the person must be able to disagree without friction.

AI Admissions Officer

Not built

Reads applications · Flags missing documents · Detects duplicates · Suggests eligibility

Conditions before building

Advisory only. It may sort and flag; it may not decide, and the Registrar must be able to act against every suggestion without friction.
Every flag must show why. A recommendation a human cannot audit is a recommendation a human cannot defend at appeal.
It must be tested for disparate impact by nationality, sex and age before it touches a real application.

AI Finance Officer

Not built

Detects incorrect payments · Predicts revenue · Sends reminders

Conditions before building

Payment verification stays with a person. Detection is the assistant’s job; confirmation is Finance’s.
Reminders must be rate-limited and stop on dispute — automated chasing of a student who has already paid does real harm.

AI Registrar

Not built

Checks prerequisites · Detects incomplete records · Suggests approvals · Flags anomalies

Conditions before building

Prerequisite checking is deterministic and needs no model — it belongs in the registration rules, not the AI layer.
Suggesting an approval is the highest-risk item on this page. It should be built last, if at all, and never as a default the Registrar must override.

AI Academic Adviser

Not built

Warns students at risk · Recommends courses · Monitors GPA · Suggests support services

Conditions before building

A risk flag goes to the human adviser first, not to the student. Being told by software that you are failing is not pastoral care.
Retention models encode past bias readily. If a cohort was underserved historically, the model learns to predict that they will fail again.

AI Research Assistant

Not built

Literature search · Citation formatting · Research planning · Proposal review

Conditions before building

The university has no published position on generative AI in assessed work. That policy has to exist before the university offers students a tool to do it with.
Citation formatting and literature search are low-risk and could ship first.

The rest of the blueprint

ERP modules Institutional documents Admissions Portal Academic Regulations