Curriculum Builder

Epic summary

The Curriculum Builder is where an institute defines exactly what learners must study and complete under one curriculum version.

The builder works with institute-owned records:

Institute programme: MBBS
  -> Curriculum: MBBS Curriculum
      -> Version: CBME 2024
          -> Stages
          -> Institute courses placed in stages
          -> Competencies
          -> Clinical postings
          -> Assessment definitions
          -> Phase-to-phase progression rules

A programme pack normally creates the first Draft version. The academic team reviews the pack content, completes local information, adds allowed institute content, validates the result, and sends it for approval.

The pack states what the curriculum requires. The process layer understands how supported requirements behave. Neither the pack nor the builder schedules a named learner, teacher, room, or date.

Before you start

The institute programme and the courses needed by the curriculum must exist. A pack-installed curriculum requires a completed pack installation. Locally authored curricula require approved source documents. Departments may be confirmed later in Curriculum Delivery Setup, but each selected course must already have a valid lead department before the curriculum can be published.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Creates the curriculum version, coordinates authoring, and submits it for review
Institute member with Curriculum Committee role	Defines and reviews stages, courses, competencies, requirements, and progression
Department Admin, normally with HOD appointment	Reviews content and requirements for assigned departments
Institute member with Assessment Coordinator role	Reviews assessment structures and completion conditions
Institute member with Curriculum Approver role	Approves publication of the curriculum version
Auditor role	Views sources, local changes, validation, approvals, and version history

How the builder is organised

The builder is a guided workspace with nine steps:

Curriculum Version Details
Stage Builder
Curriculum Map
Competency Library
Clinical Postings and Standalone Requirements
Other Completion Requirements
Assessment Definitions
Phase Progression Rules
Validation and Review

The left side shows the steps and completion state. The main area edits the selected item. A source panel shows the relevant regulation or approval beside the form.

Step 1: Curriculum Version Details

The user defines the identity and applicability of this institute curriculum version.

Field	Required	What the user defines
Institute programme	Yes	Programme inside the same institute
Curriculum name	Yes	Stable name, such as `MBBS Curriculum`
Version name	Yes	For example, `CBME 2024 - Institute Version 1`
Version code	Yes	Institute-unique code
Based on pack	Inherited/No	Pack key and version when created from a pack
Previous version	No	Earlier institute curriculum version, where this is a successor
Applicable admission batches	Yes	Admission year or range that may select this version
Effective date	Yes	Date from which it may be used
Source authority	Yes	Regulator, university, or local academic authority
Source documents	Yes	Curriculum, regulation, corrigendum, or local approval
Change summary	Conditional	Required for a successor or locally revised version
Status	Yes	Draft, Under Review, Approved, Published, Superseded, or Archived

Applicability controls which version can be selected for a new cohort. It never changes an existing cohort automatically.

Step 2: Stage Builder

The Stage Builder defines the ordered academic structure. A stage may be a phase, professional year, residency year, semester, rotation period, or research milestone.

What the user sees

The user works with an ordered tree and can add, rename, move, or nest Draft stages.

MBBS CBME 2024
├── Phase I
├── Phase II
├── Phase III Part I
├── Phase III Part II
└── Compulsory Rotating Medical Internship

Stage fields

Field	Required	What the user defines
Stage code	Yes	Stable code within this curriculum version
Stage name	Yes	Formal name from the applicable curriculum
Local display name	No	Institute-friendly label without changing the formal name
Stage type	Yes	Phase, professional year, semester, residency year, internship, milestone, or another supported type
Parent stage	No	Used only when the curriculum contains nested stages
Sequence	Yes	Order among stages with the same parent
Duration	Yes	Number and unit, such as 12 months
Overlap allowed	Yes	Whether this stage may overlap another stage
Examination at end	Yes	Whether a formal examination closes the stage
Progression approval required	Yes	Whether learners need an explicit decision before moving forward
Source reference	Yes	Page, section, table, or institute approval supporting the stage

What MedCES validates

stage codes are unique in the curriculum version;
sequence is complete and unambiguous;
durations use supported units;
nested stages fit inside their parent;
overlap is allowed only when explicitly defined;
the total structure is consistent with the programme duration or has an explained exception;
stages referenced by courses or rules cannot be removed without impact review.

The process layer does not contain fixed MBBS phase names. The pack supplies them. A different programme may use a completely different stage pattern.

Step 3: Curriculum Map

The Curriculum Map places institute courses into stages.

The same institute course can appear in more than one stage and in more than one curriculum version. Each placement is a curriculum course.

Add a course to a stage

The user selects a stage, then chooses a published institute course.

Field	Required	What the user defines
Institute course	Yes	Course from the institute Course Catalogue
Stage	Yes	Stage in this curriculum version
Parent curriculum course	No	Used for a module nested under a broader course
Mandatory status	Yes	Mandatory, elective, optional, or remedial
Sequence	Yes	Display and delivery order inside the stage
Longitudinal	Yes	Whether it continues across several stages
Credits	No	Credits where the governing curriculum uses them
Completion basis	Yes	Participation, competency completion, assessment, combined rule, or another supported basis
Source reference	Yes	Source for this placement and requirement

For a longitudinal course, the user selects all applicable stages and defines either one overall completion rule or stage-level milestones.

Define how the course must be delivered

After placing the course, the user adds its required delivery components. These components describe how the course is taught under this curriculum version. They are not entered again for every cohort.

Field	Required	What the user defines
Component type	Yes	Lecture, practical, tutorial, small-group learning, self-directed learning, field activity, or another supported type
Required amount	Yes	Required hours or number of sessions
Default session duration	Conditional	Normal duration used when sessions are prepared for scheduling
Audience mode	Yes	Full cohort, each learning group separately, selected groups together, or another supported mode
Learning-group type	Conditional	Practical group, tutorial group, or another group type required by the component
Teaching method	Yes	Large-group teaching, demonstration, laboratory work, dissection, discussion, simulation, or another supported method
Required facility capability	Conditional	Lecture hall, dissection hall, laboratory, skills lab, or another capability rather than a named room
Competency coverage	No	Competencies normally taught through this component
Sequence or distribution rule	No	Required order, spread, or other source-defined delivery condition
Source reference	Yes	Pack, regulation, university direction, or approved institute source

For example, the Anatomy placement in Phase I may contain:

Lecture     40 hours   Full cohort       Lecture hall
Dissection  60 hours   Practical groups  Dissection hall
Histology   20 hours   Practical groups  Histology laboratory
Tutorial    10 hours   Tutorial groups   Tutorial room

The Curriculum Builder shows required totals by course, component, and stage. It does not choose actual groups, faculty, rooms, dates, or weekdays. Those operational choices are made for the cohort course offering.

Curriculum map view

The screen can be viewed by:

stage;
course;
department;
mandatory or elective status;
longitudinal component;
teaching method;
unresolved requirement.

It shows totals by stage and warns when required hours or course coverage do not match the source pack.

Step 4: Competency Library

The Competency Library stores the competencies that apply to this curriculum version. Competencies may come from the pack or be approved local additions.

Competency fields

Field	Required	What the user defines
Competency code	Yes	Authority or institute code unique within the version
Competency statement	Yes	Clear description of what the learner must know or do
Related curriculum course(s)	Conditional	One responsible placement and optional contributing placements where the competency is course-based
Applicable stage(s)	Yes	Stage in which teaching or completion is expected
Domain	Yes	Knowledge, skill, attitude, communication, professionalism, or another controlled domain
Required proficiency	Yes	Supported proficiency level or entrustment level
Core status	Yes	Core, non-core, elective, or enrichment
Teaching methods	Yes	Lecture, small group, demonstration, simulation, bedside teaching, self-directed learning, or other supported methods
Assessment methods	Conditional	Written, oral, practical, observed, workplace-based, portfolio, or another supported method
Completion method	Yes	Teaching exposure, assessment, faculty observation, repeated performance, logbook evidence, or a supported combination
Direct observation required	Yes	Whether completion needs observed performance
Certification required	Yes	Whether evidence must end in a separate faculty certification decision
Minimum successful observations	Conditional	Number required when observation or repeated performance is used
Prerequisite competencies	No	Competencies that should be completed first
Source reference	Yes	Source section for the competency

Add and import options

The user can:

add one competency;
copy an existing competency within the Draft version;
import from the approved spreadsheet template;
copy from a previous institute curriculum version;
review pack-created competencies;
bulk-assign stage, course, method, or completion fields where allowed.

An import always uses three steps: upload, preview with row-level errors, and confirm. A failed row is never silently omitted.

Competency relationships

A competency belongs to one curriculum version. A course-based competency normally has one responsible course placement and may have contributing placements for integrated teaching. A programme-level competency can exist without being owned by one course. Prerequisites create a directed relationship, and MedCES prevents circular prerequisite chains.

Evidence and certification rule

For a competency that requires learner evidence or certification, the user defines:

Field	Required	What the user defines
Curriculum home	Yes	Responsible course, clinical posting, elective, or longitudinal requirement
Logbook activity	Conditional	Case record, procedure, skill, reflection, presentation, visit, or another controlled activity
Evidence required	Conditional	Structured entry, attachment, direct observation, assessment outcome, attendance-backed exposure, or a supported combination
Required count	Conditional	Number of accepted entries or successful performances
Entry-verifier context	Conditional	Actual supervisor, assigned course faculty, assigned unit faculty, or another supported context
Eligible verifier designations	Conditional	Faculty designations permitted to verify the activity
Final certification authority	Conditional	Course Coordinator, eligible unit or department faculty, or a configured longitudinal coordinator
Eligible certifier designations	Conditional	Designations permitted where certification follows a unit or department chain
Same verifier may certify	Conditional	Whether one eligible faculty member may perform both decisions
Remediation rule	Conditional	Repeat, supervised practice, teaching, reflection, or another supported corrective route

The curriculum stores eligibility rules, not named faculty members. Actual users are resolved from current faculty designation, department or unit association, course or posting assignment, learner scope, and effective dates.

Attendance at a conducted session may create Teaching Exposure when the competency was actually covered and attendance is finalised. It never creates competency certification by itself.

Course-owned competencies are certified by the Course Coordinator when their evidence rule is satisfied. Posting-linked evidence is verified by the actual supervisor or eligible assigned faculty, and final certification follows the configured designation chain within the assigned unit and responsible department.

Step 5: Clinical Postings and Standalone Requirements

A clinical posting is not entered as free text on a course. The user creates a typed requirement that MedCES can later evaluate.

Clinical-posting fields

Field	Required	What the user defines
Posting code/name	Yes	Stable identity in this curriculum version
Academic discipline or subject	Yes	Controlled academic context for the posting, such as General Medicine
Related curriculum course(s)	No	Optional links where the posting contributes to one or more course placements
Stage	Yes	Stage in which the posting is required
Posting type	Yes	Ward, outpatient, community, emergency, laboratory, skills, elective, or another supported type
Required duration	Yes	Number with unit: hours, sessions, days, or weeks
Number of blocks	Conditional	Required number of separate rotations
Minimum/maximum block length	No	Limits used when Academic Planning and Delivery splits the posting
May be split	Yes	Whether the duration may be delivered in several blocks
Sequence or prerequisite	No	Earlier stage, course, competency, or posting required first
Required site type	Yes	Teaching hospital, community centre, skills lab, or another site type
Required exposure	No	Competency set, case category, procedure, or skill requirement
Minimum attendance	Conditional	Percentage or supported attendance rule
Supervisor role	Conditional	Role eligible to supervise and sign off
Sign-off required	Yes	Whether completion requires supervisor approval
Completion basis	Yes	Duration, sessions, attendance, competency, sign-off, or a supported combination
Source reference	Yes	Source section supporting the requirement

The posting requirement is an independent curriculum record. It does not belong to a course. Optional links can show that a posting contributes to one or more course placements without making either record the owner of the other.

The curriculum requirement names the required site type, not the actual institute hospital, ward, faculty member, dates, or learner group. Eligible resources are defined in Curriculum Delivery Setup. Actual dates and learner rotations are created in Academic Planning and Delivery.

Ordinary course practicals are not created here as separate requirements. Anatomy dissection, Physiology practicals, and Biochemistry laboratory classes are delivery components of their course placements and are scheduled through cohort course offerings.

A practical, field, laboratory, or skill requirement is created separately only when it genuinely applies to the programme or phase rather than belonging to one course. Internship and clinical-posting rotations remain separate typed requirements because they have their own duration, site, supervision, learner-allocation, and completion rules.

Step 6: Other Completion Requirements

This step records non-assessment curriculum requirements that are not already represented by a course placement, competency, or clinical-posting requirement.

The user can also add:

competency sign-off count;
required document or portfolio completion;
specified teaching-hour delivery;
skill or procedure completion;
longitudinal-component completion;
internship-rotation completion.

Each requirement states whether it applies to institute delivery, cohort planning, learner completion, or more than one of these. Examination-eligibility attendance and internal-assessment gates are not authored here; they belong to the later Assessment and Examination design.

Step 7: Assessment Definitions

The builder shows the assessments defined for each phase and whether their identity, authority, academic coverage, and outcome contract are complete.

Assessment authoring is completed in Curriculum Assessment Definitions. A progression rule cannot reference an assessment until that assessment exists in the same curriculum version and produces a supported final overall outcome.

Step 8: Phase Progression Rules

The builder shows every transition from one phase to the next, its condition groups, referenced definitions, validation state, and simulation position.

Detailed authoring is completed in Phase Progression Rules. Conditions use predefined categories, category-specific thresholds where required, and explicit AND/OR groups. They do not reproduce examination eligibility or result-calculation rules.

Step 9: Validation and Review

The final screen lists problems by stage, course, competency, posting, assessment, and progression rule.

Validation checks include:

missing or overlapping stages;
curriculum courses without a published institute course or lead department;
competencies without stage, course, method, completion basis, or source;
clinical postings without duration, site type, attendance, or sign-off information where required;
assessment definitions with incomplete identity, coverage, authority, or outcome contracts;
phase transitions with invalid AND/OR groups or references outside the curriculum version;
unsupported requirement behaviour;
pack-locked values changed locally;
source items removed without an authorised decision;
differences from the previous curriculum version.

Errors prevent submission. Warnings require acknowledgement and, where configured, an explanation.

Worked example: Phase II Medicine posting

The institute has a published course General Medicine. In MBBS CBME 2024, the curriculum editor:

places General Medicine in Phase II as a mandatory curriculum course;
selects the applicable Medicine competencies from the pack;
creates the independent General Medicine Clinical Posting requirement for Phase II;
records the source-defined duration and unit;
allows splitting only if the governing curriculum permits it;
selects Approved Teaching Hospital as the required site type;
records the attendance threshold and supervisor sign-off rule;
optionally links the posting to the General Medicine course placement;
adds posting completion to the Phase II progression rule.

At this point, MedCES understands what must be delivered and what evidence will prove completion. The actual Department of Medicine, teaching hospital, wards, capacity, and eligible supervisor roles are mapped in Curriculum Delivery Setup. Actual dates and learners are assigned in Academic Planning and Delivery.

Use case 1: Define the curriculum stages

As an institute member with Curriculum Committee role
I want to build the ordered stages of the curriculum
So that every course and requirement has a clear academic period.

Acceptance criteria

The user can add, order, and nest Draft stages.
Every stage records code, name, type, duration, sequence, and source.
Illegal overlap, duplicate sequence, and duration inconsistency are explained.
The builder supports programme patterns other than MBBS phases.
A referenced stage cannot be removed without a visible impact decision.

Use case 2: Place institute courses into the curriculum

As an institute member with Academic Registrar role
I want to place institute courses in stages
So that the curriculum states when and how each course applies.

Acceptance criteria

Only courses from the same institute can be selected.
Stage, mandatory status, sequence, longitudinal status, hours/credits where used, and source are recorded.
One institute course may appear in several stages with separate curriculum-course records.
The screen distinguishes the stable course from this version-specific placement.
Totals and missing coverage are shown before review.

Use case 3: Define and import competencies

As an institute member with Curriculum Committee role
I want to define competencies with their teaching and completion methods
So that MedCES can later track meaningful learner evidence.

Acceptance criteria

Every competency has code, statement, stage, domain, proficiency, method, completion basis, and source.
Course-based competencies identify one responsible course placement and any contributing placements.
Spreadsheet import shows every valid row and every error before creation.
Duplicate codes and circular prerequisites are blocked.
Direct observation, sign-off, and minimum evidence are captured as typed fields.
Unsupported automatic evaluation is marked for product support rather than accepted as free-form executable logic.

Use case 4: Define a clinical posting

As an institute member with Curriculum Committee role
I want to record a clinical-posting requirement
So that delivery and learner completion can be planned and evaluated correctly.

Acceptance criteria

Academic discipline, stage, duration/unit, split rule, site type, attendance, sign-off, completion basis, and source are captured.
Course links are optional and can connect the posting to more than one curriculum course.
The form shows only fields relevant to the selected posting type.
The posting does not select actual dates, learners, wards, or named faculty.
Required exposure can reference defined competencies, skills, procedures, or case categories.
MedCES explains which evaluator will measure completion.

Use case 5: Complete assessment definitions

As an institute member with Assessment Coordinator role
I want to confirm the assessments required by each phase
So that progression and later examination operations reference stable definitions.

Acceptance criteria

Every assessment has a code, name, phase, type, authority, academic coverage, outcome contract, and source.
The definition comes from the same curriculum version as its phase and courses.
Assessment marks, eligibility gates, attempts, and result calculation are not invented in Curriculum Builder.
The detailed workspace is linked with its completion and validation state.

Use case 6: Complete phase progression rules

As an institute member with Curriculum Committee role
I want to define the requirements for moving from one phase to the next
So that student progression is consistent and explainable.

Acceptance criteria

Every transition has source and target phases in the same curriculum version.
Conditions use supported categories and explicit AND/OR groups.
An assessment condition references an existing curriculum assessment definition rather than free text.
Circular phase or condition references are blocked.
Simulation shows the plain-language result of every condition and group.

Use case 7: Validate and submit a curriculum version

As an institute member with Academic Registrar role
I want to validate the complete curriculum and send it for review
So that incomplete or contradictory academic rules are not published.

Acceptance criteria

Validation covers structure, courses, competencies, postings, assessments, completion rules, progression, sources, and pack policy.
Errors link directly to the field that needs attention.
Differences from the source pack and previous institute version are visible.
Reviewers can comment on an individual item and return it with a reason.
Publication remains unavailable until delivery setup and all mandatory validation are complete.

Business rules

A curriculum version belongs to one institute programme and therefore one institute.
Published versions are read-only; any change creates a successor Draft.
A curriculum course always references an institute course from the same institute.
Competencies, course placements, postings, assessment definitions, and phase progression rules belong to one curriculum version.
Course placements and clinical-posting requirements are independent sibling records.
A posting may link to zero, one, or several course placements without belonging to any of them.
Pack-locked values cannot be weakened locally.
Allowed local additions are marked as local and require institute source approval.
Users define requirements through supported types and fields, never executable code.
A published change to an assessment definition, phase transition, condition, threshold, or AND/OR structure requires a successor curriculum version.
A missing evaluator may be stored as advisory only until MedCES supports and tests the behaviour.
Curriculum publication does not create schedules, attendance, assessment events, or learner evidence.
Cohorts pin a published institute curriculum version and are not moved by later edits or pack updates.

Technical design

How the records relate

academic.institute_programme
  -> academic.curriculum
       -> academic.curriculum_version
            -> academic.curriculum_stage
            -> academic.curriculum_course_placement -> academic.institute_course
            -> academic.competency
                 -> academic.course_competency_link
                 -> academic.competency_completion_rule
                 -> academic.logbook_requirement_definition
            -> academic.clinical_posting_requirement
                 -> academic.posting_course_link (optional)
            -> academic.curriculum_requirement
            -> academic.assessment_definition
                 -> academic.assessment_course_link
                 -> academic.assessment_outcome_contract
            -> academic.curriculum_phase_transition
                 -> academic.progression_condition_group
                 -> academic.progression_condition

Conceptual schema

Record	Important fields
`academic.curriculum`	institute programme, name, status
`academic.curriculum_version`	curriculum, code/name, previous version, pack origin, applicability, effective date, source, status
`academic.curriculum_stage`	version, parent stage, code/name, type, sequence, duration/unit, overlap, exam/progression flags, source
`academic.curriculum_course_placement`	version, institute course, stage, parent placement, mandatory status, sequence, longitudinal, credits, completion basis, source
`academic.curriculum_course_delivery_component`	course placement, component type, required amount/unit, default session duration, audience mode, group type, teaching method, facility capability, sequence/distribution rule, source
`academic.competency`	version, code, statement, stage, domain, proficiency, core status, observation/sign-off, source
`academic.course_competency_link`	competency, curriculum course placement, responsibility or contribution type
`academic.competency_prerequisite`	competency, prerequisite competency
`academic.competency_completion_rule`	competency, completion method, observation, certification, successful count, authority type, same-actor rule
`academic.logbook_requirement_definition`	version, stage, course/posting/longitudinal home, activity type, evidence rule, required count, mandatory state, source
`academic.logbook_requirement_competency`	logbook requirement, competency, evidence relationship
`academic.competency_verifier_designation`	completion rule, eligible faculty designation
`academic.competency_certifier_designation`	completion rule, eligible faculty designation
`academic.curriculum_requirement`	version, applies-to type/id, requirement kind, obligation subject, mandatory state, completion effect, evaluator type, source
`academic.clinical_posting_requirement`	version, stage, academic discipline, posting type, duration/unit, blocks, split limits, site type, attendance, supervisor role, sign-off, completion basis, source
`academic.posting_course_link`	posting requirement, curriculum course placement, relationship type
`academic.assessment_definition`	version, owning phase, code/name, type, authority, purpose, source
`academic.assessment_course_link`	assessment definition, curriculum course placement, coverage type, outcome requirements, sequence
`academic.assessment_outcome_contract`	assessment definition, subject/overall outcomes, value set, successful outcome, finality, progression use
`academic.curriculum_phase_transition`	version, code/name, from/to phase, approval and exception route, source
`academic.progression_condition_group`	transition, parent group, AND/OR operator, sequence
`academic.progression_condition`	group, supported category, comparator/value/unit, missing-data result, reference, source

Type-specific tables keep clinical, assessment, and attendance fields understandable. JSON may store non-executable source metadata, but it is not the only representation of curriculum rules.

Process-layer responsibilities

The process layer:

validates stage ordering, duration, nesting, and overlap;
places institute courses without changing their stable identity;
validates course delivery components, required totals, audience modes, supported units, and component-level source coverage;
validates competency uniqueness, methods, prerequisites, and source coverage;
validates evidence methods, successful counts, curriculum ownership, eligible designation rules, and certification authority;
normalises supported units such as hours, sessions, days, and weeks;
checks typed posting, assessment-definition, completion, and progression requirements;
validates explicit AND and OR progression groups and category-specific fields;
returns a plain-language explanation for every validation and learner result;
compares the Draft with its pack source and previous version;
prevents publication when required delivery mappings or evaluators are missing.

It does not:

contain hard-coded MBBS phases, durations, competencies, or thresholds;
select institute departments, sites, rooms, or faculty;
create operational schedules or evidence;
execute user-authored formulas, SQL, or scripts;
rewrite a published version or an existing cohort snapshot.

Success outcome

The institute has a complete, source-backed curriculum version that explains every stage, course, competency, posting, assessment, and progression condition before operational delivery begins.