Student and Cohort Management Data Model

Purpose

This page defines the stable records owned by Student and Cohort Management and the records it references from Setup, Admissions, and Academic Planning and Delivery.

Ownership map

Institute programme                         Setup
└── Published curriculum version            Setup
    └── Cohort                              Student and Cohort Management
        ├── Programme enrolments            Student and Cohort Management
        │   └── Cohort memberships          Student and Cohort Management
        ├── Admission cycle-programme link  Admissions
        └── Dated phase plans               Academic Planning and Delivery

The cohort stores the selected curriculum version. It does not copy or own the curriculum definition.

Core records

Record	Purpose
`student.cohort`	Represents one institute programme intake following one pinned curriculum version
`student.cohort_readiness_result`	Stores each readiness check and its outcome
`student.cohort_amendment`	Records a controlled proposed change and its approval
`student.cohort_state_event`	Preserves every lifecycle transition
`student.student_profile`	Represents the person as a student of an institute
`student.programme_enrolment`	Connects a student to an institute programme and curriculum version
`student.cohort_membership`	Connects one programme enrolment to its cohort
`student.student_identifier`	Stores an issued institute student number and the policy version that produced it
`student.university_registration`	Records university submission and registration identifiers
`student.enrolment_lifecycle_policy`	Defines versioned transition, evidence, approval, duration, and reporting rules for an applicable programme and batch
`student.enrolment_lifecycle_request`	Records a proposed programme-enrolment change before it becomes effective
`student.enrolment_rule_result`	Preserves each regulatory and institutional check performed for a request
`student.enrolment_lifecycle_approval`	Records the required review and approval decisions
`student.enrolment_state_event`	Preserves every effective programme-enrolment state change
`student.enrolment_external_report`	Tracks required submissions and acknowledgements after a lifecycle decision
`student.enrolment_appeal`	Links an appeal and its outcome to the original lifecycle decision
`student.student_phase_assignment`	Records the curriculum phase currently assigned to a programme enrolment
`student.progression_evaluation`	Stores one version-specific evaluation of a student against a curriculum transition
`student.progression_condition_result`	Preserves required, actual, source, and result for every transition condition
`student.progression_decision`	Records the authorised Progress, Hold, exception, correction, or defer decision
`student.cohort_movement`	Preserves an approved academic movement between cohort memberships

Cohort record

The cohort is institute-owned and belongs to one institute programme.

Field	Meaning
`tenant_id`	Tenant boundary used for isolation
`institute_id`	Institute that owns the cohort
`institute_programme_id`	Programme followed by the cohort
`curriculum_version_id`	Published curriculum version pinned to the cohort
`code`, `name`	Unique and human-readable cohort identity
`intake_year`, `academic_session_id`	Intake and academic-session context
`planned_intake`	Intended number of learners, checked against approved intake
`expected_start_date`	Intended cohort start
`expected_completion_date`	Optional expected completion date
`status`	Draft, Available for Admission, Active, Completed, or Cancelled
`available_for_admission_at`	Time at which Admissions may select the cohort
`row_version`	Prevents one editor from overwriting another editor’s change

The curriculum version must belong to the selected institute programme, be published, and apply to the cohort’s intake. The pinned student-number policy is stored separately in student.cohort_identifier_policy. Once the cohort is available to Admissions, the programme, intake, curriculum, and policy relationships are controlled.

Admission relationship

The admission cycle does not sit under the cohort, and the cohort does not sit under the admission cycle.

admission.admission_cycle
└── admission.cycle_programme
    ├── academic.institute_programme
    ├── student.cohort
    └── academic.curriculum_version

One admission cycle can contain several cycle programmes. Each cycle-programme record selects the cohort that successful candidates will join. Counselling authorities, seat pools, and rounds remain beneath the admission cycle.

Enrolment relationship

A candidate is not added to the cohort merely because admission is approved. The relationship is created after joining is confirmed.

Approved and joined admission case
  -> student.student_profile
  -> student.programme_enrolment
  -> student.cohort_membership
  -> student.student_identifier

The handoff must be safe to retry. Repeating it must return the existing records rather than create duplicates.

The student number is generated from the policy version pinned to the cohort. The programme, curriculum, cohort, and policy are inherited during ordinary handoff and are not separately selected by the officer.

Programme-enrolment lifecycle relationship

The programme enrolment stores the current state for ordinary reading. The state-event history remains the authoritative explanation of how that state changed.

student.programme_enrolment
├── student.enrolment_lifecycle_request
│   ├── rule results
│   ├── evidence
│   ├── approvals
│   ├── impact snapshot
│   ├── external reports
│   └── appeal
└── student.enrolment_state_event

The ordinary enrolment states are Active, On Approved Break, Withdrawn, Discontinued, Transferred Out, Superseded, Completed, and Cancelled. The applicable versioned policy decides which states and transitions are available for a specific programme and admission batch.

Academic hold-back, repeat, remediation, competency completion, and phase progression remain in their academic records. They do not directly update the programme-enrolment state.

An approved lifecycle request records both its effective time and its recorded time. A later reversal creates another linked event instead of deleting or rewriting the earlier event.

Curriculum and phase relationship

The curriculum version defines reusable stages such as Phase I or Phase II. The cohort does not store these stages again as editable definitions.

Academic Planning and Delivery creates the actual dated plans:

academic.curriculum_stage
  -> academic.cohort_phase_plan
      -> planned and actual dates
      -> phase status

The cohort phase plan describes dated delivery for the cohort. An individual student’s current phase is stored separately in student.student_phase_assignment.

student.programme_enrolment -> pinned curriculum version
student.student_phase_assignment -> current curriculum stage

published academic.curriculum_phase_transition
  -> student.progression_evaluation
      -> student.progression_condition_result
      -> student.progression_decision
          -> next student_phase_assignment
          -> optional student.cohort_movement

The evaluation reads the exact transition and condition tree from the student’s pinned curriculum version. The curriculum definition is not copied into an editable student rule.

A date passing does not progress a cohort or student. A Ready evaluation also does not move the student until the required decision is recorded and applied.

Held-back student relationship

A held-back student normally retains:

an Active programme enrolment;
the same pinned curriculum version;
the current phase assignment until a later decision; and
complete earlier cohort membership and academic history.

If the student must attend delivery with another cohort, student.cohort_movement links the earlier and new memberships. The move does not copy or delete earlier course, posting, attendance, competency, logbook, assessment, or decision records.

Counts and dashboard projections

The following values are calculated from their source records rather than manually maintained on the cohort:

seats configured;
candidates allotted, reported, approved, and joined;
programme enrolments created;
active cohort members;
current phase;
course-offering and clinical-posting readiness;
attendance and competency summaries.

A read-optimised dashboard projection may cache these values, but the source module remains authoritative.

Lifecycle rules

A Draft cohort can be edited by an authorised user.
Available for Admission means the cohort may be selected by Admissions.
A cohort must pin an applicable published student-number policy before it becomes available to Admissions.
A cohort with operational admission links cannot be deleted.
Programme or curriculum changes are blocked after programme enrolments exist.
Active means the cohort has begun its academic lifecycle through an authorised action.
Completed requires the applicable academic completion decision.
Cancelled records remain visible in history.
Historical memberships, admission links, and phase plans are never removed when a cohort closes.

Programme-enrolment lifecycle rules

An enrolment state cannot be edited directly.
Every state change requires a request, resolved policy version, evidence, approval route, effective date, and state event.
Academic Registrar is the primary functional role for lifecycle services within an institute.
Sensitive changes may require a separate Dean or Principal approval according to the applicable policy.
Withdrawal and institute-initiated discontinuation remain separate decisions.
Migration is offered only where the applicable programme rules permit it.
Resumption from an approved break and readmission after a closed enrolment remain separate processes.
An expressly approved programme or curriculum change creates a linked successor enrolment instead of rewriting the earlier enrolment.
A lifecycle exit does not automatically return a seat to Admissions.
Programme completion requires all configured compulsory requirements, including internship where applicable.
Current state, cohort membership, reporting work, and access effects are updated without deleting historical records.

Academic progression rules

The student’s pinned curriculum version determines the phase transition and condition tree.
Evaluation uses Satisfied, Not Satisfied, and Unable to Evaluate results.
Missing or unfinalised academic facts never count as satisfied.
Evaluation and authorised progression decision are separate records.
Ready to Progress does not automatically create a phase assignment.
Hold-back normally leaves the programme enrolment Active.
A cohort move cannot silently change the programme or curriculum version.
Exceptional progression is available only where the published transition defines an exception route.
Earlier evaluations, decisions, assignments, movements, and reversals remain immutable.

Process-layer responsibilities

The process layer must:

enforce tenant and institute ownership on every cohort query;
validate programme, curriculum version, intake approval, and cohort dates together;
prevent duplicate cohorts for the same institute programme and intake where they would conflict;
calculate readiness before making a cohort available to Admissions;
lock controlled fields when admission or enrolment records depend on them;
provide impact analysis before amendment or cancellation;
create student, enrolment, and membership records exactly once during admission handoff;
allocate the student number from the cohort’s pinned policy exactly once;
resolve and pin the applicable programme-enrolment lifecycle policy for every lifecycle request;
enforce transition, evidence, duration, approval, separation-of-duty, and reporting rules;
append the enrolment state event and update the current-state projection atomically;
keep academic progression facts separate and read them only from their owning records;
resolve the phase transition from the programme enrolment’s pinned curriculum version;
evaluate typed conditions and AND/OR groups from final source records up to a clear cutoff;
retain required, actual, source, finality, and explanation for every condition result;
enforce progression decision and exception approval routes;
apply phase assignments and cohort movements atomically and exactly once;
derive dashboard counts from authoritative modules;
apply field-level restrictions to sensitive student information;
retain an immutable history of lifecycle and material changes.