AI Adoption GuideEducationTeach
Adaptive Learning Path Engine
ML adjusts content sequence and pacing for each student in real time based on mastery signals and time-on-task.
Education processRecruitAdmitEnrollTeachAssessCredentialGraduateAdvance
By Don, DoneThat’s AI coach · updated
What a next-module recommendation is allowed to say
The engine's job is a next-module recommendation that cites the mastery and time-on-task signals it actually read. It is not a new syllabus, not a grade, and not permission to skip required work.
Faculty still owns sequence. Required modules stay required. If the LMS log is too thin to support a recommendation, the field stays empty.
A usable recommendation names the suggested item, names the signals used, and names what it did not assume. A complete line looks like this: next suggested item is the Module 5 reading, because Module 4 quiz mastery is recorded as complete and time-on-task on the Module 4 lecture is present in the activity log. Required Lab 4A is not skipped. If either signal is missing, do not fill the gap with a narrative.
This page is for the teach stage: sequencing and pacing inside a course that already exists. Placement into a course is a different decision. Use course placement recommendation when the question is which course to take, not which item inside this course.
Read mastery and time-on-task from the LMS, not from silence
Read two classes of record from the LMS the institution already runs. That may be Canvas, Blackboard, Moodle, or an SIS-adjacent stack such as Anthology or Ellucian, depending on where the gradebook and activity log live. Use only the fields they actually store for this course.
Mastery means scores, rubric outcomes, or competency flags the LMS already stores for that student and item. If the quiz was never submitted, there is no mastery signal. Do not substitute "probably understood it" from a discussion post, a video play, or a missing row. When you need a fuller model of competency from multiple evidence types, that is competency mastery inference, still bound to recorded evidence, not to invented scores.
Time-on-task means durations the LMS logged: page views with timestamps, attempt duration, or session time if the institution actually captures it. Low time-on-task is a pacing signal, not proof the student should skip the item. High time-on-task is not mastery.
Map each syllabus item to the LMS object that holds those fields before you generate anything. If the course uses a knowledge graph from syllabus, use it to know prerequisites and required nodes. The graph does not create mastery. It only tells you which items are allowed to be next without breaking faculty sequence.
Run the read in this order:
- Pull the student's item-level gradebook or outcome rows for the current module and its prerequisites.
- Pull time-on-task for those same objects, if the log has it.
- Mark each required item as required from the syllabus, not from engagement.
- If mastery is present and required items in the current module are not being skipped, propose the next syllabus-legal item and cite both signals.
- If mastery is absent, or time-on-task is absent when you would need it to justify a pacing claim, leave the recommendation blank.
- Surface the draft to the instructor for override. Never push the student past a required lab on the engine's say-so.
An intelligent tutoring system may use the same signals for hints inside an item. This engine only proposes the next item. Keep those jobs separate so a hint engine cannot quietly reorder the course.
Propose the next item without skipping required work
The next item is the earliest syllabus-legal object the student has not completed, given recorded mastery on its prerequisites, with pacing comments drawn only from logged time-on-task.
Low time-on-task on a required lab is a reason to flag the student for follow-up, not a reason to skip the lab. If the log shows a short session on Lab 4A, the honest recommendation is still Lab 4A, with a note that time-on-task was low. Pair that pattern with an early engagement alert when the issue is rush or absence. Do not pair it with a shortcut to the next module.
Do not auto-skip required modules. Do not treat optional enrichment as a substitute for a required node because the student moved quickly. Speed is not completion.
Pacing adjustments that are allowed: suggest extra practice the syllabus already marks as optional; suggest slowing the next optional item; suggest the instructor review a thin attempt. Pacing adjustments that are not allowed: dropping a required lab, reordering core modules, or declaring the student ready for a later unit because time-on-task on earlier videos was high.
The instructor can override in either direction: hold the student on the current module, or advance them when the LMS record is complete and the faculty member accepts the cited signals. The engine does not get the last word.
Leave the recommendation blank when the log is too thin
Thin logs are common. A quiz row with no attempt, a page with no recorded duration, a migrated course that never enabled activity reporting, a guest or audit enrollment without a gradebook: all of these mean you do not have the signals this outcome requires.
If the quiz is missing, do not invent a mastery score. Do not impute mastery from time-on-task on the lecture. The recommendation stays empty, with a reason such as "no mastery record for Module 4 quiz."
If time-on-task is missing, you may still recommend the next item only when mastery on required prerequisites is recorded and you are not using pacing as a skip criterion. If the only argument for the recommendation was pacing, leave it blank.
If records are partial, cite what you have and stop. "Mastery recorded for quiz 4; time-on-task not logged" is a complete, honest output. Filling time-on-task with a default is fabrication.
Empty stays empty. A blank recommendation tells the instructor not to act on a machine suggestion this week.
Instructor override and the traps that look like personalization
Treat the recommendation as an advisory line in the instructor's workflow, not as a grade-book field and not as a student-facing unlock until a human publishes a path.
Skipping a required lab because time-on-task was low. The student opened Lab 4A, stayed briefly, and closed it. The engine must not conclude the lab is unnecessary. Low duration is a coaching signal. The required lab remains the next item unless the instructor explicitly waives it in the LMS.
Inventing mastery from a missing quiz. The student never submitted Quiz 4. Discussion comments or a long lecture session are not a quiz score. Do not write a synthetic percent. Leave mastery blank and leave the next-module recommendation blank if Quiz 4 is a prerequisite.
Treating a recommendation as a grade. The suggested next item is not an outcome, not extra credit, and not a revision of the recorded score. If staff copy the recommendation into the gradebook, they have changed the assessment record without an attempt. Keep the recommendation in a separate field.
Illustrative example, not a measured case: In an undergraduate research-methods course, Module 4 is sampling. The syllabus lists a lecture, Quiz 4, and required Lab 4A. The LMS shows Quiz 4 as complete with a recorded mastery mark. Lab 4A has no submission. Time-on-task on the lecture page is present. Time-on-task on the lab is a short session with no attempt artifact. The legal recommendation is Lab 4A, citing quiz mastery as complete and citing low lab time-on-task as a reason to keep the student on the lab, not to skip it. The engine does not suggest Module 5. If Quiz 4 had no attempt row, the recommendation field stays empty even if the lecture timer looks busy. The instructor can still message the student, extend a deadline, or waive an item in the LMS.
Ship the recommendation with the citations attached. If the citations cannot be produced from the LMS, do not ship a recommendation.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first