Standard LMS & Roles

Beyond the adaptive experience, the runtime has to do the ordinary work of an LMS — a substantial part of the build, not a footnote. This topic covers those foundations, what must ship in release one, and the roles that use the student side.

The 30-second version

The Adaptive Learning System must also handle accounts, roles, enrolment, gradebook, reporting, and the security a university deployment requires — built as a real system of record, not a shim. Release one includes what's needed to enrol students, run the adaptive core, and prove it works; it defers what merely enriches. Six roles use the delivery side, and the SME's delivery role is deliberately separate from their Studio authoring role.

The LMS as a system of record

Most of this is standard, deterministic engineering — but it is real work and a meaningful share of the effort. The runtime owns:

accounts and authentication · roles and permissions · student and cohort management · enrolment · course and content administration · progress and grade records · reporting and analytics · and the security and data handling a UAE higher-education deployment requires.

These are held as real primitives in Maestro's own data model (populated and kept in sync via LTI/NRPS), not borrowed per-session from Banner/SIS. Enrolment carries proper semantics — enrolled, withdrawn, deferred, completed — tied to LMS integration events.

Must-haves vs later

The split for release one is driven by one principle: include what's needed to enrol students, run the adaptive core, and prove it works; defer everything that enriches but isn't required for later phases.

Must-have for release one	Why
Student management, enrolment (via Moodle/LTI and standalone), roster/account provisioning, basic profiles	Without this there's no cohort to serve.
Core admin — course setup, user roles/permissions, run controls	Needed to configure and run a live course.
Essential reporting — student progress, mastery/completion status, grade pass-back to Moodle	Enough for instructors to monitor and for the institution to confirm the system works.
Analytics — the learner-model data the adaptive engine depends on (mastery state, activity tracking)	Core, not optional — the engine runs on it.

The six delivery-side roles

Role	What they do in delivery
Students	Learn through the adaptive journey.
Instructors / SMEs (delivery role)	Monitor cohort progress, grade summative submissions with AI assistance, review the SME queue for flagged formative diagnoses, act on integrity flags, verify contribution-ready artifacts.
Program admins / department leads	Read-only cohort oversight, program-level analytics, curriculum-health signals.
Learning designers / academic support	Depending on the institutional model, support learners with technical or process issues and triage flagged cases before they reach the SME.
Institutional integrity reviewers	Handle integrity investigations triggered by the behavioural layer or SME flags.
System admins	LTI configuration, user management, cohort setup, integration monitoring.

The SME's dual role — separate it in the permission model

An SME acts in two capacities: authoring in Studio (building courses, refining CLOs, approving nodes) and delivery in the Adaptive Learning System (grading, review queues, integrity dispositions). These are different functions and must be explicitly separated in the permission model — the same person, two distinct permission sets.

Roles that stay in Studio

For completeness, these authoring-side roles live in Studio and are not part of the delivery build: SMEs in their authoring capacity; learning designers building templates and contributing to the misconception library; and content producers and QA on the modality-production side.

For engineers — storage split

The relational web (course, CLOs, assessments, subtopics, nodes, KCs, evidence maps, milestone packs, and their edges) suits a graph store that routing and pathway logic traverse; the produced artifacts and their audit (envelopes, validation results, prompt templates, blueprints, content specs) suit a versioned document/JSON store, each carrying foreign keys back to the graph. Confirm the existing repo conventions before choosing — match what's wired, don't introduce a second pattern.