Explainable Priority Scoring Under Capacity

A recommendation list is useful only if it fits the available time and explains why each item won. This implementation uses an explicit score rather than a black-box prediction:

priority = deadline urgency + goal weight + weakness + forgetting risk
         + prerequisites + continuity - effort penalty - overload penalty

Scores rank; constraints decide

Candidates receive components from known operational signals. Confirmed deadlines and due reviews are protected. Active language and computer-science work receive continuity weight. Estimated effort reduces the chance that one large item consumes the whole day.

After sorting, the selector applies hard constraints: at most five items and no more than the requested capacity. Lower-ranked new study is deferred instead of being presented as an impossible plan.

Reasons are output data

The API returns both the recommendation and a sentence derived from the winning signals. This makes it possible to inspect a surprising result and write assertions against policy. It also prevents the UI from inventing a reason that differs from server behavior.

What the tests establish

The selector was exercised with 30, 60, 120, and 240 minute budgets. Tests verify that totals never exceed capacity, the count never exceeds five, and urgent academic work remains protected. These are deterministic policy tests, not evidence that the score predicts educational success. Future calibration can compare recommendations with completion and recall outcomes, but changes should remain explainable and versioned.