Master Timetable Review and Publication

Epic summary

The Master Timetable Review and Publication workspace brings the phase’s course sessions and clinical-posting blocks into one calendar for final review.

Course Coordinators and Clinical Posting Coordinators remain responsible for the plans they prepare. The master timetable does not copy or replace those plans. It controls which reviewed version is released to faculty and students.

Course-session allocations ───────┐
                                  ├─> Master timetable revision
Clinical-posting assignments ─────┘      -> review
                                          -> approval
                                          -> publication

For example, the Anatomy department may have completed its practical schedule while the Clinical Posting Coordinator has completed the Medicine rotations. This workspace shows both together and identifies a learner-group, faculty, or facility clash before either plan is released.

Assessment events are outside this epic. They can be shown as protected timetable items later when the Assessment and Examination module is defined.

Before you start

The following must already exist:

• an approved cohort phase plan;
• actual phase participants and learner groups;
• course offerings with draft timetable allocations;
• a clinical-posting plan with dated department and unit assignments;
• the applicable academic calendar, holidays, and protected periods;
• confirmed faculty, unit, site, and facility availability where required; and
• users assigned to timetable review and approval roles.

The workspace may be opened while individual schedules are incomplete. A timetable cannot be approved or published until every required source plan is ready or an authorised exception has been recorded.

Actors and access

Access source	Access in this epic
Institute member with Timetable Coordinator role	Creates the master revision, runs institute-wide checks, coordinates corrections, and submits it for approval
Institute member with Phase Coordinator role	Reviews phase coverage and confirms that the timetable supports the phase plan
Institute member with Course Coordinator role	Reviews and corrects source course sessions returned to the assigned offering
Institute member with Clinical Posting Coordinator role	Reviews and corrects source posting assignments returned to the clinical plan
Department Admin, normally with HOD appointment	Confirms departmental readiness and resolves department-owned resource issues
Facilities Officer role	Reviews facility capability, capacity, and clashes and confirms authorised facility changes
Institute member with Academic Registrar role	Approves or returns the complete timetable and controls exceptional publication decisions
Faculty	Views released sessions and postings that apply to the faculty member
Student	Views only released sessions and postings that apply to the student’s cohort and groups
Auditor role	Reads source versions, conflicts, decisions, publications, changes, and notifications within scope

Institute Admin and Tenant Admin may see timetable readiness across their scope. Administrative access alone does not allow a user to approve or publish an academic timetable.

Timetable lifecycle

Draft
  -> Under Review
  -> Approved
  -> Published
  -> Superseded

A returned revision moves back to Draft with the review comments retained. A published revision is never edited in place. A later change creates a successor revision that shows what changed and whom it affects.

Workspace structure

The workspace contains:

1. Timetable Revision List
2. Combined Calendar
3. Conflict Workbench
4. Coverage and Readiness
5. Review and Approval
6. Publish and Notify
7. Changes and History

Screen 1: Timetable Revision List

The list shows one row for each timetable revision prepared for a cohort phase plan.

Field	Meaning
Cohort and phase	Academic population and dated phase covered by the revision
Revision number	Sequential revision within that phase plan
Source snapshot time	Point at which course and posting plans were brought into this revision
Coverage	Required work included, incomplete, or accepted as an exception
Open conflicts	Count by blocking error and warning
Review state	Draft, Under Review, Approved, Published, or Superseded
Effective date	Date from which the published revision is visible and applicable
Published by and at	Actor and time of release

The user can create the first revision, create a successor from the current published revision, compare revisions, or open a revision within their scope.

Screen 2: Combined Calendar

The combined calendar can be viewed by:

• cohort and phase;
• learner group or individual learner exception;
• department or unit;
• faculty member or faculty pool;
• facility, site, or location; and
• day, week, or rotation period.

Each item identifies its source. A course session remains linked to its course offering and a clinical block remains linked to its posting assignment.

The coordinator can filter, inspect, and propose a correction. The calendar must not turn a clinical posting into an ordinary course session or change curriculum requirements.

Screen 3: Conflict Workbench

The workbench shows each issue in plain language, the affected records, and the action needed.

Blocking conflicts

• the same learner or learner group has overlapping activities;
• a named faculty member has overlapping assignments;
• a facility, site, location, department, or unit exceeds its availability or capacity;
• a facility does not provide the required capability;
• an activity falls outside the phase, offering, posting, or working-calendar dates;
• a course session overlaps protected clinical-posting time;
• an authority-locked item has been moved; or
• required course or posting coverage is missing.

Warnings

• unusually long learner or faculty gaps;
• an undesirable distribution of sessions across the week;
• high faculty or facility load that remains within an allowed limit;
• academic detail that is allowed to follow scheduling but is still incomplete; or
• a permitted preference that the scheduler could not satisfy.

Blocking conflicts prevent approval. A warning may be accepted only by an authorised role and always requires a reason.

When a correction changes the academic meaning of a course session or a clinical assignment, the item is returned to its owning workspace. A timetable user must not silently rewrite another coordinator’s source record.

Screen 4: Coverage and Readiness

This screen answers whether the timetable is complete enough to release.

It shows:

• required, included, scheduled, and missing course coverage by component and group;
• required and scheduled clinical-posting duration by group and learner;
• unscheduled sessions and postings;
• unconfirmed departments, units, faculty, or facilities;
• unresolved blocking conflicts and accepted warnings;
• sessions whose topic or other academic detail is still pending;
• source plans changed after the revision snapshot; and
• readiness of the faculty and student views.

The system distinguishes not scheduled, scheduled but not yet confirmed, and excluded through an approved exception. These must not appear as the same state.

Screen 5: Review and Approval

The Timetable Coordinator submits a complete revision with:

• the revision summary;
• coverage and conflict report;
• accepted-warning reasons;
• unresolved exceptions requiring a decision;
• source confirmations; and
• a proposed effective and release date.

The Academic Registrar or another configured approver can approve, return, or reject the revision. The decision records the actor, role assignment, time, comments, and exact revision reviewed.

Approval does not automatically publish the timetable unless institute policy explicitly combines those actions.

Screen 6: Publish and Notify

Before publication, the user defines:

Field	Required	Meaning
Timetable revision	Yes	Exact approved revision being released
Audience	Yes	Whole phase, selected groups, departments, faculty, or an authorised phased release
Visible from	Yes	Date and time at which the audience can see the timetable
Effective from	Yes	Date from which this revision governs planned activity
Change summary	Conditional	Required for a successor revision
Notification channels	Yes	In-application and other configured channels
Publication note	No	Plain-language instruction shown with the release

Publication creates a fixed release record. Notifications identify the changed dates or activities and link the user to the current timetable. A failed notification does not roll back the publication, but it remains visible for retry and audit.

Screen 7: Changes and History

A change after publication starts from the current published revision.

The user can:

• propose a course-session or posting change;
• see affected learners, faculty, groups, facilities, and dependent records;
• return the source item to its coordinator where necessary;
• create a successor timetable revision;
• compare old and new dates, times, rooms, faculty, or assignments;
• review and approve the successor; and
• publish it with targeted notifications.

Completed delivery and finalised attendance are never rewritten merely because the planned timetable changes later.

Use case 1: Create a master timetable revision

As a Timetable Coordinator
I want to bring the latest course and clinical schedules into one controlled revision
So that the institute can review one complete timetable.

Acceptance criteria

• Every included item retains its source type and source record.
• The revision stores the source versions or snapshot time used.
• Course sessions and clinical postings remain different record types.
• Rebuilding a Draft revision identifies source changes instead of silently overwriting reviewed decisions.
• A published revision cannot be reused as an editable Draft.

Use case 2: Review the combined calendar

As a Phase Coordinator
I want to view the timetable by learner, group, department, faculty, and facility
So that I can identify conflicts that are not visible inside one department’s plan.

Acceptance criteria

• Every view is generated from the same revision.
• Blocking conflicts and warnings are clearly different.
• Each issue names the affected records and gives a plain explanation.
• The user can open the owning course or posting workspace from an item.
• Organisational scope is applied to every view and export.

Use case 3: Resolve a timetable conflict

As a Timetable Coordinator
I want to coordinate a valid correction
So that the conflict is removed without losing source ownership or history.

Acceptance criteria

• Manual and automatic changes use the same validation rules.
• A source-owned academic change is returned to the authorised coordinator.
• A permitted timetable-only change updates the Draft source allocation through an audited service.
• Locked items require the correct authority and a reason before movement.
• Conflict status is recalculated after the source change is accepted.

Use case 4: Approve the timetable

As an Academic Registrar
I want to review the complete revision and its exceptions
So that only an academically and operationally ready timetable can be released.

Acceptance criteria

• Blocking conflicts prevent approval.
• Coverage gaps require resolution or a separately authorised exception.
• The decision applies to one exact revision.
• Returning the timetable requires comments and preserves the submitted version.
• The preparer cannot approve their own revision where maker-checker policy applies.

Use case 5: Publish the timetable

As an authorised Timetable Coordinator or Academic Registrar
I want to release an approved timetable to its audience
So that faculty and students work from one current plan.

Acceptance criteria

• Only an Approved revision can be published.
• Exactly one current published revision applies to an audience for the same dates.
• Publication records the audience, visible time, effective time, actor, and approved revision.
• Faculty and students see only items applicable to them.
• Notifications and failed delivery attempts are retained.

Use case 6: Publish a timetable change

As a Timetable Coordinator
I want to issue a reviewed successor revision
So that an unavoidable change is visible without altering the earlier record.

Acceptance criteria

• The successor starts from the current published revision.
• The system shows the impact before submission.
• The new revision follows the required review and approval route.
• Affected users receive a focused change notice.
• The earlier revision remains readable as Superseded.

Business rules

1. Source course and clinical records remain authoritative for their academic meaning.
2. A timetable revision controls review and release; it does not redefine curriculum requirements.
3. Blocking conflicts cannot be waived as warnings.
4. Published revisions are immutable.
5. A source change after review makes the affected readiness check stale.
6. Approval and publication must use active role assignments within institute scope.
7. Timetable changes do not rewrite completed delivery or finalised attendance.
8. Assessment events remain outside this epic until their own module is defined.

Exception paths

• Source schedule changed during review: mark affected checks stale and require refresh before approval.
• Urgent room or faculty change: create a successor revision or permitted emergency amendment, record the reason, revalidate, and notify affected users.
• Notification fails: keep the publication valid, record failure, and allow authorised retry.
• Unavoidable coverage gap: require a named academic exception and future recovery plan; do not label the gap complete.
• Protected activity clashes: return the movable item to its owner; do not move the protected item without the required authority.

Conceptual schema

Record	Important fields
academic.master_timetable	tenant, institute, cohort phase plan, timetable type, current published revision
academic.timetable_revision	timetable, revision number, source snapshot, status, effective dates, predecessor revision
academic.timetable_source_item	revision, source type, source record, source version, included state, display interval
academic.timetable_conflict	revision, conflict type, severity, affected records, explanation, status
academic.timetable_review	revision, reviewer assignment, decision, comments, decided at
academic.timetable_publication	revision, audience, visible from, effective from, publisher, published at
academic.timetable_notification	publication, recipient, channel, delivery state, attempt history
academic.timetable_change_request	current revision, source item, requested change, reason, impact, decision
academic.timetable_revision_event	revision, action, actor, role assignment, previous value, new value, time

academic.timetable_allocation continues to hold the planned date, time, and facility for a course session. The master timetable links that allocation to a reviewed revision rather than creating a second editable allocation.

Process-layer responsibilities

The process layer must:

• create a revision from exact source records and versions;
• combine course sessions and clinical blocks without changing their record types;
• check learner, group, faculty, facility, unit, site, date, capability, capacity, and coverage conflicts;
• explain each conflict and identify its owning workspace;
• detect source changes made after the revision snapshot;
• route source-owned corrections to an authorised coordinator;
• enforce locks and maker-checker rules;
• prevent approval while blocking conflicts remain;
• make an approved publication immutable;
• ensure one current release for the same audience and effective period;
• create successor revisions for later changes;
• calculate the affected audience and send targeted notifications; and
• preserve review, approval, publication, change, and notification history.

Out of scope

This epic does not:

• define course content or curriculum hours;
• create learner groups, course sessions, or clinical rotations;
• record actual delivery or attendance;
• schedule assessments or publish examination timetables;
• approve leave or make progression decisions; or
• edit a published timetable in place.