Runtime

Scheduler

Policy-driven concept scheduling for support, failure, spacing, and next-concept selection.

Route: /docs/scheduler

The scheduler is concept-level, not question-level. It answers:

• how many clean passes a concept has
• when the concept becomes eligible again
• whether it is in recovery or retention territory
• which concept should appear next

The canonical repo docs adjacent to this layer are:

• docs/guided-repetition-policy.md
• docs/question-quality-contract.md
• docs/readiness-truthfulness.md

By default, a concept masters after three independent passes and spaces at gaps of 2, 5, and 8 turns. A supported pass shortens the next gap; a failed attempt triggers recovery.

Why the scheduler stays generic

Consumer apps still own:

• prerequisite gating
• section or exam rollups
• UI wording
• special mastery bars

The scheduler stays policy-first so each product owns its own workflow semantics.

Typical flow

1. Build an initial schedule from concept IDs.
2. Apply outcomes as the learner answers.
3. Ask for the next eligible concept.
4. Aggregate the result into app-local dashboards or planning snapshots.

The scheduler feature page shows a minimal before/after state transition.

Adjacent showcase pages

• Guided repetition ladder walks the light/hard/recovery-light ladder with attempt budgets and named selection reasons.
• Readiness scoring and phase state shows the coarse readiness signal and the six-value phase vocabulary consumers can roll up without overclaiming.