Phase Progression Rules

Epic summary

The Phase Progression Rules workspace defines what a student must complete before moving from one phase of a curriculum to the next.

Progression is always defined as a transition:

Source phase -> Target phase

Phase I -> Phase II
Phase II -> Phase III Part I

The rule belongs to the curriculum version. It uses supported condition categories and explicit AND or OR groups. It never stores an unexplained formula or free-text instruction.

Phase I -> Phase II

ALL conditions must be satisfied:
  - First Professional MBBS final outcome is Passed
  - All required Phase I competencies are certified
  - All progression-required Phase I courses are complete
  - No unresolved progression blocker exists

Changing a published transition, condition, threshold, reference, or AND/OR structure requires a successor curriculum version.

Boundary with Assessment and Examination

Progression may require a final assessment outcome, but it does not define how that outcome is calculated.

Assessment definition: First Professional MBBS
Assessment and Examination: calculates or imports the final result
Progression condition: requires final outcome = Passed

Examination attendance eligibility, internal-assessment thresholds, pass marks, papers, attempts, and supplementary rules belong to Assessment and Examination. The progression rule references the resulting assessment outcome.

Before you start

A Draft curriculum version must exist.
Source and target phases must already be defined and ordered.
Courses, competencies, clinical-posting requirements, logbook structures, longitudinal requirements, and assessments referenced by the transition must already exist in the same curriculum version.
Any condition category used by a pack must be supported by the running MedCES release.
The user must have the Curriculum Committee Member, Academic Registrar, or another authorised curriculum role.

Actors and access

Access source	Access in this epic
Institute member with Curriculum Committee Member role	Creates transitions, conditions, groups, and source references in a Draft curriculum version
Institute member with Academic Registrar role	Coordinates authoring, reviews dependencies, runs simulations, and submits the curriculum version
Institute member with Assessment Coordinator role	Reviews assessment-outcome references without redefining assessment calculations here
Department Admin or authorised Faculty reviewer	Reviews conditions connected to assigned courses, competencies, or postings
Institute member with Dean or Principal role	Approves the curriculum version when required by the institute workflow
Auditor role	Reads rule structure, simulation, source, approval, and version history

Supported condition categories

The category determines which fields, operators, thresholds, and source records are available.

Assessment outcome

Defines an expected final result from an assessment already defined in the curriculum.

The user selects:

assessment definition;
required overall outcome;
whether the outcome must be final and published;
whether the result authority and evidence must be present.

The user does not enter marks or pass thresholds here.

Course completion

Defines completion of selected course placements or all course placements marked as required for this transition.

The user selects:

courses or a curriculum-defined course set;
required completion state;
all, count, or percentage requirement where supported;
treatment of incomplete or exempted courses.

Competency completion

Defines completion of competencies or a competency set.

The user selects:

competencies or a curriculum-defined set;
required proficiency or certification state;
count or percentage threshold where applicable;
required sign-off state;
whether only final, non-revoked evidence counts.

Clinical-posting completion

Defines completion of curriculum clinical-posting requirements.

The user selects:

posting requirements;
required completion state;
count, duration, or percentage threshold where applicable;
supervisor sign-off requirement.

This category reads posting completion. It does not schedule rotations.

Logbook completion

Defines completion and sign-off of a curriculum logbook or selected sections.

The user selects:

logbook or section set;
required completion percentage or count;
review and sign-off state;
treatment of rejected or expired evidence.

Longitudinal requirement completion

Defines completion of curriculum components that run across courses or phases, such as a foundation course, elective, family programme, or another named curriculum requirement.

The user selects the existing curriculum requirement and its required completion state.

Minimum phase training duration

Defines the minimum recognised time the student must spend in the source phase.

The user selects:

duration and unit;
recognised start and end events;
treatment of approved breaks or excluded periods;
rounding rule where needed.

Required academic decision

Defines an authoritative decision that must exist before progression, without recalculating that decision.

The user selects:

decision type;
required final outcome;
required authority;
finality and evidence requirements.

Unresolved academic blockers

Requires the number of selected open blockers to equal zero.

The user selects the blocker types, such as unresolved remediation, a result under review, incomplete compulsory evidence, or an open progression appeal.

New categories require tested application behaviour. A curriculum author cannot create a new evaluator by naming it in free text.

AND and OR logic

Every transition contains a condition tree.

AND means ALL conditions must be satisfied.
OR means ANY condition may be satisfied.

Example:

ALL conditions must be satisfied:

  1. First Professional MBBS final outcome is Passed

  2. Phase I competencies are 100% certified

  3. ANY condition may be satisfied:
       - Foundation Course is complete
       - Approved Foundation Course exemption exists

  4. Open progression blocker count equals 0

The builder supports nested groups only to a controlled depth so reviewers can understand the rule. Every group must show a generated plain-language explanation.

Evaluation results

Each condition produces one of three results:

Satisfied;
Not Satisfied; or
Unable to Evaluate.

Missing or unfinalised data never silently passes.

For an AND group:

one Not Satisfied child makes the group Not Satisfied;
if none fail but one cannot be evaluated, the group is Unable to Evaluate;
every child must be Satisfied for the group to be Satisfied.

For an OR group:

one Satisfied child makes the group Satisfied;
if none pass but one cannot be evaluated, the group is Unable to Evaluate;
every child must be Not Satisfied for the group to be Not Satisfied.

Screen structure and data captured

The workspace contains Transition Map, Transition Details, Condition Builder, Condition Editor, Simulation, Validation and Review, and History.

Screen 1: Transition Map

The map shows the ordered phases and their defined transitions.

Phase I -> Phase II -> Phase III Part I -> Phase III Part II -> Internship

Each transition shows:

condition count;
AND/OR group count;
assessment references;
definition completeness;
simulation position;
source and local-change state;
review warnings.

The map identifies a missing transition between consecutive phases. It does not create a transition automatically.

Screen 2: Transition Details

Field	Required	What the user defines
Curriculum version	Inherited	Draft curriculum being edited
Transition code	Yes	Stable code unique inside the curriculum version
Transition name	Yes	Plain name such as `Phase I to Phase II`
Source phase	Yes	Phase the student is completing
Target phase	Yes	Phase the student may enter
Description	Yes	What this transition establishes
Root logic	Yes	ALL or ANY; normally ALL
Student decision approval required	Yes	Whether runtime progression requires an authorised decision
Required decision role	Conditional	Academic Registrar, committee, Dean/Principal, or another supported functional role
Exceptional progression allowed	Yes	Whether an authorised exception route exists
Exception authority	Conditional	Required role and evidence where an exception is permitted
Source reference	Yes	Regulation, curriculum, university, or institute approval

Source and target phases must belong to the same curriculum version. A transition cannot point backwards unless the programme structure explicitly supports that route and the source documents justify it.

Screen 3: Condition Builder

The builder shows groups and cards rather than code.

Available actions are:

add condition;
add ALL group;
add ANY group;
move a condition within the allowed structure;
duplicate a Draft condition;
remove a Draft condition after impact review;
open the plain-language preview.

The display always shows the category, referenced curriculum item, operator, threshold or expected state, missing-data behaviour, and source.

Screen 4: Condition Editor

Every category starts with common fields:

Field	Required	What the user defines
Category	Yes	Supported evaluator type
Condition name	Yes	Human-readable name shown in evaluation results
Parent group	Yes	AND or OR group containing the condition
Referenced curriculum item	Conditional	Assessment, course set, competency set, posting, logbook, or other supported record
Comparator	Conditional	Equals, one of, greater than or equal, count equals, percentage at least, or another category-supported operator
Required value	Conditional	Outcome, state, count, percentage, or duration required
Unit	Conditional	Percentage, count, days, weeks, months, or another category-supported unit
Missing-data result	Yes	Normally Unable to Evaluate; restricted by category
Mandatory	Yes	Whether the condition participates in the progression result
Source reference	Yes	Source supporting this condition
Explanation	Yes	Plain description shown to reviewers and students where permitted

After the category is selected, only valid fields and operators are shown. For example, Assessment Outcome offers result values, while Minimum Phase Duration offers duration operators and units.

Screen 5: Simulation

Before publication, an authorised user can test the transition against:

manually entered test values;
one permitted existing student;
a selected cohort; or
source-pack test scenarios.

The result explains every condition:

First Professional MBBS
Required: Final outcome Passed
Actual: Passed
Result: Satisfied

Phase I competencies
Required: 42 certified
Actual: 40 certified
Result: Not Satisfied

Overall: Not Satisfied
Reason: Two required competencies remain incomplete

Simulation never creates a student progression decision or phase movement.

Screen 6: Validation and Review

Validation checks:

source and target phase ownership and order;
duplicate or missing transitions;
empty condition groups;
invalid nesting or circular references;
missing category-specific fields;
references outside the curriculum version;
unsupported operators, units, or evaluators;
missing assessment outcome contracts;
requirements that can never produce a final result;
pack-locked rules changed locally;
differences from the previous curriculum version.

Errors block curriculum submission. Warnings require an acknowledgement and reason where configured.

Screen 7: History

History shows transition creation, condition and group changes, references, thresholds, source changes, simulations, validation, review comments, approval, publication, and successor-version comparison. Published history is read-only.

Worked example: Phase I to Phase II

The curriculum author selects Phase I as the source and Phase II as the target. The root group is ALL.

The author adds:

Assessment Outcome — First Professional MBBS must have a final effective overall outcome of Passed.
Competency Completion — all competencies in Phase I Progression Competencies must be certified.
Course Completion — all Phase I course placements marked progression-required must be complete.
Unresolved Academic Blockers — selected open blocker count must equal zero.

The rule references definitions in the same Draft curriculum version. It does not contain the First Professional mark scheme or calculate the result.

Use case 1: View curriculum phase transitions

As an Academic Registrar or Curriculum Committee Member
I want to see every phase-to-phase transition
So that missing progression definitions are visible.

Acceptance criteria

The map shows phases in curriculum order and each defined transition.
Condition, group, assessment-reference, and validation counts are visible.
Users can open only records within their institute and curriculum access.
A phase-end examination is not treated as a transition unless a transition record exists.
Published transitions remain read-only.

Use case 2: Define a phase transition

As a Curriculum Committee Member
I want to connect one curriculum phase to the next
So that progression has a clear source and target.

Acceptance criteria

Source and target phases belong to the same Draft curriculum version.
Code, name, description, root logic, approval requirement, and source are recorded.
Duplicate active transitions between the same phases are blocked unless the curriculum explicitly supports named alternatives.
Backward or circular transitions are blocked unless supported by a defined programme route.
Creating the transition does not move any student.

Use case 3: Add a typed progression condition

As a Curriculum Committee Member
I want to add a condition from a supported category
So that the process layer knows exactly what to check.

Acceptance criteria

The selected category controls available references, operators, values, and units.
Referenced records belong to the same curriculum version.
Required category-specific fields must be complete before saving.
Unsupported evaluator behaviour cannot be entered as executable free text.
The saved card shows a generated plain-language statement.

Use case 4: Build AND and OR groups

As a Curriculum Committee Member
I want to organise conditions using explicit ALL and ANY groups
So that alternatives and mandatory combinations are unambiguous.

Acceptance criteria

Every transition has one root group.
A group uses either AND or OR.
Empty groups and excessive nesting are blocked.
Moving a condition shows the changed plain-language meaning before confirmation.
The stored tree preserves group, parent, operator, and sequence.

Use case 5: Reference an assessment outcome

As a Curriculum Committee Member
I want to require a final assessment outcome
So that phase progression consumes the authoritative result.

Acceptance criteria

Only assessments from the same curriculum version that permit progression use can be selected.
The user selects a supported expected outcome and finality requirement.
The condition does not expose mark or examination-eligibility fields.
A missing, pending, withheld, cancelled, or under-review result does not satisfy a Passed condition.
The assessment-definition identifier, not its display text, is stored.

Use case 6: Define a threshold condition

As a Curriculum Committee Member
I want to define an allowed count, percentage, state, or duration threshold
So that the completion requirement is measurable.

Acceptance criteria

Only threshold types supported by the selected category are offered.
Required value, comparator, unit, source, and rounding behaviour are explicit where applicable.
The preview explains the calculation and source records.
A threshold change in a published curriculum requires a successor version.
Missing data follows three-state evaluation and never silently passes.

Use case 7: Simulate a progression rule

As an Academic Registrar
I want to test the complete condition tree
So that errors are found before students depend on it.

Acceptance criteria

Simulation evaluates each leaf and group in order.
Required, actual, source, and result are shown for each condition.
Summary counts show Satisfied, Not Satisfied, and Unable to Evaluate.
Test runs are retained with the Draft review but create no student decision.
Changes after a test mark the earlier result as stale.

Use case 8: Validate and submit progression definitions

As an Academic Registrar
I want to validate every transition before curriculum review
So that incomplete or impossible rules are not published.

Acceptance criteria

Validation covers phase order, groups, references, category fields, outcome contracts, evaluators, sources, and simulation status.
Every error links to the exact transition, group, or condition.
Differences from the pack and previous curriculum version are visible.
Publication remains blocked while mandatory progression definitions are incomplete.
The validation snapshot is retained with the curriculum approval.

Business rules

Progression rules belong to the curriculum version; they do not have a separate business version.
A published progression change always requires a successor curriculum version.
Every progression rule moves from one defined phase to another defined phase.
Examination eligibility and result calculation are not progression conditions authored here.
An assessment condition references a defined assessment and consumes its final effective outcome.
Conditions use supported categories and typed fields, never user-authored code.
AND and OR relationships are stored explicitly.
Missing or unfinalised data produces Unable to Evaluate unless a supported category explicitly defines another safe result.
Simulation cannot create a student progression decision.
Runtime evaluation produces a recommendation; an authorised decision controls phase movement where approval is required.
A date passing never progresses a student automatically.

Technical design

How the records relate

academic.curriculum_version
├── academic.curriculum_stage
├── academic.assessment_definition
└── academic.curriculum_phase_transition
    └── academic.progression_condition_group
        ├── academic.progression_condition
        │   └── one category-specific condition record
        └── academic.progression_condition_group

Conceptual schema

Record	Important fields
`academic.curriculum_phase_transition`	curriculum version, code/name, from/to phase, description, root group, approval requirement/role, exception route, source
`academic.progression_condition_group`	transition, parent group, operator AND/OR, sequence
`academic.progression_condition`	group, category, name, comparator, required value/unit, missing-data result, mandatory state, sequence, source, explanation
`academic.progression_assessment_condition`	condition, assessment definition, required outcome, finality, authority/evidence requirements
`academic.progression_course_condition`	condition, course/set reference, required state, count/percentage rule, exemption treatment
`academic.progression_competency_condition`	condition, competency/set reference, proficiency/sign-off state, count/percentage rule
`academic.progression_posting_condition`	condition, posting/set reference, completion/sign-off state, count/duration/percentage rule
`academic.progression_logbook_condition`	condition, logbook/section reference, completion and sign-off rule
`academic.progression_longitudinal_condition`	condition, curriculum requirement reference, required completion state
`academic.progression_duration_condition`	condition, phase, duration/unit, recognised dates, exclusion and rounding rule
`academic.progression_decision_condition`	condition, decision type, required outcome/authority/finality
`academic.progression_blocker_condition`	condition, blocker types, required open count

The common condition stores its place in the logical tree. Typed extension records keep category fields explicit rather than hiding executable behaviour in arbitrary JSON.

Process-layer responsibilities

The Setup process layer must:

enforce institute and curriculum-version ownership on phases and every referenced definition;
expose category-specific fields, operators, values, and units;
validate the AND/OR tree, nesting depth, sequence, and circular references;
validate the assessment outcome contract before allowing an assessment reference;
generate a plain-language explanation for every condition and group;
run three-state simulation without creating operational decisions;
reject unsupported evaluators or pack requirements;
calculate dependency impact before a Draft item is changed or removed;
keep published definitions immutable and copy them safely into successor versions.

Runtime student evaluation and phase movement belong to Student and Cohort Management.

Success outcome

Every phase-to-phase movement has a published, version-specific and human-readable condition tree that MedCES can evaluate from authoritative academic records without duplicating assessment rules or hiding logic in code-like text.