[Feature Request]: Adaptive long-term learning engine for Mastery Path — retention-based spaced repetition, unified learning evidence, and study prioritization

Do you need to file a feature request?

• I have searched the existing feature request and this feature request is not already filed.
• I believe this is a legitimate feature request, not just a question or bug.

Feature Request Description

Hi,

I reviewed the current implementation in main, not just the README. I looked through the relevant learning, mastery, scheduling, service, and course-state code.

DeepTutor's current Mastery Path already has a strong foundation:

• deterministic per-objective mastery gates
• persisted quiz attempts and errors
• qualitative assessment for concepts/design tasks
• a spaced-review queue
• next_objective() prioritizing due review before new material
• Course-level aggregation of Mastery Paths, Question Bank data, syllabus units, and reading workspaces

The biggest missing piece, in my opinion, is not "adding spaced repetition", because DeepTutor already has it.

The bigger opportunity is turning the current fixed-interval review system into a genuinely adaptive long-term learning engine.

The most important part of this request is adaptive spaced repetition. Cross-course study planning is useful too, but secondary.

CURRENT BEHAVIOR

1. Spaced repetition currently uses predefined intervals

In deeptutor/learning/scheduler.py, the intervals are currently defined roughly as:

MEMORY: [0, 1, 3, 7, 14, 30, 60]

CONCEPT: [3, 7, 14, 30]

PROCEDURE: [3, 7, 14]

DESIGN: [14, 28]

schedule_next() moves forward or backward through these lists depending on correctness / consecutive correct answers.

This is already useful, but it means that learners with very different memory characteristics still mostly follow the same interval structure.

1. RepetitionState does not model actual memory state

In deeptutor/learning/models.py, RepetitionState currently stores things like:

• interval_index
• consecutive_correct
• consecutive_wrong
• next_review_at

What is missing is a richer model of long-term memory, for example:

• difficulty
• stability
• retrievability / estimated probability of recall
• desired retention
• lapse count
• review count
• last review timestamp
• uncertainty/confidence in the estimate

This matters because the current system can answer:

"Which interval index is this item on?"

but not really:

"How likely is this learner to remember this knowledge point tomorrow, in one week, or by exam day?"

1. Mastery and retention should be separated

In deeptutor/learning/mastery.py, the current mastery calculation is intentionally simple and based mainly on recent correctness.

I think DeepTutor should explicitly distinguish:

Mastery: "Has the learner demonstrated understanding?"

from:

Retention / retrievability: "How likely is the learner to successfully retrieve this knowledge now or later?"

These are not the same.

Example:

A learner may understand the brachial plexus very well but still forget several Latin structure names after a few days.

Or they may repeatedly recognize a concept correctly but fail free recall.

DeepTutor would benefit from modeling both separately.

PROPOSAL

1. Adaptive retention-based spaced repetition

Introduce a pluggable adaptive scheduler.

FSRS is an obvious reference implementation, but the architecture should not require FSRS specifically.

A useful per-knowledge-point memory state could contain something like:

difficulty stability retrievability last_review_at next_review_at desired_retention review_count lapse_count

The scheduler could then choose the next review based on predicted retention rather than moving through a fixed list.

Relevant references:

• Free Spaced Repetition Scheduler (FSRS) https://github.com/open-spaced-repetition/free-spaced-repetition-scheduler

• Ye, Su & Cao: "A Stochastic Shortest Path Algorithm for Optimizing Spaced Repetition Scheduling" KDD 2022 DOI: 10.1145/3534678.3539081

• Su et al.: "Optimizing Spaced Repetition Schedule by Capturing the Dynamics of Memory" IEEE TKDE 2023 DOI: 10.1109/TKDE.2023.3251721

A cold-start learner could use default parameters and become personalized after enough review history is collected.

1. Store durable review history, not only current scheduler state

Adaptive scheduling needs a history of evidence.

I would suggest a structured ReviewEvent or LearningEvidence record.

For example:

knowledge_point_id timestamp source assessment_type result review_quality hints_used attempt_count confidence response_time qualitative_score session_id

Not every field needs to be mandatory.

The important part is that DeepTutor should retain the evidence that caused the current learner state.

This also makes the learner model auditable and recomputable.

1. Use richer review quality than correct / incorrect where possible

Not all correct answers are equally strong evidence.

For example:

• correct without hint
• correct after one hint
• correct after several retries
• partially correct explanation
• strong Feynman explanation
• failed transfer/application question
• high-confidence wrong answer

These should not necessarily result in identical updates.

DeepTutor could internally normalize these signals into something like:

Again Hard Good Easy

or a continuous review-quality score.

This should ideally be inferred automatically rather than forcing the user to manually rate every answer.

Optional learner confidence could also be useful.

For example:

high-confidence + wrong

may indicate a misconception and should be treated differently from:

low-confidence + wrong

1. Keep knowledge-type-specific pedagogy

DeepTutor already distinguishes:

• memory
• concept
• procedure
• design

That is valuable and should remain.

However, knowledge type should primarily influence HOW the item is tested, rather than forcing a predefined review interval.

For example:

memory: unaided recall

concept: explain / distinguish / connect

procedure: perform on a new problem

design: justify or solve a transfer problem

The scheduler decides WHEN review is needed.

The knowledge type decides WHAT successful retrieval/mastery should look like.

1. Connect evidence across DeepTutor

This is closely related to issue #824.

If the same learner encounters the same underlying concept in:

• Mastery Path
• Quiz
• Immersive Reading
• Question Bank

the resulting learning evidence should ideally update the same learner state.

Example:

Mastery Path: wrong answer on a concept

Quiz: wrong answer on the same concept

Immersive Reading: failed comprehension check on the same concept

These should eventually reinforce the same underlying knowledge state rather than appearing as unrelated events.

Issue #824 already points toward unified assessment history across learning surfaces.

Relevant issue: #824

1. Track recurring misconceptions

DeepTutor already stores individual errors, which is a good foundation.

A useful next step would be detecting repeated conceptual error patterns.

Example:

Anatomy: the learner repeatedly confuses medial and lateral orientation across several different questions.

Instead of storing only separate wrong answers, DeepTutor could represent:

Misconception: medial/lateral orientation confusion

Evidence: question A question B Feynman explanation C

Last observed: yesterday

Status: active

Recommended repair: contrastive retrieval exercise

The key point is that this should remain evidence-based.

It should not become a vague AI-generated personality profile.

Relevant parts of issue #397 also align with this:

• concept-level learner state
• recurring error patterns
• forgetting/review management
• learning evidence from multiple modules
• explainable learner-state decisions

Relevant issue: #397

1. Improve review-queue prioritization

Currently review priority is still largely static and knowledge-type based.

A future review queue could combine:

• predicted forgetting risk
• how overdue the item is
• recent failures
• lapse history
• misconception history
• prerequisite importance
• exam relevance

For example:

A concept with predicted retrievability of 55% and two recent failures should probably outrank a simple memory item that became due 10 minutes ago.

The exact prioritization algorithm should remain replaceable.

1. Prerequisite-aware learner state

A knowledge point should optionally be able to reference prerequisite knowledge points.

Example:

prerequisite_ids: [...]

This could help DeepTutor distinguish:

"You are weak at this topic"

from:

"You are failing this topic because prerequisite X is unstable."

This does not require a huge automatically generated knowledge graph.

A lightweight prerequisite relationship would already be valuable.

1. Secondary feature: study prioritization across courses

This is less important than adaptive spaced repetition, but I think it fits naturally on top of the same learner state.

The existing Course infrastructure already aggregates much of the required information:

• Mastery Paths
• mastery progress
• Question Bank weaknesses
• syllabus units
• reading workspaces

At the moment, course progression is still fairly simple.

A future planner could optionally consider:

• exam/deadline
• importance
• current mastery
• due reviews
• forgetting risk
• estimated remaining work
• available study time

Then DeepTutor could answer:

"I have 90 minutes. What should I study?"

Example:

45 min anatomy Reason: tomorrow's class + several weak objectives

25 min cell biology Reason: three high-risk reviews are due

20 min biophysics Reason: untouched prerequisite for Friday

This should remain advisory and always overridable by the learner.

The main focus of this request is still the retention/review system, not calendar planning.

1. Explainability

Every important recommendation should expose its reasoning.

Instead of:

"Review brachial plexus now"

show something like:

"Review brachial plexus now because:

• last successful retrieval: 5 days ago
• estimated retrievability: 74%
• desired retention: 90%
• failed once in the last two reviews
• relevant for tomorrow's upper-limb session"

The same should apply to learner-state changes.

This is especially important when qualitative assessment involves an LLM.

IMPORTANT: THIS IS NOT A DUPLICATE OF #840

Issue #840 reported that concept and design knowledge points were not entering spaced review correctly.

That appears to be fixed in current main.

The current code now routes qualitative mastery assessment through the spaced-repetition scheduler and updates/rebuilds the review queue.

So this request is not asking to fix concept/design scheduling.

It starts from the current implementation and asks for a more adaptive retention model on top of it.

Relevant issue: #840

SUGGESTED IMPLEMENTATION ORDER

Phase 1 — Adaptive SRS foundation

• durable review-event history
• richer RepetitionState
• pluggable scheduler interface
• adaptive retention model
• configurable desired retention
• migration from existing interval-index state

Phase 2 — Better learning evidence

• hints/retries/qualitative assessment influence review quality
• mastery and retrievability represented separately
• recurring misconception tracking

Phase 3 — Cross-surface evidence

Build on #824 so that Quiz / Mastery Path / Immersive Reading evidence can update the same learner state where concepts can be matched safely.

Phase 4 — Prioritization

• forgetting-risk-aware review queue
• prerequisite information
• optional exam/deadline metadata
• optional time-budget-aware study recommendations

ACCEPTANCE CRITERIA

• Existing Mastery Paths continue to work without migration loss.
• Review intervals are not limited to hard-coded interval sequences.
• The scheduler can estimate learner/item-specific memory state from review history.
• Mastery and retention/retrievability are represented separately.
• Every review creates durable evidence that can be replayed or recomputed.
• Failed reviews shorten future intervals appropriately.
• Strong repeated retrieval increases stability and future intervals.
• Desired retention can be configured, at least globally or per Mastery Path.
• memory / concept / procedure / design can retain different assessment strategies.
• Qualitative assessments participate in adaptive review.
• Review priority can incorporate forgetting risk rather than only static knowledge-type priority.
• Repeated misconception/error patterns can be represented separately from individual wrong questions.
• The design can consume unified assessment evidence from #824 instead of creating another isolated history.
• Learner-state judgments expose their supporting evidence.
• The system remains usable with default parameters before enough personalized review history exists.
• Optional Course planning can consider due reviews, mastery, and deadlines while remaining learner-overridable.

RELEVANT CURRENT CODE

I reviewed the current main implementation in:

• deeptutor/learning/scheduler.py
• deeptutor/learning/models.py
• deeptutor/learning/mastery.py
• deeptutor/learning/policy.py
• deeptutor/learning/service.py
• deeptutor/capabilities/mastery/tools.py
• deeptutor/services/courses.py
• deeptutor/services/courses_state.py

RELATED ISSUES

#824 Unified assessment history across learning surfaces.

#397 Contains useful ideas around:

• concept-level learner state
• recurring errors
• cross-module evidence
• forgetting/review management
• explainable learner-state decisions

#840 Historical concept/design spaced-review issue. The relevant scheduling path appears to be fixed in current main.

WHY I THINK THIS FITS DEEPTUTOR

DeepTutor already has most of the hard infrastructure:

structured Mastery Paths

• deterministic mastery gates
• persistent attempts
• qualitative assessment
• error tracking
• spaced-review queue
• Course aggregation
• Question Bank
• multiple learning surfaces

The missing layer is mainly:

learning evidence ↓ personal retention model ↓ adaptive review timing ↓ better prioritization

This could make Mastery Path useful not only for learning a topic once, but for keeping that knowledge retrievable across an entire semester or longer.

Thanks for considering it.

Related Module

Other

Use Case

No response

Additional Context

No response