Structured course categorization in Course Discovery with future Catalog MFE compatibility

We are currently using Tutor with the Open edX Ulmo release and are planning a structured course categorization and filtering system using the existing LMS and Course Discovery setup.

The required metadata includes:

  • Primary knowledge domain
  • Primary competency field
  • Optional secondary competency field
  • Course format
  • Certification type
  • Catalog visibility
  • Last relevant update date

These fields need to be available in Discovery and the search index so they can support filtering, faceting, sorting, dynamic counters, and deduplicated results. For example, a course may match through both its primary and secondary competency fields, but it should still appear and be counted only once.

Our current idea is to create a Django plugin or backend extension that manages the taxonomy and course metadata, synchronizes it with Discovery or Meilisearch, and updates the indexing and search behavior.

This would initially be implemented for our current Tutor Ulmo setup and the existing Discovery-based catalog. However, we plan to upgrade to Verawood later, where the catalog experience may move to the Catalog MFE. We therefore want to avoid tightly coupling the solution to the current Discovery frontend.

Has anyone implemented a similar structured taxonomy and filtering system in Course Discovery?

We would particularly appreciate guidance on:

  • Whether an existing plugin or reusable implementation already exists
  • Whether the taxonomy should be managed in Studio, a Django plugin, or Discovery
  • How custom metadata should be synchronized and indexed
  • How primary and secondary mappings, counters, and deduplication should be handled
  • How to design the backend and API so the Ulmo implementation can later be reused or adapted for Verawood and the Catalog MFE

Any examples, repositories, or architectural recommendations would be very helpful.

Can you use the existing Taxonomy authoring tools in Studio for this purpose?

Many of us want to deprecate the discovery service, although no formal decision has been taken. I would recommend you read through that GitHub writeup before deciding to build anything on top of the discovery service as it exists today (although it may still make sense to do so for your purposes).

In Verawood and later, we have the new Learning Core Catalog App which provides Django models that can perhaps be used as a basis for building new functionality like this, although it doesn’t have any search indexing/filtering.

In short: your needs match what we’ve discussed as an ideal use case for the future replacement of the discovery service, but we haven’t made too much progress in developing the right foundation for it yet.

@braden Sorry, I missed. Thank you so much for answering and clearing my doubts.