Programme Enrolment Lifecycle

Epic summary

The Programme Enrolment Lifecycle workspace manages a student’s official relationship with an institute programme after enrolment has been created.

It is used when that relationship must change because the student:

takes an approved long break;
returns from an approved break;
withdraws from the programme;
is discontinued by the institute;
migrates to another institute where the applicable regulation permits it; or
completes every requirement of the programme.

The workspace does not provide a button that directly edits the enrolment status. Every change is handled as a request with a reason, evidence, checks, approval, effective date, reporting requirements, and permanent history.

Create request
  -> Check the applicable rules
  -> Review evidence and impact
  -> Obtain the required approval
  -> Make the decision effective
  -> Complete required reporting

Lifecycle and academic progression are different

The programme-enrolment state answers:

Is this student still officially enrolled in this programme, and in what capacity?

Academic progression answers:

What has the student completed, and what must they repeat before progressing?

A student who is held back, repeats a phase, or has incomplete competencies normally remains Active in the programme. Those decisions belong to Academic Progression. They do not become an approved break, withdrawal, or discontinuation unless a separate lifecycle decision is made.

For MBBS, passing the final professional examination is also not the same as programme completion. Internship and any other compulsory requirement must be complete before the programme enrolment can become Completed.

Before you start

The student must have an existing programme enrolment.
The enrolment must point to the student’s institute programme, curriculum version, admission source, and cohort membership.
The applicable lifecycle policy must be resolved from the programme, admission batch, institute, university, and governing regulation version.
The user must have the Academic Registrar role or another role permitted for the requested action.
Any academic result used in the decision must come from its owning academic record.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Owns the lifecycle work queue, validates requests, records decisions, makes approved changes effective, and tracks reporting within the institute
Institute member with Student Records Officer role	Prepares records, checks documents, and follows up reporting; cannot approve a sensitive transition unless separately authorised
Institute member with Dean or Principal role	Approves high-impact decisions within the granted institute scope, such as discontinuation, exceptional resumption, permitted migration, or programme change
Student	Submits permitted requests, uploads evidence, views notices and decisions, and responds or appeals where the policy allows
Institute Admin	Assigns roles and views institute summaries; does not receive lifecycle decision-making access merely from being an administrator
Tenant Admin	Views scoped summaries and maintains tenant policy defaults; does not automatically receive sensitive student details or institute decision rights
Department Admin and Faculty	View the operational status needed for assigned teaching or supervision and may submit a recommendation; cannot change the enrolment state
Auditor role	Reads requests, checks, approvals, state events, reporting, reversals, and access history within scope

The Academic Registrar role is the primary functional role for this service. Organisational scope determines which institute records the user can reach. The role grant determines which lifecycle actions they may perform.

Enrolment states

State	Meaning
Active	The student is officially enrolled. A student who is repeating academic work normally remains Active
On Approved Break	A formally approved long break has temporarily paused the student’s planned participation and affects dates or training requirements
Withdrawn	The student voluntarily ended the programme enrolment through an approved request
Discontinued	The institute ended the enrolment through an authorised decision rather than a student request
Transferred Out	The student left through a migration or transfer process that is permitted and fully approved under the applicable rules
Superseded	An expressly approved programme or curriculum change created a linked successor enrolment; the earlier enrolment remains in history
Completed	The student completed every compulsory academic, clinical, internship, and other programme requirement
Cancelled	The underlying admission or enrolment was formally cancelled. This is not used to hide an erroneous record

Not every state or transition is available for every programme. The applicable policy controls the actions displayed to the user.

Resumption is an event that returns an enrolment from On Approved Break to Active. Readmission after withdrawal or discontinuation is not treated as an ordinary resumption. It requires an explicitly permitted process and may create a successor enrolment rather than reopening the old one.

Request lifecycle

The request and the programme enrolment have separate states.

Draft
  -> Submitted
  -> Under Review
  -> Awaiting Approval
  -> Approved or Rejected
  -> Effective
  -> Reporting Complete

A request may also be withdrawn before approval. A rejected or withdrawn request does not change the programme enrolment.

Approval and reporting are also separate. A decision may become effective before an external acknowledgement arrives when the applicable policy permits it, but the reporting task remains open until completed.

Screen structure and data captured

The workspace contains Lifecycle Work Queue, Student Lifecycle Summary, Lifecycle Request, Rules and Impact Review, Decision and Approval, Reporting and Follow-up, and History and Appeals.

Screen 1: Lifecycle Work Queue

The queue shows requests that are Draft, Submitted, Under Review, Awaiting Approval, Approved but Not Effective, Reporting Pending, Completed, Rejected, or Withdrawn.

Each row shows:

student name and student number;
institute, programme, curriculum, and cohort;
current enrolment state;
requested transition;
request reason and effective date;
current owner and next action;
approval and reporting position;
due date and warnings.

Users see only the institutes and work assigned to their role and scope.

Screen 2: Student Lifecycle Summary

The summary gives the reviewer the information needed to understand the request without allowing them to rewrite its source records.

Section	Information shown
Student and enrolment	Student number, admission source, programme, curriculum version, cohort, start date, current state, and earlier lifecycle events
Academic position	Current phase, completed requirements, pending requirements, progression decisions, attendance position, and internship position from their owning modules
Time position	Time already used, approved exclusions or extensions, expected completion date, and applicable maximum duration
External position	University registration, scholarship, sponsorship, bond, and authority relationships where applicable
Open work	Pending academic decisions, appeals, admission movements, identifier corrections, or other requests that may block the transition

The summary links to an owning record only when the viewer has access to it.

Screen 3: Lifecycle Request

Field	Required	Meaning and validation
Student and programme enrolment	Yes	Selected from the user’s institute scope; read-only after the request is created
Requested transition	Yes	Available choices come from the current state and applicable lifecycle policy
Request source	Yes	Student, institute, university, regulator, court, or another configured source
Reason code	Yes	Controlled reason appropriate to the transition
Reason details	Yes	Plain-language explanation of the request
Requested effective date	Yes	Date on which the change is intended to take effect
Expected return date	Conditional	Required for an approved break when known
Supporting evidence	Conditional	Documents required by the selected transition and reason
Student acknowledgement	Conditional	Confirms that the student submitted or received the request as applicable
Contact and notice details	Conditional	Address, delivery method, and date used for formal notice

The screen states which fields came from the student, which were recorded by the institute, and which remain unverified.

Screen 4: Rules and Impact Review

The system evaluates the request against a policy version rather than relying on the reviewer to remember every rule.

Check	What the reviewer sees
Transition permission	Whether the requested change is allowed for this programme, batch, current state, institute, and governing rule version
Timing	Cutoff, minimum or maximum duration, notice period, break period, and permitted effective date
Required evidence	Each required document or order and whether it is valid
Required authority	The role or external body that must approve the decision
Academic impact	Remaining training, attendance, phase, clinical posting, internship, and expected-completion impact
Cohort impact	Whether membership pauses, ends, or requires a later cohort reassignment
Seat impact	Whether an authority decision is required; the seat is never automatically returned to Admissions
Service impact	Timetable, attendance, hostel, library, learning systems, identity access, stipend, fee, scholarship, sponsorship, and bond follow-up
Reporting	University, counselling, government, regulator, sponsor, or other notifications required by policy

Every failed check names the rule, source, responsible owner, and safe next action. The reviewer may save a draft but cannot submit an invalid transition for approval unless the policy provides an authorised exception route.

Screen 5: Decision and Approval

Field	Required	Meaning and validation
Reviewer recommendation	Yes	Recommend approval, return for information, or recommend rejection
Review notes	Yes	Findings and unresolved conditions
Approving role	Yes	Resolved from the transition policy
Decision	Yes	Approve or reject
Decision reason	Yes	Reason recorded by the approver
Approval order/reference	Conditional	Required where a formal order is issued
Approved effective date	Yes on approval	May differ from the requested date, with a reason
Conditions	Conditional	Requirements that must be completed before or after effectiveness

The requester cannot approve their own sensitive request. The screen shows whether additional university or regulatory approval is still required before the change can become effective.

Screen 6: Reporting and Follow-up

Field	Required	Meaning and validation
Reporting body	Yes	University, counselling authority, government, regulator, sponsor, or another configured organisation
Report type	Yes	Notice, approval request, surrender, migration, discontinuation, completion, or another configured report
Due date	Conditional	Calculated or entered deadline
Submission date and reference	Conditional	Required after submission
Submitted package	Conditional	Exact data and document version sent
Acknowledgement state	Yes	Not Required, Pending, Accepted, Returned, or Rejected
Response and evidence	Conditional	Required after an external response
Follow-up owner	Yes	User or work queue responsible for closing the task

The reporting screen tracks the obligation. It does not pretend that MedCES has received an external acknowledgement until evidence is recorded.

Screen 7: History and Appeals

History shows every request, check, document version, recommendation, approval, rejection, notice, response, state event, report, acknowledgement, appeal, correction, and reversal. It is read-only.

Where an appeal is permitted, the student or authorised officer can open the original decision, submit the appeal and evidence, and track the reviewing authority. An appeal does not silently undo the original event. A successful appeal creates a linked reversal or successor decision.

Use case 1: View programme-enrolment lifecycle work

As an Academic Registrar
I want to see lifecycle requests and their next actions
So that no student decision or reporting obligation is missed.

Acceptance criteria

The queue is limited to the user’s organisational scope and granted capabilities.
Each request shows its current state, owner, due date, blocker, approval position, and reporting position.
Sensitive evidence is hidden unless the role has field-level access.
Users can filter by institute, programme, cohort, transition, request state, effective date, and owner.
Overdue approvals and reporting tasks are clearly identified.

Use case 2: Submit a lifecycle request

As a Student or authorised institute officer
I want to submit a permitted lifecycle request with evidence
So that the request can be reviewed through a recognised process.

Acceptance criteria

The system shows only transitions permitted from the current enrolment state.
The request records its source, reason, requested date, evidence, and submitter.
Required fields and documents are determined by transition and reason.
Submission does not immediately change the programme enrolment.
A duplicate open request for the same purpose is blocked or linked for review.
The student can see the submitted request and its current position without seeing restricted internal notes.

Use case 3: Review regulatory and institutional requirements

As an Academic Registrar
I want to review the applicable rules and impact
So that the decision is based on the student’s actual programme and batch.

Acceptance criteria

The system resolves and records the exact policy and regulation version used for the review.
Checks cover transition permission, timing, evidence, approval, programme duration, academic impact, and reporting.
A rule result records Pass, Fail, Warning, Not Applicable, or Requires External Decision.
The reviewer cannot mark a failed check as passed without an allowed exception route and recorded authority.
Later policy changes do not rewrite the completed review.

Use case 4: Place a student on an approved break

As an Academic Registrar
I want to process a formally approved long break
So that the enrolment, academic plan, and expected completion date remain accurate.

Acceptance criteria

The request records the reason, break dates, evidence, approving authority, and applicable rule.
The system distinguishes a lifecycle break from ordinary attendance leave.
The impact review calculates affected training, attendance, postings, expected completion, and maximum-duration checks.
Approval changes the enrolment from Active to On Approved Break on the approved effective date.
Cohort membership is paused or retained according to policy; historical membership is not deleted.
Operational owners receive follow-up tasks without changing earlier academic records.

Use case 5: Resume after an approved break

As an Academic Registrar
I want to confirm that a student can return from an approved break
So that the student resumes against a valid academic plan.

Acceptance criteria

Resumption is available only from On Approved Break.
The system validates return evidence, approved return date, remaining duration, curriculum compatibility, and academic readiness.
A new or resumed cohort membership is selected through an approved placement decision when the original cohort is no longer suitable.
Approval returns the enrolment to Active on the effective date.
Academic Planning receives the confirmed placement but owns the new phase plan and learning assignments.
Earlier break dates, approvals, and impacts remain unchanged in history.

Use case 6: Process voluntary withdrawal

As an Academic Registrar
I want to process a student’s voluntary withdrawal
So that the programme relationship ends through a traceable decision.

Acceptance criteria

The student’s request and identity confirmation are retained.
The system records the requested and approved effective dates separately.
Fee, scholarship, stipend, bond, hostel, and property clearance are tracked as follow-up items and do not overwrite the academic record.
The seat is not automatically returned to the seat matrix or a counselling round.
Approval changes the enrolment to Withdrawn and ends or closes the active cohort membership according to policy.
Required university and authority reporting remains open until completed.

Use case 7: Process institute-initiated discontinuation

As an Academic Registrar or Dean/Principal
I want to process an authorised discontinuation
So that the institute does not record an involuntary decision as a student withdrawal.

Acceptance criteria

The grounds, source decision, notice, delivery evidence, student response, and applicable rule are recorded.
The required Dean, Principal, university, committee, or other authority is resolved by policy.
A student response or permitted appeal is linked to the decision.
The requester and final approver are separated for sensitive decisions.
Approval changes the enrolment to Discontinued only on the effective date.
The original decision remains visible if an appeal later reverses it.

Use case 8: Process permitted migration or transfer

As an Academic Registrar
I want to process migration only where the programme rules permit it
So that an institute change is not performed as an ordinary data edit.

Acceptance criteria

The action is hidden or blocked when migration is prohibited for the student’s programme or rule version.
Timing, institute eligibility, recognition, capacity, reason, and required approvals are checked.
Required relieving institute, receiving institute, university, or regulatory decisions are retained where applicable.
The source enrolment is not changed to point to another institute.
An approved transfer closes the source relationship as Transferred Out and links it to the receiving relationship or external reference.
The transition cannot become effective merely because an application was submitted.

Use case 9: Process exceptional readmission

As an Academic Registrar and required approver
I want to review a request to return after withdrawal or discontinuation
So that a closed enrolment is not reopened without explicit authority.

Acceptance criteria

The system first determines whether readmission is permitted under the applicable rules.
Original exit reason, time away, maximum duration, curriculum changes, remaining requirements, and cohort placement are reviewed.
Required institute, university, or regulatory approval is recorded.
The process creates a linked successor enrolment when reopening the earlier enrolment would misrepresent history.
A prohibited readmission is rejected with the applicable rule shown.
Earlier withdrawal or discontinuation events remain unchanged.

Use case 10: Process an authorised programme or curriculum change

As an Academic Registrar and required approver
I want to process an exceptional programme or curriculum change through a controlled route
So that the student’s earlier official enrolment and completed work are not rewritten.

Acceptance criteria

The system does not allow the programme or curriculum version to be edited directly on an active enrolment.
The request is available only when the applicable admission, university, institute, and regulatory rules permit the change.
The target institute programme and published curriculum version are validated before approval.
An approved academic mapping identifies recognised work, pending work, and requirements that must be repeated.
Required capacity, authority, timing, and reporting checks must pass.
Approval creates a linked successor enrolment and changes the earlier enrolment to Superseded on the effective date.
Earlier academic, attendance, competency, identifier, admission, and cohort records remain linked to the enrolment under which they occurred.

Use case 11: Complete a programme enrolment

As an Academic Registrar
I want to complete the enrolment only after every compulsory requirement is confirmed
So that programme completion is not inferred from a date or one examination result.

Acceptance criteria

Completion reads authoritative academic results, competencies, postings, internship, attendance, and other compulsory requirements configured for the programme.
Every required completion check must pass or have an expressly permitted decision.
For MBBS, passing the final professional examination alone does not complete the programme; compulsory internship must also be complete.
The completion date and approving authority are recorded.
Approval changes the enrolment from Active to Completed and ends active cohort membership without deleting history.
Degree award, university result publication, alumni status, and professional registration remain separate records or later processes.

Use case 12: Complete external reporting

As an Academic Registrar or Student Records Officer
I want to track every required notification and acknowledgement
So that an effective decision does not disappear from regulatory follow-up.

Acceptance criteria

Reporting tasks are created from the policy version used by the approved request.
Each task records the body, report type, due date, submission, package version, reference, response, and evidence.
Returned or rejected reports create follow-up work without rewriting the earlier submission.
A request remains Reporting Pending until every required task is closed.
Dashboard counts distinguish an effective state change from completed reporting.

Use case 13: Appeal, reverse, or correct a lifecycle decision

As an authorised Student, Academic Registrar, Dean/Principal, or Auditor
I want to trace and, where permitted, review an earlier decision
So that corrections do not erase the official sequence of events.

Acceptance criteria

An appeal references the original request and decision.
The reviewing authority is resolved independently from the original approver where policy requires it.
A successful appeal creates a linked reversal or successor event.
Clerical corrections record the earlier value, corrected value, reason, evidence, and approver.
No authorised user can delete a state event or silently backdate a decision.
Exported history includes event time, effective time, actor, role grant, scope, reason, authority, and reporting position.

Business rules

An enrolment state cannot be edited directly.
Every transition uses a request, an applicable policy version, an approval route, an effective date, and an immutable state event.
The rule set is resolved from the programme, batch, curriculum, institute, university, and governing authority context.
Academic hold-back, repeat, remediation, and progression do not themselves change the programme-enrolment state.
A long approved break and ordinary leave are different records.
Voluntary withdrawal and institute-initiated discontinuation are different decisions.
Migration is available only when the applicable programme rules permit it.
Withdrawal or discontinuation does not automatically create an admission vacancy.
Resumption from an approved break and readmission after a closed enrolment are different processes.
Programme and curriculum changes never overwrite the earlier enrolment; an approved change creates a linked successor record.
Completion requires every compulsory programme requirement, not merely the passage of time or completion of a phase.
A role that prepares or recommends a sensitive decision does not automatically have approval access.
Current state is a convenient projection; state-event history is the authoritative record of how it changed.
Backdated decisions require an allowed reason and additional approval and retain both recorded and effective times.

Technical design

How the records relate

student.programme_enrolment
├── student.cohort_membership
├── student.enrolment_lifecycle_request
│   ├── student.enrolment_rule_result
│   ├── student.enrolment_lifecycle_approval
│   ├── student.enrolment_external_report
│   └── student.enrolment_appeal
└── student.enrolment_state_event

academic progression, attendance, competency, posting, and internship records
  -> referenced as evidence and completion checks
  -> not rewritten by the lifecycle service

Conceptual schema

Record	Important fields
`student.programme_enrolment`	student, institute programme, curriculum version, admission case, start date, current state, current state-event id, predecessor/successor enrolment, expected completion date, row version
`student.enrolment_lifecycle_policy`	policy code/version, programme type, batch applicability, institute/university/authority context, permitted transitions, approval route, evidence rules, duration rules, reporting rules, status
`student.enrolment_lifecycle_request`	enrolment, from state, requested transition, source, reason, requested/effective dates, expected return date, state, requester, current owner
`student.enrolment_request_evidence`	request, evidence type, document reference, issuer, issue/expiry dates, verification state, verified by/at
`student.enrolment_rule_result`	request, policy version, rule code, result, input snapshot, explanation, checked at
`student.enrolment_lifecycle_approval`	request, approval step, required role/authority, decision, reason, order/reference, actor, decided at
`student.enrolment_state_event`	enrolment, request, earlier/new state, effective at, recorded at, reason, policy version, actor, approver, reversal-of event
`student.enrolment_external_report`	request, reporting body, report type, due date, package version, submission/reference, acknowledgement state, response evidence, owner
`student.enrolment_appeal`	original request/decision, appellant, grounds, evidence, reviewing authority, decision, linked reversal or successor request
`student.enrolment_impact_snapshot`	request, academic, cohort, duration, seat, service, finance, scholarship, bond, access, and reporting impacts calculated at review

Supporting documents should be stored through the common document service. The lifecycle records retain document references and verification results rather than copying files into each request.

Process-layer responsibilities

The process layer must:

enforce institute scope, functional role, assignment, record-state, and field-level access on every action;
resolve the applicable versioned policy before displaying or accepting a transition;
validate the requested transition against the current enrolment state at submission and again at effectiveness;
read academic facts from their owning modules without rewriting them;
calculate duration, cohort, seat, reporting, and operational impacts;
enforce the approval route and prevent self-approval where separation is required;
append the state event and update the current-state projection in one transaction;
make repeated submissions and retries return the existing effective result instead of creating duplicate events;
create reporting and follow-up work from the approved policy snapshot;
preserve earlier requests, approvals, reports, events, appeals, and reversals;
recalculate access and operational assignments from the effective date without deleting historical records;
prevent a partial failure from leaving the current state and state-event history inconsistent.

Regulatory references

The exact rule must be pinned to the programme and admission batch. The following official sources inform the initial policy catalogue and must not be treated as one universal rule for every programme:

Success outcome

Every programme-enrolment change is permitted for the student’s programme and batch, supported by evidence, approved by the correct authority, effective from a clear date, reported where required, and permanently explainable from its history.