Why "schedule the learner's journey" differs from "schedule the LP's content refresh"
Both models solve the same underlying constraint: content item completion is permanent — once done, done forever. To record a new certification event, the system needs a new Course as the vehicle. The two approaches differ in how that vehicle gets created and — critically — how it gets delivered to each learner at the right time.
The admin defines a series of Courses within an LP — Original, Renewal 1, Renewal 2, etc. — each with scheduling rules that determine when it activates. Rules can be absolute dates, enrollment-relative, or completion-triggered delays.
The LP template is defined once. The system evaluates the scheduling rules against each learner individually. Lisa's Renewal 1 activates 365 days after Lisa completes. Dan's activates 365 days after Dan completes. The Course is the same; the timing is per-learner.
Key property: Multiple learners can be at different stages of the same LP simultaneously. The program doesn't move as a unit — each learner traverses it on their own timeline.
The admin defines one cycle (a set of Courses) within an LP, plus a recurrence interval (e.g., "Every 12 months"). At each interval, the system deep-copies the active cycle into a new version, marks the old one "no further enrollment," and cancels incomplete work.
The recurrence fires for the entire LP at once. On Jun 1 2027, every learner — regardless of when they individually completed — gets the same treatment: old cycle cancelled, new cycle active. Optionally, a warning notification goes out one month prior.
Key property: At any given time, there is one active cycle for the whole LP. All learners are in the same cycle. The program moves as a unit.
The reason we need "reassignment" at all: content item completion is permanent. Once done, done forever. To record a new certification event, we need a new Course as the vehicle. The question is how that vehicle gets created and delivered.
Both models agree on the top and bottom rows. The divergence is in the middle — what controls the timing of each learner's journey.
| Layer | Course-level scheduling (ours) | Cycle recurrence (Option B) |
|---|---|---|
| Template | LP with Courses + scheduling rules Defined once. Contains the full pattern. |
LP with one active cycle Defined once. Contains one cycle at a time. |
| Timing mechanism | Per-learner: scheduling rules evaluate against each learner's dates 1 rule : N individual timelines |
Per-LP: recurrence fires for the entire program at one moment 1 clock : 1 batch event |
| Instance | Each learner's Course activates on their schedule Lisa: Jan 15. Dan: Jul 15. Amy: Jun 30. |
All learners get v2 at the same time Everyone: Jun 1 (cycle boundary). |
Doctor writes: "Take for 30 days, refill every 90 days, 4 refills."
The prescription is the template. Each patient's refill schedule is their instance. The pharmacy knows when your 90 days are up — it doesn't care when other patients filled theirs.
Lisa filled Jan 1 → next refill Apr 1.
Dan filled Mar 15 → next refill Jun 13.
Both are on "every 90 days" but running on their own clock.
Hospital announces: "Flu shot clinic runs every October."
The clinic schedule is the recurrence. When October arrives, everyone is invited at once. The hospital created the supply (the clinic session = deep copy) and notified people.
But: if you got a special vaccine in April, you shouldn't get another in October. Too bad — the clinic doesn't know your individual history. It runs on its own clock.
UC2 (certification renewal) is inherently a prescription problem: "Renew 12 months after you complete." Each learner's renewal clock starts at a different time because they each completed at a different time.
Option B tries to solve a prescription problem with a flu-shot-clinic mechanism. It creates the supply (new cycle), announces availability (notification), but has no mechanism to deliver it to each person when their individual prescription is due.
The Course exists in the LP template. The scheduling rule delivers it to each learner at the right time. One mechanism, both problems solved.
The deep copy creates a fresh Course. But delivery is batch-level (everyone at once) or undefined (notification → then what?). The hard problem — per-learner timing — is left unsolved.
Same UC2 scenario — "renew 12 months after completion" — modeled two ways
LP template contains: Original → (365d after completion) → Renewal 1 → (365d after completion) → Renewal 2...
LP created Jun 1 2026. Lisa completes quickly (Jul). Dan takes longer (Feb 2027). Amy enrolls late (Nov), completes Dec.
LP created Jun 1 2026. Recurrence = "Every 12 months." System warns May 2027, flips cycle Jun 1 2027. Same for Jun 2028.
| Problem to solve | Our model | Option B |
|---|---|---|
| Fresh Course for new completion record "We need a vehicle to record the renewal" |
Solved Courses pre-declared in LP template |
Solved Deep copy creates fresh Course |
| Deliver to right learner at right time "Lisa gets hers in Jan, Dan gets his in Jul" |
Solved Scheduling rules activate per-learner |
Unsolved Batch delivery (everyone at once) or undefined (notify → then what?) |
| Multiple learners in different cycles simultaneously "Lisa is in Renewal 2 while Dan is in Renewal 1" |
Supported Each learner's position is independent |
Impossible One active cycle for the whole LP |
| No ongoing admin action required "Set it and forget it" |
Yes Define template once, system executes indefinitely |
Partial Auto-recurrence reduces work but timing is wrong for UC2 |
UC2 is the general case. UC1 is the constrained special case.
It's natural to start with UC1 (fixed calendar, everyone on the same cycle) because it's simpler. Then you try to stretch that model to cover UC2. But this gets the generality backwards:
Starts with one clock for the whole LP. To handle UC2, you'd need to... what? Run separate recurrences per learner? At that point you've reinvented per-learner scheduling with extra steps.
Stretching a batch model to cover individual timelines always leaves gaps.
Starts with per-learner scheduling (the general case). To get UC1, just use absolute dates instead of completion-triggered delays. Same mechanism, simpler inputs.
Constraining a general model to cover simple cases is trivial.
| Scheduling parameter | UC2 (general) | UC1 (constrained) | What changed |
|---|---|---|---|
| Course start | 365 days after completing previous | Jan 1 2027 (absolute date) | Replace relative trigger with fixed date |
| Course end | None (or relative window) | Dec 31 2027 (absolute date) | Add a fixed deadline |
| Learner timelines | Each learner independent | All learners converge (same dates) | Emergent — not a separate mechanism |
"Refill every 90 days after your last fill."
Want a flu shot clinic? Easy: set the prescription to "Fill on October 1" for everyone. The same system handles both.
General system can trivially do the simple case.
"Everyone comes in October."
Want individual prescription timing? You'd need... a prescription system. The clinic model can't stretch — you have to build the per-patient infrastructure anyway.
Simple system cannot stretch to the general case.
| Use case | How it's configured in our model | What makes it "special" |
|---|---|---|
| UC1 — Annual compliance | Absolute start + absolute end | All learners converge on same dates (simplest config) |
| UC2 — Certification renewal | Completion-triggered delay | Each learner independent (general case) |
| UC2 + Window | Completion-triggered delay + relative end | General case + time pressure |
| UC3 — Regulatory clock | Enrollment-relative start + relative end | Individual but not completion-dependent |
All four use the same components and mechanisms. The difference is which scheduling inputs are configured. No separate "batch mode" or "cycle recurrence" needed.