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.
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 configuration |
| 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 Offerings, Requirements and Workflow, Assignments, and Activation History. Values inherited from the organisational hierarchy or approved master data 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 |
| Admission batch | Selected/created | Yes | Batch that successful candidates will enter |
| 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 offering fields
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Institution | Selected | Yes | Institution within the cycle owner’s permitted hierarchy |
| Programme offering | Selected | Yes | Active offering already defined for that institution |
| Department | Inherited | Conditional | Shown for department-associated offerings |
| Programme/speciality | Inherited | Yes | Read-only identity from the offering |
| Recognised intake | Inherited | Yes | Current approved intake from the programme offering |
| Intake included in cycle | Entered | Yes | Cannot exceed the recognised/permitted intake without approved evidence |
| Regulation version | Selected | Yes | Version to be assigned during enrolment handoff |
| Offering-specific cutoff | Entered | No | Requires authority evidence when different from the cycle default |
| Approval source | Entered/uploaded | Conditional | Required for intake or cutoff variation |
| Offering 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 configuration version |
System-derived information
The screen calculates configuration completeness, offerings 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, and default statutory cutoff.
- 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 programme offerings
As an Admission Nodal Officer
I want to add the programmes and specialities included in the cycle
So that every seat and candidate is attached to the correct institutional offering.
Acceptance criteria
- The Admission Nodal Officer selects an institution within the cycle owner’s permitted hierarchy.
- The Admission Nodal Officer selects a recognised programme offering and records the intake included in the cycle.
- The same institution, programme, and session combination cannot be added twice.
- PG and super-speciality offerings retain their speciality identity.
- Each offering can have an approved cutoff override only when supported by authority.
- Removing an unused draft offering is allowed; an offering with accepted seats or candidates cannot be deleted.
Negative cases and alternate flows
- Programme unavailable: Do not allow a programme that is inactive or not offered by the institution.
- 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 configuration.
Acceptance criteria
- Activation checks that offerings, cutoff, counselling processes, seat ownership, required roles, and checklists are complete.
- Activation records the approver, date, and configuration 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 configuration: 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.
Success outcome
An active cycle contains the approved institutional, programme, authority, deadline, requirement, and responsibility context needed for every later admission action.