Scope of Collaboration

What the dev team builds, what it consumes, and the one architectural instruction that shapes release one: build the LMS layer as a real system of record from day one, with LTI in front of it — not as a Banner/SIS pass-through shim.

The 30-second version

In scope: the Adaptive Learning System (Maestro Journey) — rendering authored courses, the in-course AI Companion, adaptive mastery-based delivery, the standard LMS foundations, and LTI. Out of scope: Curriculum Engineering (Maestro Studio) — it already works and belongs to the-code; its output is consumed as input. For January, integration is LTI-embedded, but the LMS layer is built as a genuine system of record from day one.

In scope — the Adaptive Learning System

The dev team builds Maestro Journey: the student side that takes a finished course and runs it for learners. That means:

Rendering the authored course — the nodes and every format in them (video, text, interactive) exported from Studio.
The in-course AI Companion.
Adaptive delivery with mastery-based progression — holding a learner at a topic until mastery is shown, routing back if not, and letting them set their own pace.
Running and grading assessments with AI, since the whole experience is self-paced.
The usual LMS foundations — accounts, roles, permissions, student management, reporting (see Standard LMS & Roles).
LTI, so it plugs into the university's existing LMS (see Integration).

Out of scope — Curriculum Engineering

Maestro Studio is not built here. It already works, and it belongs to the-code. Its output — the Published Course Package — is consumed as input and advised on, but not rebuilt. (The Studio topics exist so the dev team understands what that output means.) The team is also expected to study the Studio MVP and its code, advise on how to build the student side and which formats fit, and specify what to add at authoring time so it can be used later.

Later stages

Two parts are explicitly later-stage and not in the release-one build: Academic Intelligence (Maestro Pulse — the dashboards) and the Refinement loop (Maestro Compass — feeding insight back to SMEs). A foundational academic-intelligence layer (a basic learner pulse) is in release one; the full analytics and refinement workflows come in later phases.

LTI now, system of record from day one

For the January cohort the answer is LTI-embedded, not a standalone platform students log into separately. This mirrors the earlier pilot: LTI minimises disruption to the university's existing ecosystem — Banner for the course catalogue, the SIS for student identification, the registration layer, the gradebook. For a live cohort launch, disturbing any of those layers is not an option, so LTI is the right integration surface for release one.

The consequential architectural instruction

The longer-term intent is that the university progressively retires those layers and bases the ecosystem on Maestro itself. So the Adaptive Learning System must be architected from day one as a genuine system of record — with its own accounts, roles, roster, enrolment, and gradebook data model — with LTI sitting in front of it as the January launch and sync mechanism, not as a pass-through shim. A shim treats Banner/SIS as the source of truth and borrows identity per session; a system of record holds its own primitives and uses LTI claims to populate and sync them. The first is cheaper to build and expensive to unwind; the second is the correct foundation.

For engineers — the export boundary is already a design constraint

Only high-level status (completion, score, readiness) leaves Maestro toward the LMS. Detailed learner reasoning and misconception data stay inside the adaptive system regardless of integration depth. Build to that boundary from the start — it is not a later privacy retrofit. See Integration and Learning Signals.

Engagement approach (build on / rebuild)

Because Studio is a prototype, nothing is locked into it: the student side can be built on top of it or rebuilt from scratch if that is the better call — and either way the product is the-code's. The work is expected to be iterative: study the MVP, advise on the build and which formats fit, start with the obvious flows, and widen from there. The trust layer is a specific case of this — the-code's existing IP that the team assesses and decides to integrate against or partly rewrite.