MaestroMaestro Overview — contents
The Build
Standard LMS & Roles
Beyond the adaptive experience, Maestro does the ordinary work of an LMS: accounts, roles, schools and programmes, enrolment, progress and grade records. This topic covers the six roles, how access to a course is decided, and how Moodle roles map onto Maestro.
Every person has exactly one role: IT Admin, Academic Lead, Dean, SME, Registration or Student. A role says what someone may do at all; their scope says where. On a single course, rights also come from the person's relation to it: owner, co-author or reviewer. Deans are scoped to their school, Registration to the programmes or courses assigned to them. No staff role, IT Admin included, can read a learner's Atlas conversations.
The LMS as a system of record
Maestro holds its own accounts, roles, schools, programmes, enrolments, progress and grade records as real primitives in its own data model. Moodle remains the place learners are enrolled; LTI roster sync keeps Maestro's enrolments in step (enrolled, deferred, withdrawn, completed). See Integration — Moodle & LTI.
Two progress measures are shown side by side and never merged: lesson progress (the share of a course's lessons completed) and the assessment grade (the average of the milestones completed so far, always shown with how many are done, for example "78% · 2 of 4 assessments").
The six roles
| Role | Scope | What they can do |
|---|---|---|
| IT Admin | Everything | The Admin Center (users, single sign-on, LTI, models, prompts, audit, health). Create courses, assign course staff, manage schools, programmes and Registration scopes. Author, read and comment on any course, submit and release. Act on the Release board and add released courses to Moodle. Approve Digital Library books. Learning analytics and governance across all courses. |
| Academic Lead | All schools, all courses | Create courses, assign course staff, manage schools and programmes. Read every course and comment, without editing, submitting or releasing. See the Release board read-only. Learning analytics, enrolment and progress, and governance across all courses. |
| Dean | Their school, plus courses they work on | Manage and review the school's courses: read, comment, return to the course team, and release. Analytics, enrolment and progress for the school. Also everything an SME can do on courses where they are owner, co-author or reviewer. No Admin Center. |
| SME | Courses they work on | Create courses, then author, read, comment and (as owner) submit on the courses they work on. Governance tools for their own courses, such as the misconception registry. Sees generation progress, not student progress. |
| Registration | Assigned programmes or courses | Student enrolment, progress and last activity (never marks) for their scope, and the Registration desk. No course content. |
| Student | Their own enrolments | Journey only. |
Anyone in an authoring role (IT Admin, Academic Lead, Dean, SME) can create a course; the creator becomes its owner. Studio menus and routes are built from each role's capabilities, and the Academic Lead and Deans review courses in a read-only mode.
Course staff
| Relation | On the course |
|---|---|
| Owner | Exactly one per course. Edits the content, and is the only person who submits the final report to the Dean. |
| Co-authors | Edit the content alongside the owner. |
| Reviewers | Read the course and leave comments; they do not edit. |
Comments are anchored to the part of the course they concern, and every comment creates a notification. Open reviewer comments do not block the owner from submitting. Release itself belongs only to IT Admin or the Dean of the course's school; every version goes through the Dean. The flow is described in The Published Course Package.
Schools & programmes
Every course belongs to a school, and each school has one Dean, so a course has a Dean from the day it is created. The Dean of a course is always the Dean of its school; it is not stored on the course. Programmes group courses for enrolment and progress reporting, and Registration staff are scoped by programme or by course. IT Admin and the Academic Lead manage schools, programmes and these scopes.
Moodle role mapping
Moodle roles never grant higher Maestro roles. On a launch:
- Moodle's Instructor, Administrator and Content Developer roles are treated as staff; every other role is a learner.
- A first-time learner is created as a Student. A first-time instructor is created as an SME with no course access until assigned to a course.
- A returning identity keeps its Maestro role. IT links staff institutional identifiers to their Maestro staff accounts in advance, so a Dean or Academic Lead arriving from Moodle signs in with their own role.
- Roster sync counts only members with a learner role.
The Registration desk
Enrolment happens in Moodle, so Registration has no enrolment actions. Instead, the Registration desk gives Registration staff a list of cases for the learners in their scope (for example, learners who have gone quiet, or contact requests raised from Journey), each with a response target. Staff work a case by adding notes and by sending the learner a message, which arrives in the learner's Atlas dock, where the learner can reply. The Academic Lead and Deans see a read-only view of the desk within their scope.
No staff role, IT Admin included, has any way to read a learner's conversations with Atlas. This is enforced in code and tests, not only by convention. Staff messages to learners travel one way through a deliberately narrow channel.
The role list (it_admin, academic_lead, dean, sme, registration, student) and the role-to-capability table live in one place in @maestro/shared; the backend guard, the database constraint and the Studio menus all read it. Capabilities say what; one course access resolver says where, returning content access (edit, comment or none) and progress access from role, course_staff relation, school and Registration scope. Every list and aggregate endpoint takes its scope from the resolver; nothing filters on the client.