TL;DR
A Course is the recipe. A Cohort is the meal you cooked
yesterday. You author the recipe once. You can cook it many times.
What lives where
When you create a cohort, the syllabus tree is cloned into it. From
that moment, edits to the cohort don’t propagate back to the course,
and edits to the course don’t reach existing cohorts. (You can still
re-clone with cohorts.create({ course_id, copy_overrides: false }).)
When you have just one cohort
Plenty of products only ever need one cohort per course — for example,
a self-paced consumer learning app. The SDK supports that with sugar:
You can ignore cohorts entirely until you need them. The day a customer
asks for “the same course but for the new intake,” you already have
the model.
When you have many cohorts
This is where the split pays off. Say you sell a corporate training
course; each customer is a cohort:
Now each customer’s enrollments, submissions, and grades are isolated.
The syllabus stays in one place.
Anti-patterns
Don’t model “this year” and “last year” as edits to the same Course.
You’ll lose history and break analytics. Create a new Cohort instead.
Don’t model “track A” and “track B” of the same course as separate
Courses. They share a syllabus, share rubrics, share generated
content. Use one Course with two Cohorts and per-cohort overrides.
Don’t create a Course per student. Courses are syllabi. A 1:1
tutoring product is one Course with one Cohort per learner — or a
single Cohort and the right rubric. Talk to us if you’re not sure.