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 the runtime. It is a versioned, immutable package delivered via API — a real contract between two systems, not an internal export.
The hand-off is neither a file drop nor a shared datastore. Studio publishes a versioned, immutable Published Course Package via API; the Adaptive Learning System consumes it. Once published, a version is never mutated — regeneration produces a new version, and reassembly always pulls the approved live version. The package is the static authored artifact; your runtime executes it against a specific learner.
The hand-off contract
When a course is finished in Studio it moves to the Adaptive Learning System over an API. Treat this as a real contract between two systems. Studio (Curriculum Engineering) publishes; the runtime consumes. The package is the authored, static artifact Studio produces once per course version; the runtime is what executes it against a specific learner. This boundary is the most important one in Maestro — everything downstream depends on honouring it.
The ten contents of the package
| # | Contents | What it carries |
|---|---|---|
| 1 | Course academic contract | Course identity, refined CLOs, assessments (redesigned for contribution), structure & weighting, rubrics, integrity and active-AI-use rules, the self-paced subtopic architecture. |
| 2 | The node graph | Every mastery node with its full DNA: the Knowledge Component, mastery statement, node type, dependencies (prerequisites, bridges, thresholds), the assessment it prepares for, misconception bindings with detection signals, critical/bridge/high-risk flags, and routing rules for the diagnostic bands. |
| 3 | Per-node experience design | Each node's approved Node Experience Blueprint (Level 1 — the object sequence, purposes, vehicles) and Content Specifications (Level 2 — the academic source-of-truth per object, with preservation rules and grounding references). |
| 4 | Produced learning objects (Level 3) | The actual assets in every modality (text, structured visual, video, interactive, simulation specs where relevant), each wrapped in a common envelope. |
| 5 | Evidence Check contracts | The primary Evidence Check for each node — a distinct object with a stable LMS tracking key, flagged as the official learner-model-updating and routing-feeding object. This is what LTI-AGS binds to. |
| 6 | Milestone Assessment Pack Contracts | One per summative milestone (four for MDLD602). Each has a static pack (brief, rubric, AI-use rules, support objects, node-preparation map, evidence-check map, misconception blockers) identical for every learner, plus dynamic readiness logic the runtime evaluates per learner to determine submission unlock. |
| 7 | Learning Anchors | Authored, bounded in-journey guidance — either fully authored, or runtime handoff templates the live Companion composes against within the anchor's boundary. |
| 8 | Interactive template profiles & instance specs | Template definitions (form schema, supported purposes, evidence-check capability, accessibility & approval status, reuse scope) plus each instance's form values and evidence role. |
| 9 | Runtime governance metadata | Prompt-template versions to pin at runtime (so the Companion behaves deterministically against the authored version), the misconception-library slice the course depends on, and the reference-corpus slice grounding was validated against. |
| 10 | Privacy & export boundary flags | Every object carries its LMS-export rule — only high-level status leaves toward the LMS; learner reasoning, misconception flags, confidence and process signals stay inside unless the institution explicitly authorises otherwise. |
Every Level 3 object arrives in a common envelope carrying: identity, parent references, object family & purpose, produced modality, content & modality-specific fields, grounding references & grounding_strength, the prompt_template ID and version used, generation mode, governance_status, an asset reference, and the fidelity-check block. Versioning is part of the envelope, not an afterthought. Evidence-check objects additionally carry feeds_routing, updates_learner_model, is_primary_evidence_check, and per-band band_routing.
Delivery mechanism & caching
Studio exposes a publishCoursePackage action that produces a signed, versioned package. The Adaptive Learning System calls fetchCoursePackage(course_version_id) at deployment time — not per-learner, per-session. The package is cached in the runtime once and used by every learner in that cohort. This keeps the runtime fast and the authored artifact stable across a cohort.
Five open items
Five items on the package spec are still being resolved and will be delivered closed before the build starts against the package. They are flagged now so nothing is a surprise — everything else above is settled and can be built against.
| Open item | What it will pin down |
|---|---|
| Course-level release manifest | The top-level document naming the version, listing every included object with checksums, and declaring which prompt-template versions are pinned. |
| Runtime judge pinning | The exact contract for how the live Companion binds to the same judge and prompt versions the course was authored against. |
| Asset delivery contract | How large binaries (video, images, interactive bundles) are referenced, hosted, and cached vs. inlined in the package. |
| LMS binding key | The stable key format the primary Evidence Check exposes for LTI-AGS line-item binding. |
| Learner-visibility flags | The object-level flag declaring whether an object is learner-facing, SME-facing, or system-only. |
Versioning & rollover
Once published, a version is immutable. Any republish produces a new immutable version; regeneration never mutates a version in place. The Adaptive Learning System decides its own rollover policy — which cohorts move to a new version and which stay on the old — so live learners aren't disrupted mid-course. This pairs with the continuous-delivery model (governed vs. expressive fields, object-ID persistence across versions, learner-level version pinning) that keeps a running cohort stable while the course keeps improving.