Identifier Policies and Number Builder

Epic summary

The Identifier Policies and Number Builder workspace defines how MedCES issues internal student numbers.

A tenant can publish a default policy. An institute can publish an override when its numbering convention is different.

Applicable institute policy
  -> otherwise applicable tenant policy
  -> otherwise no automatic number can be issued

For example, a tenant may define:

{INSTITUTE_CODE}-{PROGRAMME_CODE}-{INTAKE_YEAR}-{SEQUENCE:4}

The generated student number could be:

GMCN-MBBS-2026-0001

An institute override could instead define:

{INTAKE_YEAR}/{PROGRAMME_CODE}/{SEQUENCE:3}

which generates:

2026/MBBS/001

Before you start

• The tenant must exist before a tenant policy can be created.
• The institute must exist before an institute override can be created.
• Institute and programme codes used by the template must already be defined.
• The user must be authorised to manage identifier policies at the selected scope.
• An institute override must identify the tenant policy it replaces, where one exists.

Actors and access

Access source	Access in this epic
Tenant Admin	Creates and publishes tenant-wide default policies
Institute Admin	Creates institute overrides and views the effective institute policy
Institute member with Identifier Policy Manager role	Prepares and tests policies within the granted scope
Institute member with Student Records Officer role	Reviews whether a proposed format supports student operations
Institute member with Identifier Policy Approver role	Approves publication and controlled replacement where configured
Auditor role	Reads policy versions, tests, approvals, sequence events, and issued-number history

What this epic generates

This epic generates only the institute’s internal Student Number. It does not generate or overwrite:

• counselling candidate identifiers;
• application numbers;
• NEET roll numbers;
• university registration numbers;
• examination roll numbers;
• government identity numbers.

Those values are issued by their owning systems and stored separately.

Screen structure and data captured

The workspace contains Policy Directory, Policy Details, Number Builder, Sequence Rules, Preview and Validation, Publication, and History.

Screen 1: Policy Directory

The directory shows the policies visible at the user’s scope.

Each row shows:

• identifier type;
• tenant or institute scope;
• applicability;
• generation mode;
• current version;
• effective period;
• status;
• whether the policy is inherited or locally overridden.

An institute user can see the institute override and the tenant policy that would apply if the override did not exist.

Screen 2: Policy Details

Field	Required	Meaning and validation
Identifier type	Yes	Initially Student Number; fixed once the policy is published
Owning scope	Yes	Tenant or institute within the user’s authority
Policy name and code	Yes	Unique and stable inside the owning scope
Applies to	Yes	All programmes or an explicitly supported programme category
Generation mode	Yes	Automatic or Controlled Manual Entry
Uniqueness scope	Yes	Tenant or institute; cannot be narrower than the applicable policy allows
Effective from/to	Yes/No	Period during which the policy may be selected for a cohort
Replaced policy	Conditional	Required for an institute override or successor version where applicable
Approval source	Conditional	Institutional order or policy evidence where required
Status	System controlled	Draft, Under Review, Published, Retired, or Rejected

Screen 3: Number Builder

The user creates the format by selecting controlled variables and separators. The builder does not accept executable expressions or user-written code.

Supported variables initially include:

Variable	Example value
{TENANT_CODE}	DMER-MH
{INSTITUTE_CODE}	GMCN
{PROGRAMME_CODE}	MBBS
{INTAKE_YEAR}	2026
{ACADEMIC_SESSION}	2026-27
{COHORT_CODE}	MBBS26
{SEQUENCE:4}	0001

The user may also select supported prefixes, suffixes, separators, letter case, and zero padding.

The builder immediately shows a plain-language explanation of the format and an example result.

Screen 4: Sequence Rules

Field	Required	Meaning and validation
Starting value	Yes for automatic mode	First number available to the sequence
Padding length	Yes for automatic mode	Minimum displayed digits
Partition	Yes for automatic mode	One sequence per tenant, institute, programme, intake year, cohort, or supported combination
Reset rule	Yes	Never, intake year, academic session, or another supported boundary
Exhaustion behaviour	Yes	Block issuance and alert; never wrap silently
Manual pattern	Conditional	Required in manual mode to validate permitted values

Sequence rules must be understandable from the preview. A change that could create the same value in two partitions is blocked.

Screen 5: Preview and Validation

The user selects realistic sample values and asks MedCES to generate examples.

The screen shows:

• the first several values;
• results at a sequence boundary;
• maximum possible length;
• unsupported or empty variables;
• possible collisions with current policies or issued identifiers;
• whether the uniqueness scope can be enforced;
• how the next cohort would resolve the policy.

Previewing never reserves or consumes a number.

Screen 6: Publication

The publication screen shows the complete format, sequence rules, applicability, override relationship, test results, affected future cohorts, and approval route.

Publishing creates an immutable policy version. Later changes create a successor version.

Screen 7: History

History shows drafts, test results, review decisions, publication, effective dates, cohort policy resolution, sequence reservations, issued identifiers, retirement, and replacements. It is read-only.

Use case 1: View the effective student-number policy

As a Tenant Admin, Institute Admin, Identifier Policy Manager, or Student Records Officer
I want to see which policy applies at a tenant or institute
So that I know how future student numbers will be created.

Acceptance criteria

• The screen shows both the selected effective policy and the fallback policy.
• An applicable published institute policy takes priority over the tenant policy.
• The reason for the selected policy is shown in plain language.
• Draft, future, expired, and retired versions are not treated as current.
• Users cannot see policies outside their tenant or institute scope.

Use case 2: Create a tenant default policy

As a Tenant Admin or tenant-scoped Identifier Policy Manager
I want to define the default student-number policy
So that institutes can follow a consistent numbering convention.

Acceptance criteria

• Identifier type, policy code/name, applicability, mode, uniqueness scope, effective period, and source are recorded.
• Only one published default with the same applicability can be effective for the same period.
• The policy remains Draft until its format and sequence tests pass.
• Creating the policy does not change existing student numbers.

Use case 3: Create an institute override

As an Institute Admin or institute-scoped Identifier Policy Manager
I want to define an institute-specific policy
So that the institute can follow its approved local numbering convention.

Acceptance criteria

• The override belongs to one institute.
• The screen shows the tenant policy being replaced.
• The override contains a complete format and sequence configuration; it does not silently merge fragments with the tenant policy.
• Its uniqueness scope is compatible with existing identifiers.
• Other institutes continue using their own effective policies.

Use case 4: Build the number format

As an Identifier Policy Manager
I want to assemble the student-number format from supported variables
So that the result is predictable and safe to generate.

Acceptance criteria

• Variables are selected from a controlled catalogue.
• Separators, prefixes, suffixes, case, and padding are stored as typed settings.
• Unsupported variables and executable expressions are rejected.
• Automatic mode requires exactly one sequence component.
• Required source values are identified before publication.
• The screen explains the resulting format with examples.

Use case 5: Configure sequence allocation

As an Identifier Policy Manager
I want to define where the sequence starts and when it resets
So that numbers remain unique under the institute’s convention.

Acceptance criteria

• Starting value, padding, partition, reset rule, and exhaustion behaviour are explicit.
• Sequence partitions use supported fields and cannot be free text.
• The system detects configurations that could issue the same value twice.
• Issued numbers are never recycled.
• Concurrent requests are allocated atomically.

Use case 6: Test and preview the policy

As an Identifier Policy Manager or Student Records Officer
I want to test the proposed policy with realistic cohort data
So that errors are found before student numbers are issued.

Acceptance criteria

• Preview displays several consecutive examples and boundary cases.
• Missing source values and excessive length are reported clearly.
• Collision checks include issued identifiers and overlapping published policies.
• Preview does not consume a sequence value.
• The test inputs and results are retained with the review.

Use case 7: Publish a policy version

As an Identifier Policy Approver or other authorised approver
I want to publish a tested policy
So that future cohorts can use it.

Acceptance criteria

• Required tests pass at submission time.
• The approver sees format, sequence, scope, applicability, effective dates, and affected future cohorts.
• Publication creates an immutable version.
• Existing issued student numbers remain unchanged.
• Cohorts already pinned to another version do not move automatically.

Use case 8: Resolve and pin the policy for a cohort

As an Institute Admin or Academic Registrar
I want to confirm the applicable policy while preparing a cohort
So that every student in that cohort follows the same numbering convention.

Acceptance criteria

• MedCES first checks for an applicable published institute policy and then the tenant policy.
• The policy is checked against the cohort’s institute, programme, intake, and expected start date.
• The selected version is shown during cohort readiness.
• Making the cohort Available for Admission pins the policy version.
• A missing applicable policy blocks availability unless a published Controlled Manual Entry policy applies.

Use case 9: Configure controlled manual entry

As an authorised Identifier Policy Manager
I want to define a manual-entry policy where numbers are issued outside MedCES
So that externally issued student numbers are still validated and audited.

Acceptance criteria

• Manual mode defines an allowed pattern, length, and uniqueness scope.
• The source authority and evidence requirement are recorded.
• Every entered number is checked for uniqueness.
• Manual entry requires the configured capability and reason.
• MedCES does not maintain an automatic sequence for this policy.

Use case 10: Replace or retire a policy

As an authorised Tenant Admin, Institute Admin, or Identifier Policy Approver
I want to end a policy and publish its successor
So that future cohorts use the new convention without renumbering existing students.

Acceptance criteria

• The current version remains immutable.
• The successor has its own effective date and complete configuration.
• Overlapping effective periods with the same applicability are blocked.
• Pinned cohorts and issued identifiers remain connected to the earlier version.
• Retirement cannot free issued numbers for reuse.

Use case 11: View policy and allocation history

As an authorised administrator or Auditor
I want to trace how a student number was produced
So that the identifier can be explained and verified.

Acceptance criteria

• History shows the policy version, resolved variables, sequence partition, allocated value, cohort, enrolment, actor, and time.
• Failed allocation attempts are retained without presenting an unissued value as active.
• History cannot be edited.
• Sensitive student references follow current access rules.

Business rules

• Tenant policy is the fallback; an applicable institute override takes priority.
• A policy version is immutable after publication.
• A cohort pins one applicable policy version when it becomes Available for Admission.
• Policy changes affect future cohorts and never renumber existing students automatically.
• Preview does not consume a number.
• Issued or reserved numbers are never recycled.
• Automatic allocation must be atomic and safe under concurrent enrolments.
• Gaps are permitted when necessary to prevent reuse or unsafe rollback.
• A student number is distinct from all externally issued candidate, university, examination, and government identifiers.
• User-authored executable code is never accepted by the number builder.

Technical design

Conceptual schema

Record	Important fields
setup.identifier_policy	identifier type, owner entity, applicability, generation mode, uniqueness scope, status
setup.identifier_policy_version	policy, version, template, effective dates, source, approval, published at
setup.identifier_policy_component	policy version, order, component type, variable code, literal, formatting settings
setup.identifier_sequence_definition	policy version, starting value, padding, partition fields, reset rule, exhaustion rule
setup.identifier_sequence_counter	sequence definition, partition key, next value, row version
student.cohort_identifier_policy	cohort, identifier type, pinned policy version, resolution reason, pinned at
student.student_identifier	student, programme enrolment, identifier type, value, issuer entity, policy version, status, issued at
audit.identifier_allocation_event	policy version, partition, reserved value, enrolment, outcome, actor, timestamp

Process-layer responsibilities

The process layer must:

• resolve institute override before tenant fallback using current published versions;
• parse only supported typed components and reject executable expressions;
• validate required variables, length, character rules, applicability, and effective dates;
• detect overlapping policies and possible collisions before publication;
• preview without changing a sequence counter;
• pin the resolved policy version to the cohort at availability;
• allocate a sequence value atomically and enforce the configured uniqueness scope;
• make enrolment retry return the already issued identifier;
• prevent reuse after cancellation, failure, retirement, or correction;
• retain the policy version and resolved inputs used for every issued number.

Success outcome

Every student number follows an approved tenant or institute convention, remains unique, can be traced to the exact policy version that generated it, and never changes merely because a later policy is published.