MaestroMaestro Overview — contents
The Build
The Published Course Package
The single most important architectural boundary in Maestro: how a finished course crosses from Studio to Journey. A course reaches learners only as a released version, a frozen, immutable snapshot that the Dean has approved. Journey never reads Studio's working drafts.
There is no direct publish. The course owner signs the final report, which freezes the course as a submitted version; the course cannot be signed until its milestones exist and are approved. The Dean of the course's school (or IT Admin) then releases exactly that version or returns it with a reason. A released version is immutable: improving the course produces a new version, which goes through the Dean again. Journey serves learners only from released versions.
The hand-off contract
Studio is where a course is designed and produced; Journey is where learners take it. The released version is the contract between the two. It holds everything Journey needs to deliver the course (structure, lessons, checks, remediation, milestones) as one snapshot, and Journey reads nothing else. Content authoring never flows through Moodle: Moodle only links to released courses (see Integration — Moodle & LTI).
Items in a version are keyed by stable lesson and knowledge-component identifiers, so a learner's records survive when a later version improves the course.
From signing to live
- The owner signs. The course owner compiles and signs the final report. Signing submits the course to the Dean as a frozen version that no learner sees. Signing is refused if the course has no milestones, or if any milestone is not approved (each one is named so the owner can finish it on the Milestones page), and if the course has changed since the report was compiled.
- The Dean decides. The Dean of the course's school, or IT Admin, reviews the course read-only with the final report, open comments and a summary of what changed since the last released version. They either return it to the course team with a reason, or release exactly that version. A Dean releasing a course they worked on is allowed and recorded as self-released.
- Live in Journey. The released version becomes the live version and the previous one is superseded. The course then waits in IT's "Ready for Moodle" queue until it is added to Moodle and first linked or launched ("Live in Moodle").
Every version goes through the Dean, the second and third included. Open reviewer comments do not block submitting; the Dean sees them in the review.
The Release board
The Release board shows where every course stands, in five columns:
IT Admin acts on "Ready for Moodle". The Academic Lead and Deans see the board read-only. Who may do what is covered in Standard LMS & Roles.
What a released course contains
Every course is built by the Lead Designer, so every released course has the same shape:
| Contents | What it carries |
|---|---|
| Course record | Course identity and title, the version number, the learning path (subtopics in order), lesson and check counts, the milestones and the outcomes each covers, and the course credential where one is set. |
| Lessons | One lesson per subtopic stop, following the Lesson Page Standard in reading order: the Storyline's open, each part's narrated video and "Read instead", its card and "Try it", the Pause moments, the close and the carry-forward to the next lesson. |
| Checks and variant pools | Each lesson's check, with only its approved variants, so a learner trying again meets a fresh question. The check records which lesson part it tests. |
| Remediation pieces | What the learner's result can lead to: the firm-up prompt, each second way in, the worked example, and, where the check has a bound mix-up, its mix-up message and "Look again". These are delivered per learner, never as part of the linear lesson. |
| Misconception bindings | The registry entries for the tempting errors each lesson's check scores against. |
| Milestones | Each approved milestone with its weight, its rubric and its approved build pack, frozen with the version, so an edit or a rename in Studio reaches learners only through the next release. |
Nothing in a lesson gives away an answer the learner has not earned: the check's key, rubric and feedback stay with the check and are sanitised before Journey draws them.
A version is one course_publications row (course code, version, status, and a manifest) plus publication_items, each with an item_kind and a stable key. Lead Designer courses emit course_meta, node, lead_designer_lesson, interactive_instance (the check), variant_pool (approved variants only), reserved_remediation (firm_up_prompt, learn_another_way, worked_example), lead_designer_look_again, misconception_binding, milestone, milestone_rubric and milestone_pack. A milestone carries grade_weight (0–1) and approval_status; only approved milestones let the owner sign. Statuses are preview, submitted, returned, published, superseded and archived. Contracts live in @maestro/shared.
Publishing refuses unfinished lessons
A version cannot go to learners while the course is unfinished. Publishing refuses when the validation report is missing, unapproved or out of date, or when the subtopic architecture is not approved. It also refuses, in plain words naming each lesson held back, when a lesson has no expected minutes, no design, no produced check, or a required remediation piece that is not produced: the firm-up, each second way in, the worked example, and, where the check has a bound mix-up, the mix-up message and "Look again". A staff preview is exempt, because it exists to show work in progress; a preview never becomes the live version.
Versioning & rollback
Once released, a version is immutable. Any change to the course produces a new version, signed by the owner and released by the Dean like the first. Rollback makes an earlier version live again; because versions are frozen snapshots, nothing is rebuilt. Only a version that was released can be made live again: a submitted, returned or preview version never reaches learners through a rollback. Rollback is an IT Admin action, and the live version cannot be archived.
Each enrolment is pinned to a version: either it follows the latest released version or it stays on a pinned one. Because items are keyed by stable lesson identifiers, a learner's records carry across later versions, and milestone rubrics and build packs are read from the learner's own version rather than from Studio's working copy.