Academic Planning and Delivery Data Model

Purpose

This page defines the operational records used to turn a cohort’s published curriculum into dated phase delivery.

The model does not copy curriculum requirements into editable operational rules. Every phase plan, course offering, and clinical-posting plan keeps a reference to the exact published curriculum version already pinned to the cohort.

Ownership map

student.cohort                                      Student and Cohort Management
└── academic.cohort_phase_plan                      Academic Planning and Delivery
    ├── phase-plan participants
    ├── learner group sets and memberships
    ├── academic.cohort_course_offering
    │   ├── course sessions and timetable allocations
    │   ├── actual delivery records
    │   └── materials and course communication
    ├── academic.clinical_posting_plan
    │   └── department rotations
    │       ├── posting-specific unit subgroups
    │       └── dated posting occurrences
    │           ├── actual clinical delivery and operational changes
    │           └── attendance and competency hand-offs
    ├── academic.master_timetable and published revisions
    └── attendance occurrences, marks, ledgers, and certificates

The phase plan references one curriculum phase from the curriculum version pinned to the cohort. Its participant records reference authoritative programme enrolments and student phase assignments rather than replacing them.

Core records

Record	Purpose
academic.cohort_phase_plan	Represents the dated operational instance of one curriculum phase for a primary cohort
academic.phase_plan_participant	Connects an authoritative student phase assignment to operational participation in the phase plan
academic.phase_plan_readiness_result	Stores each planning-readiness check and its explanation
academic.phase_plan_amendment	Records a proposed controlled change and its impact and approval
academic.learner_group_set	Defines one grouping purpose such as practical, tutorial, or clinical rotation within a phase plan
academic.learner_group	Represents one stable phase-level learner group
academic.learner_group_membership	Connects a phase-plan participant to a group for effective dates
academic.group_generation_run	Stores the roster snapshot, method, locks, parameters, seed, and result of automatic group generation
academic.cohort_course_offering	Represents one curriculum course placement being delivered through one cohort phase plan
academic.course_offering_component_plan	Connects an inherited curriculum delivery component to its actual learner groups, delivery window, and operational readiness without redefining its requirement
academic.course_offering_group	Connects a group-based component to the actual learner groups used by this offering
academic.course_session	Represents one schedulable or scheduled occurrence of course teaching
academic.course_session_audience	Identifies the full cohort, selected groups, one group, or an authorised individual exception covered by a session
academic.course_session_competency	Connects a session to competencies from the same curriculum version
academic.course_session_faculty_plan	Stores the planned faculty member, faculty pool, or eligibility requirement for the session
academic.timetable_allocation	Places a course session on a date and time with a planned facility
academic.schedule_run	Stores the inputs and result summary for one automatic scheduling attempt
academic.schedule_proposal_item	Stores a proposed allocation, warning, or unscheduled reason produced by a scheduling run
academic.course_offering_event	Preserves offering status changes, confirmations, returns, and cancellations
academic.clinical_posting_plan	Represents the phase’s dated operational plan for curriculum clinical-posting requirements
academic.clinical_rotation_period	Defines one dated rotation period and its clinical time pattern
academic.posting_unit_availability	Records which eligible unit can receive how many learners for which dates and sites
academic.clinical_posting_assignment	Assigns one stable clinical group to a department posting and rotation period
academic.clinical_posting_subgroup	Represents a posting-specific subdivision assigned to one unit, site, and supervisor pool
academic.clinical_posting_subgroup_member	Connects actual phase participants to the posting-specific unit subgroup
academic.clinical_schedule_run	Stores department-rotation or unit-allocation scheduler inputs, algorithm details, and result
academic.clinical_posting_occurrence	Represents one dated posting day or shift derived from a released posting assignment and its approved time pattern
academic.clinical_posting_occurrence_learner	Records why a learner is expected for a dated posting occurrence
academic.clinical_posting_delivery_record	Records the outcome and actual unit, site, location, time, and other facts for one posting occurrence
academic.clinical_posting_delivery_supervisor	Identifies the supervisors who were actually responsible for the delivered occurrence
academic.clinical_posting_activity_summary	Records the controlled, non-identifying educational activity categories undertaken
academic.clinical_posting_operational_variance	Preserves an approved difference between the published plan and actual clinical delivery
academic.clinical_posting_replacement_requirement	Connects cancelled or partial delivery to required and completed replacement work
academic.clinical_posting_completion_snapshot	Stores an explainable Ready, Not Ready, or Unable to Evaluate result for one learner and posting assignment
academic.master_timetable	Identifies the controlled timetable for one cohort phase plan
academic.timetable_revision	Stores one Draft, reviewed, approved, published, or superseded timetable revision
academic.timetable_source_item	Connects a revision to an exact version of a course allocation or clinical-posting assignment
academic.timetable_conflict	Stores a blocking conflict or warning, its affected records, explanation, and resolution
academic.timetable_review	Records an approval, return, or rejection against one exact revision
academic.timetable_publication	Releases an approved revision to a defined audience from an effective date
academic.course_delivery_record	Records the outcome and actual facts for one planned course session
academic.course_delivery_faculty	Identifies the faculty who actually delivered the session and their contribution
academic.course_material	Stores the identity, scope, audience, and state of a lightweight course resource
academic.course_material_version	Stores each released or replaced file or link version
academic.course_announcement	Stores a dated notice for a course, group, or session audience
academic.course_discussion	Defines a moderated course or group discussion and its permissions
academic.course_discussion_post	Stores a discussion post, reply, and moderation state
attendance.attendance_occurrence	Represents one attendance-taking opportunity derived from course or clinical activity
attendance.attendance_roster_member	Records why a learner was eligible for the occurrence
attendance.attendance_mark	Stores the learner’s raw status, duration, reason, capture source, and actor
attendance.attendance_ledger_entry	Stores immutable numerator and denominator facts created on finalisation or correction
attendance.attendance_summary	Provides a recalculable attendance view for a learner, category, and period
attendance.attendance_certification	Preserves a versioned attendance statement and the facts and policies used

Phase plan and learner ownership

The phase plan has one primary cohort, curriculum version, curriculum phase, academic calendar, and dated interval. It may include an individually approved learner from another cohort when the programme, curriculum, and phase are compatible.

academic.phase_plan_participant records operational participation only. It does not create a programme enrolment, move a cohort, or make a progression decision.

Projected learner numbers are stored on the phase plan for capacity planning. They never become participant records until an authoritative student phase assignment exists.

Learner-group ownership

Learner groups belong to one phase plan and one group set. Membership is effective-dated and references an actual phase-plan participant before activation.

Stable clinical groups rotate across departments. Unit subgroups are not permanent learner groups: they belong to one clinical-posting assignment and may be different for the next department.

Course-offering record

Field	Meaning
tenant_id, institute_id	Ownership and isolation boundary
cohort_phase_plan_id	Dated phase plan through which the course is delivered
curriculum_course_placement_id	Exact course placement in the cohort’s pinned curriculum version
planned_start_date, planned_end_date	Delivery window within the phase plan
course_coordinator_assignment_id	Current authorised coordinator assignment
status	Draft, Ready for Scheduling, Partially Scheduled, Fully Scheduled, Active, Completed, or Cancelled
department_confirmation_state	Whether the responsible department has confirmed its operational readiness
created_from	Phase-plan generation, manual addition, elective selection, remediation, or another supported source
row_version	Prevents one editor from silently overwriting another editor’s work

One phase plan can have only one active offering for the same curriculum course placement. A cancelled offering remains in history and cannot be replaced without an authorised reason.

Curriculum requirements are inherited

The following values come from the immutable curriculum course delivery component:

• component type;
• required hours or sessions;
• default session duration;
• audience mode;
• learning-group type;
• teaching method;
• required facility capability;
• source-defined sequence or distribution rule; and
• competency relationships.

academic.course_offering_component_plan does not copy these into editable requirement fields. It records only operational choices such as the actual groups, permitted delivery window, selected resource pool, readiness state, and a justified exception where the curriculum allows one.

Course sessions and timetable allocations

A course session and its timetable allocation are separate so that either working order is possible.

Topic-first
  Course session with topic and audience
    -> timetable allocation

Timetable-first
  Course session shell
    -> timetable allocation
    -> department later completes topic and academic detail

The course session stores the academic meaning. The timetable allocation stores the date, start time, end time, facility, scheduling state, and lock state.

Changing the room or time does not create a new curriculum requirement. Changing the topic or faculty does not erase the earlier allocation history.

Learner hours and group-delivery hours

Curriculum hours describe what each learner must receive.

If a practical component requires 30 hours and the cohort has four practical groups, each group must receive 30 hours. The institute may therefore schedule up to 120 group-delivery hours when the groups are taught separately.

Required learner coverage: 30 hours per learner
Practical Group A:          30 scheduled hours
Practical Group B:          30 scheduled hours
Practical Group C:          30 scheduled hours
Practical Group D:          30 scheduled hours

If two groups can use separate laboratories at the same time, those group-delivery hours may occur in parallel. The system reports coverage for each learner group rather than adding the group hours and incorrectly comparing 120 with the curriculum requirement of 30.

Planned and actual faculty

The schedule may name a faculty member, identify an eligible faculty pool, or leave the named assignment to the department where policy allows it.

The faculty member who actually delivered the session is recorded later in the delivery record. A last-minute substitution must not rewrite the planned timetable as though the original assignment never existed.

Scheduling-run records

An automatic run stores:

• offerings, sessions, dates, and groups included;
• calendar and period-template version used;
• existing locked allocations;
• faculty, facility, group, and capacity facts used;
• hard constraints and permitted preferences;
• algorithm version and run time;
• proposed allocations;
• unscheduled sessions and reasons; and
• warnings and coverage summary.

The result is a proposal. Accepting a proposal creates or changes draft timetable allocations through an audited action. Running the scheduler never publishes the timetable.

Clinical rotation and unit allocation

Clinical scheduling has two levels:

Main clinical group
  -> department posting and rotation period
      -> posting-specific subgroups
          -> unit, site, location options, and supervisor pool

The department assignment preserves the curriculum posting and duration. Unit subgroups place every actual learner within the available clinical teams and capacity for that posting. A department without units remains a department-level assignment.

Posting blocks expose their protected clinical hours to timetable conflict checking without becoming ordinary course sessions.

Master timetable ownership

The source schedulers own their course allocations and clinical-posting assignments. The master timetable owns the controlled revision through which those source records are reviewed and released.

Course allocation ───────────────┐
                                 ├─> timetable source item
Clinical posting assignment ─────┘      -> timetable revision
                                         -> review
                                         -> publication

academic.timetable_source_item stores the source type, source record, and source version used by a revision. It is not a second editable timetable allocation.

A published revision is immutable. A change creates a successor academic.timetable_revision, and the earlier revision becomes Superseded only when the successor is published for the same audience and effective scope.

Conflicts belong to the revision on which they were calculated. If a source record changes, affected checks are marked stale and recalculated rather than presented as still valid.

Planned and actual delivery

The planned course session answers what the department intended to teach. academic.course_delivery_record answers what actually happened during course teaching.

Planned session	Actual delivery record
Planned date, time, and duration	Actual start, end, and accepted duration
Planned faculty or faculty pool	Faculty who actually delivered
Planned facility	Actual facility where required
Planned topic, objectives, and competencies	Topic, objectives, and competencies actually covered
Scheduled state	Conducted, Partially Conducted, Cancelled, or Rescheduled outcome

The planned values are not overwritten by actual values. A substitution, cancellation, partial session, or deviation remains visible and may create a replacement-teaching need.

The Course Workspace is a working surface over academic.cohort_course_offering; it is not another course or enrolment record. Student access comes from the active phase participant, effective learner-group membership, and session audience.

Materials, announcements, and discussions belong to the offering and have explicit audiences and visibility windows. File replacements create academic.course_material_version records. Moderated or withdrawn content remains in history.

Clinical-posting occurrences and delivery

A released clinical-posting assignment is a dated block for a main clinical group. It produces individual posting days or shifts from its approved time pattern.

Released clinical-posting assignment
  -> dated clinical-posting occurrence
      -> expected unit subgroup and learner roster
      -> actual clinical-posting delivery record
      -> attendance occurrence
      -> linked competency and logbook evidence

The occurrence keeps the planned unit, site, location options, time, supervisor pool, and expected roster. The delivery record separately stores what actually happened, including the outcome, accepted duration, actual unit, site, location, supervisors, and controlled educational activity categories.

A same-day operational substitution does not overwrite the published plan. academic.clinical_posting_operational_variance records the planned and actual values, reason, approval, and affected learners. A future or material schedule change returns to Clinical Posting Planning and Master Timetable Review.

A Cancelled occurrence does not become delivered time or an ordinary attendance opportunity. Partial or cancelled compulsory delivery may create academic.clinical_posting_replacement_requirement, connected to the original and replacement occurrences.

The completion snapshot reads named source facts from planning, clinical delivery, Attendance Management, and Competency and Logbook. It does not copy attendance marks or learner evidence and does not make a phase-progression decision.

Attendance ownership

Attendance is separate from the plan and from the delivery record.

Academic occurrence
  -> attendance occurrence
      -> eligible roster snapshot
          -> learner marks
              -> submission and finalisation
                  -> attendance ledger entries
                      -> summaries and certificates

The occurrence references its source course session, practical, tutorial, posting day, or shift. A multi-week clinical posting produces dated occurrences according to its operating pattern; it does not produce one mark for the whole posting.

The roster records why each learner was applicable on that date. It derives from effective phase, group, and posting assignments and does not create or change those assignments.

attendance.attendance_mark keeps the raw status. On finalisation, the applicable policy converts the mark into explainable numerator and denominator values stored in immutable ledger entries. A correction produces successor entries rather than changing the earlier official fact.

Attendance requirements and thresholds are authored with the curriculum or applicable Setup policy. Attendance retains the exact requirement and policy references used for capture, calculation, and certification.

Attendance calculation boundaries

Only conducted and applicable activity enters the denominator. Cancelled activities, Not Required learners, and dates outside a learner’s effective assignment are excluded.

Not Marked and unfinalised occurrences remain pending. They are not silently counted as absence. Authorised Absence remains a distinct raw status whose numerator and denominator treatment comes from policy.

Theory, practical, and clinical categories remain separate when the applicable requirements use separate thresholds. Attendance publishes the facts and certificate state; Assessment and Examination or Student and Cohort Management later decides what those facts mean for eligibility or progression.

Process-layer responsibilities

The process layer must:

• create and validate phase plans against the cohort’s pinned curriculum and academic calendar;
• keep projected learners separate from authoritative phase participants;
• validate cross-cohort participation without rewriting student history;
• generate and reconcile stable learner groups while preserving locks and effective dates;
• keep permanent group membership separate from posting-specific unit subgroup membership;
• create required draft offerings exactly once for a phase plan;
• verify that the offering references the phase plan’s pinned curriculum version and stage;
• prevent offering users from changing curriculum-owned component requirements;
• resolve the responsible department, eligible coordinators, facilities, faculty pools, group rules, and calendar from authoritative records;
• create session shells or accept department-prepared sessions without double-counting requirements;
• calculate full-cohort and group-specific coverage correctly;
• prevent group, faculty, facility, and date conflicts;
• check facility capability and capacity rather than matching only a room name;
• keep hard constraints separate from scheduling preferences;
• retain locks when an automatic scheduling run is repeated;
• explain why every session was or was not scheduled;
• allow topic-first and timetable-first working without losing academic detail;
• create department-rotation and unit-allocation candidates from curriculum, group, capacity, and availability records;
• enforce posting duration, exclusivity, sequence, department, unit, site, supervisor, and learner-capacity constraints;
• use actual learners when dividing a clinical group between units;
• retain clinical scheduling inputs, locks, algorithm version, result quality, and unscheduled reasons;
• build a master revision from exact source versions without duplicating their editable academic meaning;
• check cross-source conflicts and detect source changes made after review;
• enforce timetable review, approval, audience, publication, and successor-revision controls;
• keep planned session values separate from actual delivery values;
• validate actual faculty, time, topic, competencies, cancellation, partial delivery, and replacement need;
• derive course-workspace access from faculty assignments and learner participation rather than a second course enrolment;
• enforce material visibility, versioning, privacy, and discussion moderation;
• create dated clinical-posting occurrences from released assignments and approved time patterns;
• build expected clinical rosters from effective posting and unit-subgroup membership;
• keep planned clinical facts separate from actual unit, site, location, supervisor, time, activity, and outcome;
• validate operational substitutions and route future or material changes back through posting and timetable revision;
• create and track replacement requirements for compulsory cancelled or partial clinical delivery;
• read attendance and competency facts for explainable posting-completion readiness without copying their records;
• create attendance occurrences and rosters from applicable dated course or clinical activity and effective membership;
• keep raw attendance status separate from policy calculation treatment;
• finalise attendance into immutable ledger entries and correct it through successor entries;
• calculate explainable, category-specific summaries and versioned certificates;
• record every material change and preserve earlier published, finalised, or locked values; and
• prevent assessment events and clinical-posting blocks from being created as ordinary course sessions.

Module boundaries

• Setup owns the course, curriculum placement, delivery components, eligible resources, calendars, and reusable constraints.
• Student and Cohort Management owns the cohort, programme enrolment, cohort membership, and student phase assignment.
• Academic Planning and Delivery owns the phase plan, operational participant, learner group, offering, session, clinical rotation, unit subgroup, dated posting occurrence, timetable allocation and publication, actual course and clinical delivery, course and clinical-posting workspaces, and attendance records.
• Assessment and Examination will own practical, written, oral, and clinical assessment events and results.

Attendance supplies finalised and certified facts to later eligibility and progression processes. It does not make those decisions itself.

The timetable can eventually show all these dated records together without making them the same kind of record.