A Phased Approach to Modular Learning Paths / Sequencing by Edly and OpenCraft

Background and Context

Following recent client discussions, there is confirmed interest in implementing Learning Paths that can be configured directly within Studio and surfaced to learners in a clear, structured way. Two complementary proposals, Edly’s catalog and sequencing UI, and OpenCraft’s learner-facing UI and backend, present a strong case for a phased implementation that meets immediate institutional needs while aligning with the Open edX platform’s long-term goals around modular content delivery.

A current OpenCraft client has agreed to potentially partially fund this work, contingent on technical feasibility and alignment with the community. After reviewing OpenCraft’s existing UI and Edly’s proposed authoring tools, the client confirmed that this direction would meet their needs.

This proposal outlines a three-phase implementation, designed to:

• Deliver immediate value (sequencing courses into programs)

• Establish foundations that can be built upon by the community

• Accommodate alternative catalog and discovery approaches through modularity

This infrastructure lays the groundwork for competency-based education (CBE). This will allow learning paths to be aligned with skills or competency frameworks, enabling flexible mastery rules and credentialing in future phases.

Client Use Cases

Use Case 1: Basic Learning Paths

• Learning Paths are authored in Studio

• Learning Paths assigned to learners by instructors (learners cannot select their own)

• Learners cannot view available Learning Paths in the Discovery UI

• Learners can (reuse OpenCraft’s learner-facing UI):

  • See their full pathway

  • Track progress through sequenced courses

  • Understand what's required to complete the full path (or tier)

• Supports MVP needs of institutions who manage enrolments centrally but want structured learner views

Use Case 2: Advanced Learning Paths with Tiering

Builds on Use Case 1 with added functionality:

• Multi-level Learning Paths (e.g. nested or progressive structures)

• Elective and flexible groupings (e.g. “choose 2 of 5”)

• Course prerequisites and unlocking logic

• Certificate tiers (e.g. “Complete Tier 1 + Electives to unlock Tier 2 certificate”)

Proposed Approach

Phase 1: Backend Foundation

Goal: Establish the backend structure for Learning Paths, including models, logic, and Django admin interfaces, with future learner progress tracking and credentialing logic in mind.

Scope:

• Set up Django admin pages to:

  • Create and Learning Paths.

  • Link courses to Learning Paths.

  • Manage enrollments.

• Set up APIs to:

  • List and retrieve Learning Paths.

  • List and create enrollments (including individual and bulk enrollment APIs).

  • Enroll users into courses that are included in a Learning Path (to bypass invite-only course requirements).

• Implement platform integration (as suggested by @Felipe Montoya during the last Product WG meeting). This step is optional, but it would ensure that the Learning Paths are natively available in the platform:

  • Move the LearningPathKey to opaque-keys.

  • Move Learning Path models to edx-platform.

• No UI work (Studio or learner-facing) will be done in this phase.

• Lay the groundwork for certificate/tier logic tied to learner progress tracking (based on completion and grading), and future UI integrations.

This work will align with and support the enhanced certificate and completion logic under discussion in the Open edX community: Enhanced certificate generation, completion, grades, and tiers. The Learning Credentials repository is responsible for calculating Learning Paths progress in order to define flexible certification criteria. This way, course authors can define individual requirements for each step (i.e. course) in a Learning Path.

Most, if not all, of the code for this functionality already exists and is being used in production on a large Open edX instance. So the main goal for Phase 1 would be to verify that the existing backend logic:

• supports the basic set of use cases that the community would like to see in an MVP implementation.

• can be used as a starting point for building out instructor and learner-facing functionality for Studio and the LMS in subsequent phases.

Once there is consensus around that, we could upstream the existing implementation by transferring it to the openedx organization on GitHub.

Phase 2a: Minimal Studio Authoring UI

Goal: Build a Studio authoring experience scoped specifically to course sequencing, intentionally simple, but designed for extension.

Scope:

• Develop a visual Studio-facing UI for Learning Path authoring

• Ensure integration with backend logic and upstream alignment

• Allow course teams to group courses and define Learning Path properties within Studio

Phase 2b: Learner-facing UI

Goal: Provide a clear, structured learner experience with progress tracking leveraging OpenCraft’s learner-facing UI.

Scope:

• OpenCraft’s existing learner-facing UI and backend logic will be adapted for upstream compatibility.

• Learners will see:

  • Assigned Learning Paths

  • Grouped courses with completion status

  • Visual progress tracking through the sequence

• Designed to support future enhancements like elective selection, self-enrolment, and discovery UIs

Discussion point:

To ensure a cohesive learner experience, we’d like to explore whether OpenCraft’s “My Learning” dashboard could form the basis of a unified learner interface. This dashboard presents all enrolments (courses + learning paths), supports filtering and search, and includes progress tracking, reducing the need to switch between different views.

Open

We understand that the Open edX community is currently rebranding the Learner Home, and we want to avoid duplicating or diverging from that direction.

We’d like to ask the community:

• Is it feasible to contribute or align our existing dashboard with the evolving core dashboard work?

• What would be the best path to explore this integration: collaboration on the new Learning MFE, or a plugin architecture that supports custom dashboards?

• If a shared direction isn’t possible right now, is it acceptable to temporarily override the dashboard in specific deployments (while maintaining API compatibility)?

Our goal is to avoid creating parallel dashboards and instead support a single, learner-friendly view, whether an institution delivers courses, learning paths or both.

Phase 3: Plugin Architecture and Extension Hooks

Goal: Prepare the platform for modular, community-built pathway extensions without altering core code. No feature plugins will be built in this phase, focus is on creating the architecture that allows them

Scope:

• Add plugin slots and extension hooks to the Studio authoring MFE

• Define backend extension points for learning path logic

• Provide API endpoints and contracts for plugins to:

  • Add new configuration options in Studio

  • Extend learner-facing views and logic

  • Introduce new completion/credentialing rules

• Document the plugin API to enable community adoption

Future Phases:

Deliver modular extensions to support real-world use cases, including those required by current clients.

Examples:

• Create plugins for:

  • Tiered certification logic (e.g. complete basic + electives to unlock advanced tiers)

  • Flexible course groupings (e.g. “choose 3 of 5”, “at least one from this list”)

This will require extensions to both the backend implementation and user-facing functionality in Studio and the LMS.

Modularity and Collaboration

We recognise the overlapping efforts from other vendors (Schema, EduNext, etc.) and actively support a modular implementation model. Our proposed plugin architecture is designed to:

• Avoid vendor lock-in

• Allow alternative catalog UIs to interoperate

• Enable credentialing or rubrics extensions without core changes

We welcome Schema’s and EduNext’s proposals and view this phased work as a foundation others can build on.

Next Steps

We are seeking:

• Community endorsement of Phase 1 as the starting point, so we can prepare a product proposal for a practical, MVP-aligned foundation.

Once Phase 1 is approved, we will:

• Iteratively develop and refine each subsequent phase.

• Present each phase as a separate proposal for community review and feedback before moving forward.