MaestroMaestro Overview — contents
The Concept
Studio · Course Design
Maestro Studio is where faculty turn a standard university syllabus into a finished, adaptive, AI-native course. It has two halves on one path: Course Design re-engineers the course's academic structure, and the Lead Designer plans, designs and produces its lessons. This topic covers Course Design, the people who run Studio, and how a course is signed and released.
A professor uploads a syllabus and Studio takes it through six ordered reviews: Course Intake, Learning Outcome Review, Assessment Design, Rubric and Weighting, Academic Integrity, and Topic Architecture. AI drafts each one; faculty approve it before the next opens. Approving the last review hands the course to the Lead Designer, which builds every lesson from the course's approved sources. When the lessons and milestones are ready, the course owner signs the final report and the Dean releases it to learners. There is no direct publish.
Everything Studio produces arrives in Journey as a released course version: frozen, immutable, and read by the runtime exactly as signed. Read this to know what each part of that version means and why it exists. Course Design lives in the authoring module (routes under /api/courses/:code/design/**); where a course stands in the authoring journey is served only by GET /api/courses/:code/authoring-workflow, never re-derived on the client.
One path, two halves
The premise is simple to state and hard to do well: a university syllabus is written for a teacher in a room — lectures, weeks, a final exam. Studio does not digitise that. It does not turn Week 1 into Module 1. Instead it re-engineers the course, review by review, into something a learner can move through alone with an AI: outcomes rewritten as a connected journey, assessments redesigned as authentic contributions, AI integrity built in, and only then the course broken into topics that the Lead Designer turns into lessons.
| Half | What it does | Ends with |
|---|---|---|
| Course Design (this topic) | Six ordered reviews from syllabus to topic architecture, each approved by faculty. | An approved topic architecture, handed to the Lead Designer. |
| Lead Designer (next topic) | Divides the sources across topics, plans the lesson calendar, designs each lesson to one standard and produces it. | Produced lessons, ready for the final report. |
Studio makes two kinds of course. A New academic course starts from a syllabus and runs the six reviews below. A New training course starts from existing material instead (a material map, a brief and a course contract) and goes to the same Lead Designer — this is the path behind Maestro Swift.
The six reviews
Course Design runs as a governed sequence. Each review is a faculty gate: the next review stays locked until the current one is approved. Faculty can edit a draft, ask for it again, or approve it.
| Review | What it does | What faculty approve |
|---|---|---|
| 1 · Course Intake | Extracts the existing academic structure from the syllabus — title, code, level, credit hours, prerequisites, official learning outcomes, assessment components, weekly plan, delivery and initial risks. It redesigns nothing yet. | Course Intake Summary |
| 2 · Learning Outcome Review | Reviews whether the official outcomes are strong enough to drive adaptive learning, and proposes refined outcomes. | Refined learning outcomes |
| 3 · Assessment Design | Redesigns each assessment into an authentic, context-specific contribution, aligned to the refined outcomes. | Assessment redesign |
| 4 · Rubric and Weighting | Revisits weights, rubric criteria, process evidence and grading policy for the redesigned assessments. These weights drive the milestone report and the Moodle gradebook columns. | Structure, weighting and rubric decision |
| 5 · Academic Integrity | Designs each assessment so AI can support the learner but cannot replace their thinking. | Integrity and active-AI-use rules |
| 6 · Topic Architecture | Breaks each refined outcome into self-paced learning territories (topics) that prepare the learner for the redesigned assessments. | Topic architecture — approving it hands the course to the Lead Designer |
traditional syllabus → refine outcomes into a connected journey → redesign assessments as contribution → set weights and rubrics → secure AI integrity → build topics → the Lead Designer makes the lessons. Lessons are the end of the path, not the beginning, so every lesson traces back to a real, refined outcome.
Each review is drafted by an AI model chosen in the Admin Center. A review can run on a single model, or as a council: several models examine the same draft through different professional lenses and a chairman model consolidates their views, including where they disagree and what they could not judge. Either way, a person approves. The phrase that captures it: AI accelerates, humans govern.
Refining learning outcomes
A learning outcome (a CLO, Course Learning Outcome) is a statement of what a learner should be able to do by the end of a course. Official outcomes are written for accreditation, and may be broad, outdated, or not strong enough to drive adaptive design. So Studio does not blindly consume them. It treats them as the accreditation starting contract and works with faculty to refine them — sharpened, not replaced.
Each outcome is evaluated for clarity, cognitive demand, scope, assessability, context of application, its relationship to the other outcomes, progression, the evidence that would show it, and — critically — adaptivity readiness: can this outcome carry topics, lessons, checks and the mix-ups learners are likely to make? The refined outcomes become the lanes of the learner's course road in Journey.
Assessment as contribution
If outcomes define the destination, assessments define the evidence of meaningful achievement. In Maestro the lessons already build and check understanding, so formal assessments are freed to become something better than a knowledge-retention test: an opportunity to apply learning and produce a useful piece of work.
| Traditional model | Maestro model |
|---|---|
| Student writes paper → professor reads → grade assigned → paper disappears. | Student works through the lessons → reaches the milestone → chooses a world → builds a useful piece of work → defends it aloud → receives a weighted report. |
The defining principle is personalise the context, not the rigour. All learners build the same kind of work against the same rubric, but each chooses a different world to apply it in. The academic standard stays identical; the context, audience and constraints are personal. (This is also a core integrity mechanism — see Academic Integrity.)
| Same for all learners (fixed core) | Personalised per learner |
|---|---|
| Outcome alignment · assessment concept · required capability · rubric criteria and weights · the spoken defense | The world chosen · audience · constraints · scenario details |
The approved assessment designs become milestones, built on Studio's Milestones page and approved by faculty. A course cannot be signed until its milestones exist and every one is approved: the final report's compile refuses otherwise and names each missing milestone. In Journey each milestone is entered through its Milestone Guide; over LTI each approved milestone gets its own gradebook column with its weight. See Mastery & the Knowledge Check and Integration.
Integrity & active AI use
This review is not a proctoring add-on — it is Maestro's integrity strategy, built in at design time. Maestro does not ban AI or pretend it doesn't exist. It designs assessments for active, transparent, accountable AI use, so AI can support the learner but cannot replace their judgement, context, decisions, process, evidence and ownership.
| Passive AI use (designed out) | Active AI use (designed for) |
|---|---|
| The learner asks AI to produce the assessment and submits it with little thinking. | The learner uses AI to brainstorm, structure, compare options or test ideas — but remains responsible for judgement, context, evidence and final decisions. |
Integrity is carried by design layers baked into the task: personal-context anchoring (the world the learner chooses), process evidence (autosaved versions and a daily work log), a decision rationale, AI-use transparency, and the spoken defense, where the learner answers live questions about their own locked work. The question shifts from "did you use AI" to "did you exercise your own judgement and can you explain it."
Sources & grounding
"Grounding" is how Maestro keeps AI-written content academically honest. Reference material — textbooks, readings, documents, web pages — is loaded into the Digital Library, where it is split into sections and indexed. Once the outcomes are settled, faculty choose the course's sources from the library and Studio measures their coverage against each refined outcome, so a thin or wrong set of sources is caught before any lesson is written. Faculty approve the sources too.
The sources are the academic anchor, not the full script. Core concepts, theories, terms, frameworks and major claims must be anchored in them; examples, cases and practice can be extended; and nothing may contradict the sources, the outcomes, the assessments or the approved structure.
Retrieval is deliberately layered, because naive similarity search fails on academic text (an off-topic book can score high on vocabulary overlap alone). Each section keeps its source and place in the document; search combines semantic and keyword matching, because courses use exact terms that pure similarity misses; and coverage is judged on whether the sources actually teach each outcome, not whether they mention related words.
From there the Lead Designer divides every section of every source across the topics. Where a topic owns nothing, Fill this gap lets the AI search for reputable open sources and write a reading for it; faculty review and approve that reading before it is used.
Topic architecture
The last review creates the topics (subtopics, in Studio's words) — the learning territories a learner moves through to reach a refined outcome and prepare for its assessment. A topic is not a copied week, a reading title or an activity name. It is a major territory under one outcome that organises the concepts, skills, judgements and applications needed to achieve it in a self-paced course.
The weekly plan is treated as an input (evidence of scope), never as the structure. The number of topics follows the course's size: a budget set from its credit hours, shared across outcomes in proportion to the professor's weeks. In Journey, each topic becomes a stop on the course road. Approving Topic Architecture is the hand-off: the Lead Designer then divides the sources and plans the lessons.
Studio roles & course staff
Studio has six roles, one per person. What a person can do on a course comes from their role, their relation on that course, and the course's school.
| Role | In Studio |
|---|---|
| IT Admin | Everything, plus the Admin Center. Can release a course and adds released courses to Moodle. |
| Academic Lead | All schools and courses: creates courses, assigns staff, reads and comments, sees academic dashboards. |
| Dean | Manages the courses of their school: reads, comments, returns a course to its authors, or releases it. Can also author as an owner or co-author. |
| SME | Authors and produces the courses where they are owner or co-author; comments where they are a reviewer. |
| Registration | The Registration desk for the programmes assigned to it: cases, contact requests and messages to learners. |
| Student | Journey only. |
Each course has course staff: exactly one owner, any number of co-authors who edit, and reviewers who read and comment. Comments are anchored to the part of the course they are about, and every comment raises a notification. Courses belong to schools and programmes, which is how a Dean's scope is set. No staff role can read a learner's Atlas conversations.
The roles and their capabilities are defined once in the shared package (roles.ts, ROLE_CAPABILITIES). Routes gate with requirePermission(capability) and course access with requireCourseAccess, which derives edit, comment or no access from the role, course_staff, the course's school and the Registration scope. Never compare role strings and never filter scope on the client.
Sign & Dean release
When the lessons are produced and the milestones approved, Studio compiles a final report: the validation account of the course as it stands. The course owner signs it, and signing submits the course to the Dean of its school.
The Dean (or IT Admin) either returns the course to its authors with comments, or releases the signed, frozen version. A released version is live and immutable in Journey; changes mean a new version through the same path. A Release board shows every course in reach, from with its authors to live in Moodle. A rollback can only return to an earlier released version. There is no direct publish.
The Admin Center
The Admin Center is IT Admin's set of operational controls behind Studio and Journey: users and roles, single sign-on, course access, Moodle (LTI) settings, Digital Library approvals, retrieval settings, AI usage, course versions, system health and an audit log of governance actions.
| Control | What it governs |
|---|---|
| Model catalogue | Every model Maestro uses is chosen here from a catalogue — per review, per Lead Designer prompt, per job. No model is hard-coded. |
| Prompt registry | Every prompt is versioned and approved. A run uses only an approved version; a placeholder or archived prompt is refused, and the block waits. |
For engineers this matters because produced lesson blocks record the prompt version that wrote them, and a released version is frozen: learners stay on the version they took, and a newer prompt only reaches them through a new version, signed and released again.