Planned Cohort Management

Epic summary

The Planned Cohort Management workspace creates and governs a cohort for one institute programme and intake.

For example:

Institute programme: MBBS
Curriculum version: MBBS CBME 2026 v1
Cohort: MBBS 2026 Batch
Planned intake: 100

The cohort must exist before Admissions can add the programme to an admission cycle. After a candidate’s admission and joining are confirmed, the enrolment handoff creates the student’s programme enrolment and cohort membership.

Before you start

The tenant and institute must be active.
The institute programme must be active.
At least one applicable curriculum version must be published.
The programme’s approved intake must be recorded for the intended period.
An applicable published Student Number policy must exist at tenant or institute scope.
Required authority relationships and functional roles must be active.
The user must have Institute Admin or the Academic Registrar functional role at the institute.

Actors and access

Access source	Access in this epic
Tenant Admin	Views institutes and cohort summaries throughout the tenant; does not automatically receive sensitive student details
Institute Admin	Creates and manages cohorts and views all cohort dashboards within the institute
Institute member with Academic Registrar role	Creates, reviews, amends, and manages cohorts within scope
Institute member with Cohort Approver role	Approves availability, controlled amendments, cancellation, or completion where configured
Admission Nodal Officer	Selects available cohorts and views admission-linked counts; cannot change cohort-owned fields
Student Section Officer	Monitors enrolment handoff and resolves permitted exceptions
Department Admin	Views the parts of a cohort connected to the department’s courses and postings
Faculty	Views cohorts and learners connected to current teaching or supervision assignments
Student	Views their own cohort and curriculum information
Auditor role	Reads readiness, changes, state transitions, and reconciliation history within scope

Screen structure and data captured

The workspace contains Cohort Directory, Cohort Details, Curriculum Review, Readiness and Availability, Cohort Dashboard, Amend or Cancel, and History.

Screen 1: Cohort Directory

The directory opens at the user’s permitted scope.

A Tenant Admin sees institutes within the tenant and can open their cohort lists.
An Institute Admin or Academic Registrar sees cohorts in their institute.
Department and faculty users see only cohorts connected to permitted academic work.

Users can search and filter by institute, programme, intake year, academic session, curriculum version, current phase, and cohort status.

Each row shows cohort code and name, programme, curriculum version, planned intake, enrolled learners, status, current phase, and warnings.

Screen 2: Cohort Details

Field	Entry type	Required	Meaning and validation
Institute	Selected from scope	Yes	Institute that owns the cohort; fixed after creation
Institute programme	Selected	Yes	Active institute-owned programme
Cohort name	Entered/generated	Yes	Human-readable name, for example `MBBS 2026 Batch`
Cohort code	Entered/generated	Yes	Unique inside the institute
Intake year	Entered/selected	Yes	Year in which the cohort is admitted
Academic session	Selected	Yes	Approved session covering the intended intake
Planned intake	Entered	Yes	Positive whole number checked against the effective approved intake
Expected start date	Entered	Yes	Intended start of the cohort’s academic lifecycle
Expected completion date	Entered	No	Expected completion based on programme duration and local planning
Student-number policy	System resolved	Yes	Applicable institute override or tenant fallback; pinned when the cohort becomes available to Admissions
Notes	Entered	No	Operational context; cannot replace approval evidence
Status	System controlled	Yes	Draft, Available for Admission, Active, Completed, or Cancelled

Screen 3: Curriculum Review

The user selects one published curriculum version applicable to the programme and intake.

Before confirmation, the screen shows:

curriculum name and version;
source programme pack and local approval;
effective period;
expected programme duration;
stages or phases in order;
course placements;
clinical-posting requirements;
progression requirements;
any known delivery-readiness gaps.

The curriculum version is pinned when the cohort becomes available to Admissions. A newer curriculum version does not move this cohort automatically.

Screen 4: Readiness and Availability

The screen lists every readiness check as Passed, Warning, or Blocking and links a failed check to its source screen.

Blocking checks include:

inactive institute or programme;
missing or unpublished curriculum version;
curriculum not applicable to the intake;
planned intake above the supported approved intake;
duplicate or conflicting cohort;
invalid dates;
missing required authority relationship;
missing required functional role;
missing, unpublished, or inapplicable student-number policy;
unresolved curriculum or programme status issue.

An authorised user can make the cohort Available for Admission only when all blocking checks pass.

Screen 5: Cohort Dashboard

The dashboard presents information from its owning modules without creating duplicate records.

Section	Information shown
Cohort identity	Institute, programme, intake, status, curriculum version, expected dates
Admissions	Linked cycles, seats, allotments, reporting, approvals, joining, and vacancy summary
Enrolment	Planned intake, joined candidates, programme enrolments, active members, and reconciliation differences
Phase progress	Current phase, previous and next phases, planned/actual dates, progression state, and delays
Academic readiness	Phase-plan, course-offering, clinical-posting, learner-group, and timetable status
Academic summary	Attendance, competency, logbook, and other available summaries
Exceptions	Blocking gaps, overdue decisions, failed handoffs, and unresolved amendments

Scope controls which dashboard the user may open. Functional access and field sensitivity control the detail shown inside it.

Screen 6: Amend or Cancel

The screen displays the current record, proposed change, reason, supporting evidence, impact, and approval route.

Impact analysis covers admission cycles, seats, allotments, joined candidates, programme enrolments, cohort memberships, phase plans, course offerings, postings, and schedules.

Screen 7: History

History shows creation, curriculum selection, readiness results, availability, admission links, amendments, handoffs, reconciliation, lifecycle changes, cancellation, and completion. It is read-only.

Use case 1: View cohorts within scope

As an authorised tenant, institute, department, or academic user
I want to see the cohorts within my permitted scope
So that I can reach the relevant cohort without seeing unrelated institutional data.

Acceptance criteria

Tenant Admin can navigate from institute to cohort summaries across the tenant.
Institute Admin and Academic Registrar can see all cohorts in the institute.
Department and faculty visibility is limited by current academic relationships and assignments.
Student access is limited to the student’s own cohort.
Sensitive student or admission fields require the relevant capability even when the cohort itself is visible.
Search results never include another tenant.

Use case 2: Create a planned cohort

As an Institute Admin or Academic Registrar
I want to create a cohort for an institute programme and intake
So that Admissions and academic planning have one agreed learner group to use.

Acceptance criteria

Institute, programme, cohort name/code, intake year, academic session, planned intake, and expected start date are recorded.
The institute programme belongs to the selected institute and is active.
The cohort code is unique inside the institute.
Planned intake is a positive whole number and is compared with the applicable approved intake.
A conflicting cohort for the same programme and intake is blocked or sent for explicit review.
A new cohort starts in Draft status and cannot yet be selected by Admissions.

Negative cases and alternate flows

Programme unavailable: Do not offer an inactive or out-of-scope programme.
Approved intake missing: Allow Draft save, but block availability to Admissions.
Possible duplicate: Show the existing cohort before another is created.
Insufficient scope: Do not permit creation for a sibling institute.

Use case 3: Assign the curriculum version

As an Institute Admin or Academic Registrar
I want to select the published curriculum version the cohort will follow
So that every learner and later academic plan uses the correct requirements.

Acceptance criteria

Only published curriculum versions owned by the selected institute programme are offered.
The version must apply to the cohort’s intake and expected start date.
The user can review phases, course placements, postings, duration, and progression requirements before confirmation.
Making the cohort available to Admissions pins the selected version.
Publishing a newer version does not alter this cohort.

Negative cases and alternate flows

No applicable version: Keep the cohort Draft and link to Curriculum Builder or Curriculum Versions.
Version withdrawn before availability: Require another applicable published version.
Enrolments already exist: Block direct curriculum replacement and require a controlled migration process.

Use case 4: Review cohort readiness

As an Institute Admin or Academic Registrar
I want to review cohort readiness
So that Admissions cannot select an incomplete or invalid cohort.

Acceptance criteria

The screen checks institute, programme, curriculum, intake, dates, authority relationships, duplicate cohorts, and required functional roles.
The screen resolves the applicable institute identifier policy and then the tenant fallback.
Every result identifies its owner and source record.
Blocking failures prevent availability.
Warnings require acknowledgement where policy allows the cohort to proceed.
Readiness is recalculated when a relevant source record changes.
The checked source versions and result are retained in history.

Use case 5: Make the cohort available to Admissions

As an Institute Admin, Academic Registrar, or required Cohort Approver
I want to make the ready cohort available to Admissions
So that it can be selected for the correct admission cycle programme.

Acceptance criteria

All blocking readiness checks pass at submission time.
The system records the actor, time, readiness version, and approval.
The status changes from Draft to Available for Admission.
The applicable Student Number policy version is pinned to the cohort.
Admissions can now select the cohort with its institute programme and pinned curriculum version.
Programme, intake, and curriculum become controlled fields.
Availability does not itself create an admission cycle, seat, candidate, or student.

Use case 6: Amend a planned cohort

As an Institute Admin or Academic Registrar
I want to correct an existing cohort through the permitted process
So that the record remains accurate without breaking dependent work.

Acceptance criteria

Ordinary Draft fields can be changed while no operational dependency exists.
A controlled change records the current value, proposed value, reason, evidence, impact, and approval.
Impact analysis includes Admissions, enrolments, and academic planning.
Programme and curriculum replacement are blocked after programme enrolments exist.
Approved changes create history and trigger readiness and dashboard recalculation.
Rejected changes leave the current cohort unchanged.

Use case 7: Cancel a cohort

As an authorised Institute Admin, Academic Registrar, or Cohort Approver
I want to cancel a cohort that will not proceed
So that it cannot receive new admission or academic records while its history remains available.

Acceptance criteria

Cancellation records reason, effective date, supporting evidence, and approval.
A Draft cohort with no dependencies can be cancelled directly by an authorised user.
Active admission links, joined candidates, enrolments, or academic plans block ordinary cancellation.
The blocking records and required resolution are shown.
A cancelled cohort cannot be selected for a new cycle programme.
The cohort is never physically deleted.

Use case 8: View admission and enrolment position

As an authorised tenant, institute, academic, or admission user
I want to compare the planned intake with admission and enrolment progress
So that missing handoffs or count differences are found early.

Acceptance criteria

The dashboard shows configured seats, allotments, reporting, approvals, joining, programme enrolments, active memberships, and vacancies where available.
Each count states its source module and last calculation time.
Users can open detailed candidate records only with the relevant Admissions capability.
A difference between joined candidates, programme enrolments, and cohort memberships is clearly identified.
Counts are calculated from source records and cannot be manually overwritten on the cohort.

Use case 9: Receive a student through admission handoff

As a Student Section Officer
I want to complete the handoff for an approved and joined candidate
So that the person receives one programme enrolment and one membership in the selected cohort.

Acceptance criteria

Admission approval and joining are rechecked at submission time.
The handoff creates or links the student profile.
It creates one programme enrolment using the cohort’s institute programme and pinned curriculum version.
It creates one active membership in the planned cohort.
Repeating the same handoff returns the existing result without duplication.
Failed work remains retryable and shows the exact incomplete step.
Cohort counts are refreshed after successful completion.

Use case 10: View the cohort dashboard

As an authorised user
I want to open one dashboard for the cohort
So that I can understand its current admission, enrolment, and academic position.

Acceptance criteria

The dashboard shows cohort identity, curriculum, status, counts, current phase, academic readiness, and exceptions.
Information is read from the module that owns it.
Tenant and institute users see only their permitted organisational scope.
Department and faculty users see only assigned academic detail.
Sensitive fields remain hidden without the required capability.
Every summary shows its last refresh time and links to its owning workspace where permitted.

Use case 11: View phase progression

As an authorised academic or administrative user
I want to see where the cohort is in its curriculum
So that upcoming work and delayed progression are visible.

Acceptance criteria

The dashboard shows curriculum phases in their defined order.
Planned dates, actual dates, phase state, progression decision, and exceptions come from Academic Planning and Delivery.
The cohort does not progress merely because a date has passed.
Progression actions are not performed from this epic.
Users can open the phase plan only when their academic access permits it.

Use case 12: View cohort history

As an Institute Admin, Academic Registrar, Cohort Approver, or Auditor
I want to review the complete cohort history
So that every material decision can be explained.

Acceptance criteria

History includes creation, curriculum selection, readiness, availability, admission links, amendments, handoffs, reconciliation, and lifecycle changes.
Every event identifies actor, time, reason, source, approval, and earlier/new value where applicable.
History is read-only.
Historical events retain the role and scope used at the time.
Export follows the viewer’s current access and field restrictions.

Business rules

A cohort belongs to one tenant, institute, institute programme, intake, and pinned curriculum version.
A cohort must exist before Admissions can reference it.
One admission cycle may contain many cycle programmes; each cycle programme selects its planned cohort.
Admission approval alone does not create cohort membership. Joining and enrolment handoff are required.
A published curriculum version is never edited through the cohort.
A newer curriculum version does not move an existing cohort automatically.
A later student-number policy does not move or renumber an existing cohort automatically.
Phase definitions come from the curriculum; actual phase dates and progression decisions come from Academic Planning and Delivery.
Scope allows navigation to the cohort, while capability, assignment, record state, and field sensitivity determine detailed access and actions.
Counts shown on the dashboard are derived from source records.
Operational cohorts and their history are never physically deleted.

Technical design

How the records relate

academic.institute_programme
└── academic.curriculum_version (published)
    └── student.cohort
        ├── admission.cycle_programme
        ├── student.cohort_membership
        │   └── student.programme_enrolment
        └── academic.cohort_phase_plan

The diagram shows references, not ownership. Admissions owns admission.cycle_programme; Academic Planning and Delivery owns academic.cohort_phase_plan.

Conceptual schema

Record	Important fields
`student.cohort`	tenant, institute, institute programme, curriculum version, code/name, intake year, academic session, planned intake, expected dates, status, row version
`student.cohort_identifier_policy`	cohort, identifier type, pinned policy version, resolution reason, pinned at
`student.cohort_readiness_result`	cohort, check code, result, blocking flag, source record/version, owner, checked at
`student.cohort_amendment`	cohort, proposed changes, reason, evidence, impact result, requester, approver, status, effective time
`student.cohort_state_event`	cohort, earlier/new state, actor, role grant, reason, source, timestamp
`admission.cycle_programme`	admission cycle, institute programme, cohort, curriculum version, intake included, status
`student.student_profile`	person, institute, source admission case, status
`student.programme_enrolment`	student, institute programme, curriculum version, admission case, start date, status
`student.cohort_membership`	programme enrolment, cohort, joined at, membership status
`student.student_identifier`	student, programme enrolment, identifier type, value, issuer, policy version, status, issued at
`academic.cohort_phase_plan`	cohort, curriculum stage, planned/actual dates, state, progression decision
`student.cohort_dashboard_projection`	cohort, source counts, current phase, warning summary, calculated at

Process-layer responsibilities

The process layer must:

enforce tenant and institute scope before returning a cohort;
apply capability, assignment, record-state, and field-level checks inside that scope;
validate institute programme, curriculum ownership, applicability, intake, and dates together;
prevent duplicate and conflicting cohorts;
calculate readiness from current authoritative records;
resolve and pin the applicable student-number policy version at availability;
lock controlled fields when dependent admission or enrolment records exist;
calculate amendment and cancellation impact before approval;
process enrolment handoff exactly once and support safe retry;
derive dashboard counts from authoritative modules and expose their calculation time;
obtain phase progress from the authorised cohort phase plan;
audit every material change and state transition.

Success outcome

Every intake has one clearly owned cohort, one pinned curriculum version, reliable admission and enrolment counts, scoped visibility, and a complete history that later academic modules can safely use.