Admission Cycles and Rules
Epic summary
The Admission Cycles and Rules epic establishes the operating context for admissions. A cycle brings together the academic session, programme family, participating institutions, counselling routes, statutory cutoff, requirements, and responsible officers.
Examples include MBBS Admissions 2026-27, PG Medical Admissions 2026-27, and Super-Speciality Admissions 2026-27.
No allotment can be accepted and no candidate can be admitted without an active cycle.
Before you start
The institute programme, published curriculum version, and planned cohort must already exist. Admissions selects these records; it does not create them. The planned cohort must belong to the same institute programme and must not already be assigned to another active admission route for the same intake.
Actors and access
| Actor | Access |
|---|---|
| Admission Nodal Officer | Creates and edits draft cycles |
| Directorate/University/Trust Admissions Officer | Defines shared templates and approves governed changes |
| Authorised Dean/Principal | Approves activation, closure, or controlled reopening where configured |
| Counselling Coordinator | Adds counselling-specific setup |
| Specialist officers | View the requirements relevant to their assigned work |
| Internal Auditor | Read-only access to versions and approvals |
Screen structure and data captured
The workspace contains Cycle Details, Cycle Programmes, Requirements and Workflow, Assignments, and Activation History. Values already defined in Setup are selected rather than retyped.
Cycle details
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Owning entity | Selected | Yes | Governance entity or institution within the user’s permitted hierarchy |
| Cycle name | Entered | Yes | Human-readable name, for example PG Medical Admissions 2026–27 |
| Cycle code | Entered/generated | Yes | Unique code within the owning entity |
| Academic session | Selected | Yes | Approved academic-session master |
| Programme family | Selected | Yes | UG, PG, super-speciality, PhD, or another configured family |
| Default statutory cutoff | Entered from source | Yes | Blocking admission cutoff with source authority |
| Governing notification | Entered/uploaded | Yes | Order number, date, issuing authority, and source document |
| Operational start and end | Entered | Yes | Period during which the cycle can be worked; cannot extend admission authority |
| Status | System controlled | Yes | Draft, Pending Approval, Active, Closed, or Reopened |
| Notes | Entered | No | Operational context; cannot replace source evidence |
Cycle programme fields
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Institution | Selected | Yes | Institution within the cycle owner’s permitted hierarchy |
| Institute programme | Selected | Yes | Active programme owned by that institute |
| Planned cohort | Selected | Yes | Existing planned cohort that successful candidates will join; cannot be created from Admissions |
| Department | Inherited | Conditional | Shown for programmes associated with a coordinating department |
| Programme/speciality | Inherited | Yes | Read-only identity from the institute programme |
| Recognised intake | Inherited | Yes | Effective approved intake recorded for the institute programme |
| Intake included in cycle | Entered | Yes | Cannot exceed the recognised/permitted intake without approved evidence |
| Curriculum version | Selected | Yes | Published institute curriculum version applicable to this intake and pinned during cohort/enrolment handoff |
| Programme-specific cutoff | Entered | No | Requires authority evidence when different from the cycle default |
| Approval source | Entered/uploaded | Conditional | Required for intake or cutoff variation |
| Cycle programme status | System controlled | Yes | Draft, Ready, Active, or Inactive |
Requirements and workflow fields
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Requirement name and code | Entered/selected | Yes | Identifies a document, eligibility rule, clearance, or declaration |
| Requirement type | Selected | Yes | Document, eligibility, finance, medical, programme, bond/legal, or declaration |
| Applies to | Rule builder | Yes | Programme, quota, category, domicile, sponsorship, or other condition |
| Requirement level | Selected | Yes | Mandatory, conditional, or informational |
| Responsible capability | Selected | Yes | Capability required to complete or decide it |
| Approval sequence | Entered | Conditional | Order or prerequisite when the workflow is sequential |
| Due stage | Selected | Yes | Before reporting, before decision, before joining, or before handoff |
| Source and effective version | Entered/uploaded | Yes | Authority, order, effective date, and setup version |
System-derived information
The screen calculates setup completeness, cycle programmes without seat pools, unassigned mandatory work, conflicting rules, cutoff conflicts, active candidate counts, and whether activation or closure is permitted.
Use case 1: Create an admission cycle
As an Admission Nodal Officer
I want to create an admission cycle for an academic intake
So that seats, rounds, and candidates are managed within the correct session.
Acceptance criteria
- The Admission Nodal Officer records a unique cycle name, academic session, programme family, owner entity, default statutory cutoff, and at least one planned cohort through its cycle programme.
- The Admission Nodal Officer identifies whether the cycle is UG, PG, super-speciality, or another supported family.
- The system prevents accidental duplication of the same cycle at the same owner entity.
- A new cycle starts in Draft status.
- Draft cycles are visible only to authorised users and cannot receive operational admission decisions.
- Creation is recorded in the audit trail.
Negative cases and alternate flows
- Missing academic session: Do not create the cycle.
- Duplicate cycle: Show the existing cycle and allow the user to open it.
- Cutoff before cycle start: Reject the date combination.
- Insufficient scope: A college user cannot create a cycle owned by an inaccessible parent or sibling entity.
Use case 2: Add institute programmes to the cycle
As an Admission Nodal Officer
I want to add the institute programmes and specialities included in the cycle
So that every seat and candidate is attached to the correct institute programme and curriculum version.
Acceptance criteria
- The Admission Nodal Officer selects an institution within the cycle owner’s permitted hierarchy.
- The Admission Nodal Officer selects an active institute programme, an existing planned cohort, a published curriculum version applicable to that cohort, and the intake included in the cycle.
- The planned cohort belongs to the selected institute programme and institute.
- The same planned cohort cannot be added twice or attached to conflicting active admission cycles.
- PG and super-speciality institute programmes retain their speciality identity.
- Each cycle programme can have an approved cutoff override only when supported by authority.
- Removing an unused Draft cycle programme is allowed; one with accepted seats or candidates cannot be deleted.
Negative cases and alternate flows
- Programme unavailable: Do not allow an institute programme that is inactive, owned by another institute, or lacks an applicable published curriculum version.
- Planned cohort unavailable: Do not create the cycle programme; link the user to Student and Cohort Management to create or correct the cohort.
- Existing operational records: Replace deletion with controlled deactivation and history.
- Intake mismatch: Flag a proposed intake that conflicts with the recognised or permitted intake.
Use case 3: Configure requirements and workflow
As an Admission Nodal Officer
I want to configure the admission requirements
So that every candidate is evaluated consistently.
Acceptance criteria
- The Admission Nodal Officer selects or creates a document checklist by programme and seat-pool conditions.
- The Admission Nodal Officer associates eligibility, fee, bond, medical, and programme-clearance requirements.
- The Admission Nodal Officer assigns the responsible capabilities and approval sequence.
- Requirements can specify whether they are mandatory, conditional, or informational.
- Rules inherited from an approved template show their source and cannot be silently changed.
- Every material change creates a new version with an effective date.
Negative cases and alternate flows
- Mandatory role unassigned: Prevent activation until an owner exists for every mandatory clearance.
- Conflicting requirements: Flag overlapping rules that produce incompatible outcomes.
- Change after candidates are processed: Require a new version and identify affected cases for review.
Use case 4: Activate, close, or reopen a cycle
As an Authorised Dean/Principal
I want to control the cycle’s operational state
So that admissions occur only under approved setup.
Acceptance criteria
- Activation checks that cycle programmes, planned cohorts, curriculum versions, cutoff, counselling processes, seat ownership, required functional role assignments, and checklists are complete.
- Activation records the approver, date, and setup version.
- Closing the cycle requires all rounds to be closed or formally excepted.
- A closed cycle is read-only for ordinary users.
- Reopening requires a reason, supporting authority, and the required higher-level approval.
- Reopening does not alter the statutory cutoff.
Negative cases and alternate flows
- Incomplete setup: List the exact blockers and keep the cycle in Draft.
- Open reconciliation: Prevent closure until unresolved rounds are addressed.
- Cutoff passed: Reopening may permit record correction but cannot permit a new admission after the cutoff.
Technical design
Conceptual schema
| Record | Important fields |
|---|---|
admission.admission_cycle | owner entity, code/name, academic session, programme family, operational dates, statutory cutoff, status, approval |
admission.cycle_programme | cycle, institute programme, planned cohort, curriculum version, included intake, cutoff override, status |
admission.requirement_version | cycle, version, effective date, source, status |
admission.requirement_rule | version, requirement type, applies-to condition, level, responsible capability, due stage |
admission.cycle_assignment | cycle, responsibility, user, scope, validity, status |
admission.cycle_state_event | cycle, earlier/new state, actor, reason, source, timestamp |
Process-layer responsibilities
- Validate institute programme, planned cohort, curriculum version, and institute ownership together.
- Prevent conflicting use of the same planned cohort.
- Compile requirement conditions into supported, explainable rules without accepting executable user code.
- Check cutoff, counselling, seats, functional role assignments, and checklists before activation.
- Version requirements after operational work has begun.
- Lock closed cycles and audit every controlled reopening.
Success outcome
An active cycle contains the approved institutional, programme, authority, deadline, requirement, and responsibility context needed for every later admission action.