TL;DR Summary

We propose a foundational implementation of Learning Paths in Open edX. This will not be a full product, but a modular, plugin-ready sequencing architecture that supports courses as the first learning item type. It provides the extensible base needed for future capabilities such as CBE alignment, flexible authoring tools, and integrated credentialing.

This phase will adapt and refactor an existing HMS-funded implementation so it aligns with the Open edX community's long-term architecture goals.

We are using the name Learning Paths for now, but future UI will support configurable terminology (e.g. Path, Journey, Program).

Overview

A Learning Path is a curated, trackable sequence of learning items (courses, library components, assessments, and external tools) designed to guide learners toward specific skills, competencies, or outcomes. Items can be ordered, gated by prerequisites, and tracked for progress and completion.

Learning Paths also support Learning Path Runs, similar to how courses have course runs. Each Learning Path run contains course keys, so it always points to the correct course run, but does not manage course content itself. When a course is updated and its course key stays the same, those updates automatically apply to the Learning Path Run. When a new course run is introduced, a new Learning Path Run should be created if instructors want to ensure that learners keep their existing completion records and grades intact.

This proposal defines the backend foundation for Learning Paths, not a full-featured product or UI. We are building for modularity and interoperability, so that advanced use cases like competency-based education (CBE), microcredentials, branching logic, and custom credentialing can be added later through plugins or follow-up phases.

What Phase 1 is:

• A transition from HMS-funded work to an upstream-ready foundation

• A learning context–based abstraction (not course-bound)

• A backend that supports plugin-driven growth for multiple future use cases

• A path to higher-value features without re-architecture

Why we’re building on the HMS code:

Several comments questioned whether the current HMS implementation was too “course-coupled” to be reused. That’s a valid concern, and it’s exactly why this proposal includes architectural rework. But discarding the HMS code entirely would be wasteful. It contains useful logic that aligns with educator needs and gives us a head start on validation. Our approach is to retain the valuable structure, while abstracting away the course dependencies and aligning with the community’s long-term modular vision.

This is not about preserving legacy, it’s about evolving solid groundwork into a shared foundation.

What does the future hold?

• Studio authoring experience for Learning Paths

• Learner-facing experience for Learning Paths

• Prerequisites, electives, and conditional sequencing (“any X of Y”)

• Microcredentials and program-level recognition

• Deeper RBAC for path-specific instructor roles

• Extensions for mastery tracking and CBE workflows

Links to the HMS implementation

• GitHub - open-craft/frontend-app-learning-paths

• learning-paths-plugin/learning_paths/models.py at main · open-craft/learning-paths-plugin

Problem

The platform lacks native support for flexible learning progression that spans multiple courses.
Institutions have independently built their own solutions, creating fragmentation, limiting adoption, and increasing maintenance cost.

Use Cases

These use cases reflect the functionality being delivered in Phase 1 of the MVP. Pathways will be managed through Django Admin interfaces for now, with frontend author and learner work to follow in Phase 2.

As a Platform Administrator…

• I want to create and manage learning paths from existing courses so that learners can follow a curated journey.

• I want to define whether courses in a learning path can be completed in any order. (Note: In Phase 1, only “any order” sequencing is supported. “Set order” logic can be added in a future iteration.)

• I want to enroll learners in learning paths so they can access learning content.

• I want to view a catalogue of all learning paths in the Django Admin (for Phase 1 MVP) so I can manage each learning path.

• I want to bulk-enroll learners into a Learning Path and its associated courses via the API.

• I want to create Learning Path Runs so I can offer multiple versions of the same learning path over time, without disrupting the progress or grades of learners already enrolled.

• I want course content updates to automatically apply within a Learning Path Run when the course key stays the same, to minimise administrative friction for small improvements.

• I want to create a new Learning Path Run when a new course run is available, so new learners can start the updated version, while existing learners continue in the original run with their progress and grades protected.

• I want to archive a learning path while still maintaining credential eligibility, so learners can receive certificates even if a path is no longer enrollable.

• I want to edit learning path details (such as the name, description, item order, and visibility) so I can keep the overall path accurate and relevant. (Note: The details of individual learning items (the course in this case) must still be edited at the source level, e.g. within the course itself.)

• I want to manage user access (add/remove/enable/disable) so that participation stays up to date.

• I want to track progress across learners and paths so I can monitor completion rates.

• I want to download learning path credentials or certificates as proof of completion, so I can provide learners with verifiable recognition for their progress. For MVP: Basic support depends on integration with the Learning Credentials plugin, which is under separate community review.

As a Course Author…

In Phase 1, course authors will not interact directly with Learning Paths via Studio. Their use cases will be supported in Phase 2 when a dedicated UI is implemented. For now, all authoring and administrative functionality is handled through the Django Admin by Platform Administrators.

As a Learner…

In Phase 1, learners will not interact with Learning Paths directly. However, the backend will be built to support the following learner use cases, enabling the eventual implementation of a learner-facing UI in Phase 2.

• I want to browse learning paths that I have access to, so I can choose which ones to follow.

• I want to view learning path details (title, description, estimated time), so I can decide if it fits my goals.

• I want to see the list of courses in a learning path, so I can understand the scope of the sequence.

• I want to complete courses in any order, so I can follow a flexible learning experience.

• I want to track my progress across each course and the overall learning path through a status indicator (e.g. Not Started, In Progress, Completed), so I can keep track of where I am.

• I want my progress and grades to stay accurate and untouched when new versions of a learning path are released, so I can complete the version I started with confidence.

• I want to receive a certificate or credential upon completing a learning path, if one is issued.

Proposed Solution and Implementation Plan

We do not intend to upstream the HMS implementation “as-is.” Instead, Phase 1 evolves the HMS-funded work into an upstream-ready, modular, platform-integrated backend foundation for Learning Paths, supporting full courses as the first learning item type and enabling future learner- and author-facing tools.

This work is split into two sub-phases. Funding is required for both discovery and implementation.

Phase 1.1: Technical Discovery

• Confirm architectural alignment with community needs

• Identify gaps between HMS code and MVP requirements

• Scope refactors and new logic

• Surface major risks and refine estimates

Phase 1.2: Architectural Rework (Funding Required)

Backend-only Architecture

Refactor and extend the backend into a reusable implementation supporting MVP use cases:

• A generalised learning path model (using the “learning context” abstraction)

• Django Admin and APIs for creating Learning Paths and Learning Path Runs, managing enrollment, and controlling access.

• Basic sequencing (courses can be completed in any order; prerequisites and other sequencing rules will follow in a future iteration once the data model is established.)

• Progress tracking and completion across courses

• Path-completion triggers via the Learning Credentials plugin

Modular and Extensible Structure

This phase decouples sequencing logic from course containers and implements it around generic learning contexts, laying the groundwork for future additions like:

• Course sections or units

• Library content

• Rule-based sequencing (e.g. “any 2 of 3”)

• Program-level credentials

• RBAC and tagging extensions

These are intentionally out of scope for Phase 1, to keep it small and manageable, but designed for in the foundation.

Code refactor and reuse plan:

• Reuse validated logic from the HMS implementation (already in real-world use)

• Replace course-coupled assumptions with generalised models

• Align with upstream standards and plugin strategies

Architectural Goals

• Upstream-ready (aligned with openedx repositories and opaque-keys)

• Plugin-ready, allowing MFEs and external tools to interact with Learning Paths without tight coupling

• Future-proof, so we can later support library content, microcredentials, sequencing logic, and more

Phase 1 delivers the foundation, not the full house. It ensures we can expand responsibly, without rewriting core architecture.

ERD envisioning future architecture:

This will be refined during Phase 1.

Open

Open

A rough diagram of mapping the existing models with the envisioned models in the ERD.

Other Approaches Considered

• Upstream HMS code as-is: Not feasible. The current implementation is course-coupled and does not align with the community’s modular architecture vision.

• Start from scratch: Discards existing work and slows progress toward validation and adoption.

Competitive Research

• Canvas supports program-level outcomes but keeps them tightly coupled to courses.

• Coursera enables Specialisations made up of modules and courses but has limited flexibility beyond predefined structures.

• D2L Brightspace allows outcomes to be attached and surfaced at multiple levels (programs, courses, activities), adapting to institutional structures.

• Moodle requires plugins for more advanced sequencing and competency workflows.

Open edX can differentiate through openness, extensibility, and learner-centred flexibility, especially in how learning paths and outcomes evolve over time.

Funding status

• Funding will be required for architecture alignment (to be scoped)

Next steps

1. Secure Funding for Phase 1

2. Technical Discovery

3. Phase 1 Implementation

4. Parallel Proposal Development

   1. Phase 2a: Studio authoring UI

   2. Phase 2b: Learner-facing UI