MaestroMaestro Overview — contents
The Concept
Studio · Course Engineering
Maestro Studio (Curriculum Engineering) is the authoring tool that turns a standard university syllabus into a finished, adaptive, AI-native course. This is the first of Studio's two halves — it re-engineers the academic structure of the course before any node is built.
A professor uploads a syllabus PDF (usually around five CLOs) and Studio builds a fully digitized adaptive course from it, with no separate content vendor. It runs in two phases the SME approves stage by stage: Course Architect (six steps — this topic) and the Node Engine (five steps — the next topic). At each stage a panel of AI models — the LLM Council — reviews the work and writes a report with citations, and a human SME must approve before it advances. Studio is out of scope for the dev team to build; its output is consumed as input. Understanding it is what makes the hand-off make sense.
You will not build Studio. But everything Studio produces arrives in the Published Course Package your runtime consumes, and the node metadata Studio writes ("node DNA") is exactly what drives adaptivity at runtime. Read this to know what each field means and why it exists, so the runtime honours it correctly.
The authoring tool (a prototype)
Maestro Studio is a working proof of concept — a prototype, not production-grade software. It proved the concept well enough to win HBMSU's commitment, and it is the source of authored courses, but the dev team should treat it as the reference for how the concept works and the source of exported courses, not as code to build on. The whole Course Engineering phase belongs to the-code and is not rebuilt by the dev team.
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 digitize that. It does not turn Week 1 into Module 1. Instead it re-engineers the course, stage by stage, 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 structure broken into subtopics and the mastery nodes the Node Engine produces.
Throughout Studio the reference course is MDLD602 — Leadership of Innovative Curriculum Design and Instruction: a postgraduate, 3-credit-hour course with five official CLOs and four assessment components. Every worked example in this documentation traces back to it.
Course Architect — the six steps
Course Engineering runs as a governed pipeline. Each step is an SME gate: nothing advances until a human approves it. The nodes only get built once outcomes, assessments, and integrity are settled — so a node always traces back to a real, refined outcome.
| Step | What it does | Output the SME approves |
|---|---|---|
| 1 · Course Intake & Syllabus Extraction | Extracts the existing academic structure — title, code, level, credit hours, official CLOs, assessment components, weekly plan, readings, risks. It redesigns nothing yet. | Course Intake Summary |
| 2 · CLO Quality Review & Refinement | Reviews whether the official CLOs are strong enough to drive adaptive learning, and refines them with the SME. | Refined CLOs |
| 3 · Assessment Redesign for Contribution | Redesigns each assessment into an authentic, context-specific contribution artifact. | Assessment Redesign Report |
| 4 · Assessment Structure, Weighting & Rubric | Revisits weights, rubric criteria, process-evidence requirements, and grading policy for the new artifacts. | Structure & Rubric Decision Report |
| 5 · Assessment Integrity & Active AI Use | Designs each assessment so AI can support the learner but cannot replace their thinking. | Integrity & AI-use requirements |
| 6 · Self-Paced Subtopic Architecture | Breaks each refined CLO into learning territories (subtopics) that prepare the learner for the redesigned assessments. | Subtopic Architecture |
traditional syllabus → refine CLOs into a connected journey → redesign assessments as contribution → secure AI integrity → build subtopics → generate Mastery Nodes. Nodes are the end of Course Engineering, not the beginning.
Refining CLOs into a connected journey
A CLO (Course Learning Outcome) is a statement of what a learner should be able to do by the end of a course — the intended destination of learning. Official CLOs 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 the official CLOs as the accreditation starting contract and works with the SME to refine them into an operational foundation — sharpened, not replaced.
Each CLO is evaluated against clarity, cognitive demand, scope, assessability, context of application, alignment with the course, relationship to other CLOs, progression, expected evidence of mastery, and — critically — adaptivity readiness (can this outcome support subtopics, nodes, evidence, misconceptions, and adaptive decisions?).
The five refined CLOs form a coherent arc: Critique → Evaluate → Design → Integrate → Reform. Each refined outcome traces forward into the subtopics and nodes that prepare a learner to demonstrate it.
Redesigning assessment as contribution
If CLOs define the destination, assessments define the evidence of meaningful achievement. In Maestro the nodes 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 artifact.
| Traditional model | Maestro model |
|---|---|
| Student writes paper → professor reads → grade assigned → paper disappears. | Student builds mastery → reaches readiness → creates a useful artifact → receives academic evaluation → may convert it into a verified contribution that a community, institution, or industry can use. |
The defining principle is personalise the context, not the rigor. All learners may build the same artifact type against the same rubric — say a Curriculum Reform Readiness Toolkit — but one applies it to a public school, another to a corporate training environment. The academic standard stays identical; the context, audience, constraints, and use case are personal. (This is also a core integrity mechanism — see Academic Integrity.)
| Same for all learners (fixed core) | Personalised per learner |
|---|---|
| Refined CLO alignment · assessment concept · required capability · rubric criteria · minimum academic standard | Learner context · audience · constraints · scenario details · artifact format · contribution pathway |
The MDLD602 redesign turned four traditional assignments into contribution artifacts: a Verified Curriculum Framework Decision Brief, a Curriculum Implementation Improvement Sprint, an AI-Enabled Curriculum Intervention Prototype, and a Curriculum Reform Readiness Toolkit — each something a real school leader, designer, or training manager could actually use.
The redesigned assessments arrive as Milestone Assessment Pack Contracts in the course package (one per summative milestone; four for MDLD602). Each has a static layer (brief, rubric, AI-use rules, node-preparation map) identical for every learner, and a dynamic readiness logic layer the runtime evaluates against a specific learner's model to decide submission unlock. The contract defines the logic; your runtime applies it per learner. See Mastery & the Knowledge Check and Adaptivity & Routing.
Assessment integrity & active AI use
This step 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 judgment, context, decisions, process, reflection, evidence, ownership, and accountability.
| 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 judgment, context, evidence, and final decisions. |
Integrity is carried by design layers baked into the task: personal-context anchoring (requires a real or realistic learner context), process checkpoints, a decision rationale, an evidence trail, AI-use transparency, and a reflection or defense. The question shifts from "did you use AI" to "did you exercise your own judgment and disclose it meaningfully."
What did AI help with? · What did you use? · What did you reject? · Why did you reject it? · What did you personally decide? These fields make the learner's own thinking visible at every step, and they feed the integrity model described in Academic Integrity.
The Digital Library & grounding
"Grounding" is how Maestro keeps AI-generated content academically honest. An admin loads reference material once — the course's textbook and readings — into a Digital Library. That material is chunked and reused as the grounding source: when Studio generates a node, the academic content is anchored to approved passages, not invented by the model.
The reference material is the academic anchor, not the full script. Three levels: must be anchored — core concepts, theories, terminology, frameworks, major claims; can be extended — examples, scenarios, misconceptions, evidence checks, bridges, feedback; must not contradict — no extension may contradict the textbook, CLO, assessment, or approved structure.
The retrieval architecture is deliberately layered, because naive similarity search fails on academic text (an off-topic book can score ~0.95 on vocabulary overlap alone). Studio uses:
- Contextual embeddings — each chunk gets a short context header (its source, chapter/section, and role) prepended before it is embedded, so a passage torn out of the book keeps its meaning.
- Hybrid search — semantic (embedding) retrieval plus keyword/BM25, because courses use exact terms (framework names, theorists) that pure similarity misses. Agreement between both signals is a much stronger trust signal than either alone.
- Subtopic-direct anchoring — each subtopic is anchored to its best-matching passages and produces a reviewable evidence pack with a confidence band (strong / moderate / weak). "No anchor found" is a legitimate, honest outcome.
- A coverage check — after CLOs are approved, a model judges whether the corpus actually teaches each CLO (well / partial / thin / none), not just whether it mentions related vocabulary. This is the safeguard that catches a wrong or insufficient reference corpus early.
Every produced object carries a grounding_strength (strong | weak) and its grounding source (anchor | course_level | model_only) in its envelope. Two distinct operations exist and are never conflated: coverage/adequacy (does the corpus cover each CLO? — a read-only measurement, writes no tags) and reference alignment (which passages anchor each subtopic? — the only place chunk-to-subtopic tags are written). A node set is academically approvable only when it shows reference grounding, or a human explicitly accepts weak/no grounding with a recorded reason.
Subtopic architecture
After CLOs and assessments are settled, Studio creates the subtopics — the learning territories a learner moves through to reach a refined CLO and prepare for its assessment. A subtopic is not a copied week, a reading title, or an activity name. It is a major learning territory under a refined CLO that organises the concepts, skills, judgments, applications, and evidence needed to achieve that CLO in a self-paced experience.
The weekly plan is treated as an input (scope evidence), never as the structure. MDLD602's six CLOs expand into eighteen subtopics; under Refined CLO 1, for example, subtopics include the foundations of curriculum design, major frameworks, the assumptions behind them, criteria for evaluating them, contemporary trends, and contextual relevance across in-person, online, and hybrid environments.
Mastery Nodes & their DNA
Course Engineering ends by generating Mastery Nodes from each subtopic. A node is the atomic unit — roughly one lesson — targeting a single Knowledge Component (KC): one concept, skill, judgment, or misconception the learner must develop and that Maestro can make an educational decision around. (What a node is, its eleven types, and how it becomes content are the subject of the next topic.)
Each node carries the metadata the-code calls its "DNA" — and this is the metadata the runtime reads to drive adaptivity:
| DNA field | What it carries |
|---|---|
| Knowledge Component | The single concept the node teaches. |
| Mastery statement | What the learner must be able to demonstrate. |
| Node type & ID | The cognitive job of the node (one of eleven types) and its stable identifier. |
| Dependencies | Prerequisites, bridges, and thresholds — how it connects to other nodes. |
| Assessment connection | Which milestone assessment this node prepares for. |
| Misconception bindings | Likely wrong models, with detection signals (see the misconception library). |
| Risk flags | Critical / bridge / high-risk markers that raise the governance and evidence bar. |
The LLM Council & SME gates
Everything in Studio is AI-generated; humans govern at defined gates. The governance mechanism is the LLM Council: multiple AI reviewers examine the same object through different professional lenses — never identical voters, which would share blind spots — and a Chairman consolidates their reviews into one report with citations. An SME then approves before the work advances. The deck's phrase captures it: AI accelerates, humans govern.
The Council runs at the foundational stages (CLOs, assessments) and again, in two passes, around node production — once on the design (blueprint) and once on the produced content. Its lenses and reliability principles are detailed in Academic Integrity; the full roster appears in the Nodes Engine.
The Admin Center
Studio also includes an Admin Center — the operational controls behind the authoring tool. It manages accounts and roles, per-course access, model and prompt settings, grounding settings (which reference corpus a course uses), and an audit log of governance actions. For the dev team this matters because the runtime governance metadata in the course package (pinned prompt-template versions, the misconception-library slice, the reference-corpus slice) originates from these settings — the runtime must honour the exact versions the course was authored against, not the newest available.