Student Academic Progression and Cohort Movement

Epic summary

The Student Academic Progression and Cohort Movement workspace determines whether an individual student is ready to move from their current curriculum phase to the next phase.

It uses the phase-transition conditions published in the curriculum version pinned to the student’s programme enrolment.

Published curriculum transition
  + final student academic facts
  -> progression evaluation
  -> authorised progression decision
  -> phase assignment and, when needed, cohort movement

The workspace supports students who progress with their cohort and students who are held back, complete remediation, or later join another cohort for academic delivery.

Important boundary

A held-back student normally remains Active in the programme enrolment.

Holding a student back changes:

the student’s academic progression position;
their current phase assignment;
the requirements still pending;
and possibly the cohort or learner group used for future delivery.

It does not by itself create an approved break, withdrawal, discontinuation, or other programme-enrolment lifecycle state.

Assessment and Examination owns eligibility, examination occurrences, marks, attempts, and final assessment outcomes. This epic reads the final assessment outcome required by the curriculum transition. It does not recalculate it.

Before you start

The student must have an Active programme enrolment and a pinned published curriculum version.
The student’s current phase assignment must be known.
The curriculum version must contain a published transition from the current phase to the target phase.
Required source records must exist in their owning modules, such as assessment outcomes, course completion, posting completion, competency sign-off, logbook completion, or academic decisions.
The applicable cohort phase plan must identify the evaluation window and cutoff date.
The user must have the Academic Registrar or another authorised progression role.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Owns the progression workbench, evaluates students, coordinates review, records decisions, and confirms phase or cohort placement
Institute member with Progression Committee Member role	Reviews assigned students and records recommendations or committee decisions within scope
Institute member with Dean or Principal role	Approves exceptional progression or another decision where the curriculum and institute workflow require it
Department Admin and authorised Faculty	Reviews source academic work and recommendations for assigned students; cannot change the final progression decision without the required role
Student	Views their published progression position, unmet requirements, decision, and permitted review or appeal route
Institute Admin	Views institute-level summaries and assigns roles; does not receive academic decision access merely from being an administrator
Tenant Admin	Views scoped summary counts; detailed student information and institute decisions require the appropriate functional access
Auditor role	Reads evaluations, inputs, decisions, exceptions, movements, reversals, and access history

Progression evaluation states

State	Meaning
Not Started	No evaluation has been created for the student and transition
Awaiting Data	One or more required conditions cannot yet be evaluated
Ready to Progress	Every required condition is satisfied
Not Ready	One or more required conditions are not satisfied
Review Required	A condition, exception, conflict, or source correction needs authorised review
Decision Recorded	An authorised progression decision has been made
Applied	The approved phase assignment and any cohort movement have completed
Reversed	A later authorised decision reversed the earlier decision without deleting it

Evaluation state and decision outcome are separate. Ready to Progress is a recommendation, not a phase movement.

Decision outcomes

Outcome	Meaning
Progress	Move the student to the target phase from the approved effective date
Hold in Current Phase	Keep the student in the source phase until pending requirements are resolved
Progress by Approved Exception	Move despite a named unsatisfied condition through a permitted exception route
Return for Data Correction	No academic decision; the owning source record must be corrected or finalised
Defer Decision	Keep the case open until a stated review date or dependency is available

There is no ordinary manual Pass button. The decision must reference the evaluation and explain any difference from the recommendation.

Screen structure and data captured

The workspace contains Progression Workbench, Student Evaluation, Condition Evidence, Decision Review, Phase and Cohort Placement, Student Progression View, and History.

Screen 1: Progression Workbench

The workbench is opened for a cohort and curriculum transition, such as Phase I to Phase II.

Each student row shows:

student name and number;
programme enrolment and curriculum version;
current phase and cohort;
target phase;
evaluation state;
satisfied, unsatisfied, and missing condition counts;
required assessment-outcome position;
recommendation;
decision state;
proposed effective date;
assigned reviewer and warnings.

Users can filter by condition result, assessment outcome, recommendation, decision state, current cohort, and assigned reviewer. Bulk evaluation is allowed; bulk academic decisions are not assumed to be allowed.

Screen 2: Student Evaluation

The screen evaluates the condition tree from the student’s pinned curriculum version.

ALL conditions must be satisfied

✓ First Professional MBBS final outcome is Passed
✕ Phase I competencies are 40 of 42 certified
✓ Phase I course-completion requirements are complete
? One progression blocker source is not finalised

Overall: Not Ready

Each condition shows:

curriculum requirement;
required value or state;
actual value or state;
Satisfied, Not Satisfied, or Unable to Evaluate;
source module and records;
data cutoff and finality;
plain-language explanation;
source owner responsible for correction.

The evaluator cannot edit the source fact from this screen.

Screen 3: Condition Evidence

This screen shows the exact evidence used for a selected condition.

Information	Meaning
Condition definition	Category, comparator, threshold, AND/OR group, and curriculum source
Source records	Assessment result, course completion, competency sign-off, posting completion, logbook, duration, decision, or blocker record used
Finality	Draft, final, published, revoked, superseded, or another supported state
Cutoff	Time up to which facts were included
Calculation	Required and actual values with unit and rounding where applicable
Result explanation	Why the condition was satisfied, not satisfied, or unavailable

Restricted source evidence remains hidden unless the viewer has access. The condition result can still be shown where policy permits.

Screen 4: Decision Review

Field	Required	Meaning and validation
Evaluation	Yes	Final evaluation snapshot being reviewed
Recommendation	Inherited	Ready, Not Ready, Awaiting Data, or Review Required
Proposed outcome	Yes	Progress, Hold, Approved Exception, Return for Correction, or Defer
Decision reason	Yes	Plain explanation of the decision
Pending requirements	Conditional	Requirements the student must still complete when held
Review date	Conditional	Next formal review date for Hold or Defer
Effective date	Conditional	Required for Progress or approved phase placement
Required approver	Inherited	Role resolved from the curriculum transition and exception policy
Exception reference	Conditional	Required when the decision differs from the rule result through an allowed exception
Student notice	Conditional	Notice date, delivery method, and acknowledgement where required

If source facts change after the evaluation snapshot, the screen marks the evaluation stale and requires re-evaluation before an ordinary decision.

Screen 5: Phase and Cohort Placement

An approved Progress decision creates the target phase assignment.

Field	Required	Meaning and validation
Target phase	Inherited	Target from the published curriculum transition
Effective date	Inherited/confirmed	Approved progression date
Delivery cohort	Conditional	Cohort whose phase plan the student will follow where it differs from the original cohort
Membership action	Yes	Retain original cohort, add an academic delivery membership, or close and replace active delivery membership according to policy
Learner-group placement	Deferred/reference	Completed later in Academic Planning and Delivery
Placement reason	Conditional	Required when the student does not remain with the original cohort
Approval	Conditional	Required for exceptional cohort movement

The student’s curriculum version remains unchanged. A cohort move cannot silently place the student under another curriculum version.

Screen 6: Student Progression View

The student and authorised staff see:

current phase and curriculum version;
current cohort and any academic delivery cohort;
evaluated transition;
published requirement results;
pending requirements;
decision and effective date;
next review date;
permitted review or appeal route.

Internal committee notes and restricted evidence are not exposed to the student.

Screen 7: History

History shows evaluations, input snapshots, stale evaluations, recommendations, committee reviews, decisions, notices, phase assignments, cohort movements, reversals, and source links. It is read-only.

Worked example: student held in Phase I

The Phase I to Phase II transition requires all Phase I competencies to be certified and the final First Professional outcome to be Passed.

For one student:

First Professional outcome: Passed
Required competencies: 42
Certified competencies: 40
Overall evaluation: Not Ready

The Academic Registrar records Hold in Current Phase, identifies the two pending competencies, and sets a review date. The student:

remains Active in the MBBS programme enrolment;
remains assigned to Phase I;
retains the same curriculum version;
receives an academic plan for the pending work from Academic Planning and Delivery;
may later be associated with another cohort’s Phase I delivery where required.

After the competencies are completed, MedCES creates a new evaluation. The earlier Not Ready evaluation and Hold decision remain in history.

Use case 1: Open a cohort progression workbench

As an Academic Registrar
I want to see all students due for one phase transition
So that missing data and individual exceptions are identified before decisions.

Acceptance criteria

The workbench resolves the cohort’s curriculum version and applicable transition.
Every student row shows condition counts, recommendation, decision state, and warnings.
Users see only institutes and students within their scope.
A cohort phase date passing does not mark students as progressed.
Summary counts link to the underlying student cases.

Use case 2: Evaluate a student against the published transition

As an Academic Registrar
I want to evaluate a student using their pinned curriculum
So that every recommendation follows the correct version-specific rule.

Acceptance criteria

The system uses the curriculum version stored on the programme enrolment.
It loads the transition from the student’s current phase to the selected target phase.
Every leaf condition records required value, actual value, source, finality, cutoff, and result.
AND and OR groups follow the published tree.
Missing or unfinalised facts produce Unable to Evaluate.
Repeating an unchanged evaluation returns or reuses the same result rather than creating conflicting snapshots.

Use case 3: Review condition evidence

As an authorised reviewer
I want to understand why a condition passed or failed
So that the recommendation is explainable.

Acceptance criteria

The screen shows the published condition and the exact source records used.
Source field ownership and finality are visible.
The reviewer cannot edit assessment, attendance, competency, posting, or logbook evidence from progression.
A correction link opens the owning module only where the user has access.
Sensitive evidence follows field-level restrictions.

Use case 4: Record ordinary progression

As an Academic Registrar or authorised progression approver
I want to approve progression for a ready student
So that their target phase assignment begins from a clear date.

Acceptance criteria

Every mandatory condition must be Satisfied unless an allowed exception route is used.
The decision references a non-stale evaluation snapshot.
Decision reason, authority, and effective date are recorded.
The target phase comes from the curriculum transition and cannot be replaced freehand.
Applying the decision creates one target phase assignment and closes the earlier current assignment appropriately.
Repeating the apply action returns the existing assignment.

Use case 5: Hold a student in the current phase

As an authorised progression decision-maker
I want to hold a student who has unmet requirements
So that the pending work and next review are explicit.

Acceptance criteria

The decision references every relevant unsatisfied or unavailable condition.
Pending requirements, reason, decision authority, notice, and next review date are recorded.
The current phase assignment remains active.
The programme enrolment remains Active unless a separate lifecycle decision changes it.
Academic Planning and Delivery receives the pending-work context but owns the repeat or remediation plan.
The Hold decision remains visible after a later successful progression.

Use case 6: Progress through an approved exception

As a Dean, Principal, or other authorised exception approver
I want to decide a progression exception permitted by the curriculum
So that the system does not disguise it as an ordinary pass.

Acceptance criteria

The curriculum transition must explicitly allow an exception route.
The exact unsatisfied condition, authority, reason, evidence, and conditions are recorded.
The requester cannot self-approve where separation is required.
The resulting decision is labelled Progress by Approved Exception.
If the curriculum does not permit an exception, the action is unavailable.

Use case 7: Move a student to another cohort for delivery

As an Academic Registrar
I want to associate a held-back or delayed student with an appropriate delivery cohort
So that the student can complete pending academic work without losing history.

Acceptance criteria

The target cohort belongs to the same institute programme and uses the same curriculum version, or an approved curriculum-migration process is completed separately.
Capacity, phase plan, dates, and academic compatibility are checked.
Earlier cohort membership is retained in history.
The reason, effective dates, and approval are recorded.
Course offerings, learner groups, posting rotations, and timetable assignments are created by Academic Planning and Delivery rather than copied automatically here.

Use case 8: Re-evaluate after pending work is completed

As an Academic Registrar
I want to run a new evaluation after source facts change
So that the student can progress when the published requirements are satisfied.

Acceptance criteria

A new snapshot reads the latest final source facts up to the selected cutoff.
Earlier evaluations and decisions remain unchanged.
Changed condition results clearly identify the new source evidence.
A Ready recommendation still requires the configured progression decision.
Successful application updates the phase assignment exactly once.

Use case 9: Return incomplete or conflicting data to its owner

As an Academic Registrar
I want to return a case for source correction
So that progression does not alter another module’s record.

Acceptance criteria

The case identifies the owning module, source record, problem, and responsible work queue.
Progression stores a follow-up item, not a replacement academic fact.
The case remains Awaiting Data or Review Required until a final source record exists.
Technical users cannot make academic decisions while resolving integration failures.
Re-evaluation records which corrected source version was used.

Use case 10: View student progression history

As an authorised user or Student
I want to understand the student’s progression history
So that current phase and earlier decisions can be explained.

Acceptance criteria

Authorised staff see evaluations, evidence references, decisions, assignments, cohort movements, and reversals.
Students see their published outcomes, pending requirements, decisions, dates, and available review route.
Internal notes and restricted evidence remain protected.
History cannot be edited or deleted.
Export follows the viewer’s current scope and field permissions.

Business rules

The student’s pinned curriculum version determines the applicable transition and conditions.
Progression evaluation never uses the latest curriculum version merely because it exists.
Evaluation and authorised decision are separate records.
Ready to Progress never moves a student automatically.
A held-back student normally retains an Active programme enrolment.
Phase assignment, cohort membership, programme enrolment, and curriculum version are separate relationships.
A cohort move cannot silently change the curriculum version.
Source academic facts are read from their owning modules and are not edited here.
Missing or unfinalised facts never count as satisfied.
Exceptional progression is available only when the published transition permits it.
Earlier evaluations, Hold decisions, movements, and reversals remain immutable history.
Applying the same approved decision more than once cannot create duplicate assignments or memberships.

Technical design

How the records relate

student.programme_enrolment -> pinned academic.curriculum_version
student.student_phase_assignment -> current academic.curriculum_stage

academic.curriculum_phase_transition
└── academic.progression_condition_group and conditions
    -> student.progression_evaluation
       ├── student.progression_condition_result
       └── student.progression_decision
           ├── student.student_phase_assignment
           └── student.cohort_movement -> student.cohort_membership

Conceptual schema

Record	Important fields
`student.student_phase_assignment`	programme enrolment, curriculum stage, effective start/end, assignment state, source decision, academic delivery cohort
`student.progression_evaluation`	programme enrolment, curriculum version, transition, source phase assignment, data cutoff, input snapshot/hash, state, overall recommendation, evaluated at/by
`student.progression_condition_result`	evaluation, condition/group, required and actual values, source records/finality, Satisfied/Not Satisfied/Unable result, explanation
`student.progression_decision`	evaluation, proposed/final outcome, reason, pending requirements, review/effective dates, authority, exception reference, notice, state
`student.cohort_movement`	programme enrolment, from/to cohort membership, phase, reason, effective dates, source decision, approval, state
`student.progression_follow_up`	evaluation/decision, owning module, source record, problem, owner, due date, resolution state
`student.progression_reversal`	original decision, reason, evidence, authority, reversal decision, applied at

The evaluation stores an input snapshot or stable references to exact source versions so a later source correction does not rewrite why the earlier decision was made.

Process-layer responsibilities

The process layer must:

enforce institute scope, functional role, assignment, and field-level access;
resolve the transition from the programme enrolment’s pinned curriculum version;
obtain final academic facts from their owning modules up to a clear cutoff;
evaluate typed conditions and AND/OR groups using three-state logic;
retain required, actual, source, finality, and explanation for every condition;
mark an evaluation stale when a relevant source fact changes before decision;
enforce decision and exception approval routes;
apply the phase assignment and cohort movement atomically and exactly once;
keep the programme enrolment Active for an academic hold unless a separate lifecycle event applies;
prevent curriculum change through ordinary cohort movement;
preserve evaluations, decisions, movements, notices, and reversals as immutable history.

Success outcome

Every student phase movement can be explained from the exact published curriculum transition, final source evidence, authorised decision, effective phase assignment, and cohort history, while held-back students remain correctly enrolled and visible for follow-up.