Code › tail-villain
Turning Results into Review Schedules
Connecting Study and Interview outcomes to FSRS so active recall quality drives the next review
The first problem with Tail Villain’s review feature was not sending a reminder. Showing a learner a topic again after a fixed number of days is easy enough. Explaining why that topic should return today, and not tomorrow or next week, is the harder part.
A fixed interval looked reasonable at first. Review something tomorrow, then a few days later, then again after a week. That already resembles a spaced repetition loop. But if a topic the learner barely explained and a topic they handled cleanly both return on the same schedule, the product is ignoring the evidence it already has.
That felt wrong for an interview practice platform. The learner is already answering questions. The AI is already evaluating those answers. The session is already saving the outcome. If the review schedule still behaves like a calendar reminder, the system throws away the strongest signal in the product.
Fixed reminders were not enough
The Ebbinghaus forgetting curve has been part of the product rationale from the beginning. Memory weakens when it is not retrieved, and one clean reading rarely survives until a real interview. Tail Villain was meant to be more than a mock interview tool. The pressure interview is also supposed to become a review event.
But the product did not need to reproduce the forgetting curve literally. I did not want to imply that one curve can predict every learner, every topic, and every context. The useful part was the underlying principle: memory needs retrieval, successful retrieval can justify a longer interval, and difficult retrieval should bring the topic back sooner.
Fixed reminders cannot express that difference. Opening a page does not prove that a memory became stronger. Seeing a notification does not count as review. In interview preparation, the gap between feeling familiar with an answer and explaining it under pressure is exactly the gap the product is trying to expose.
So I made active recall the boundary. The learner has to try first: answer, explain, hesitate, miss details, recover, or fail. That attempt is the learning event. The quality of that attempt becomes the input for the next schedule.
Study and Interview needed to feed review
Study and Interview already contained useful signals. Study asks guided questions, explains a topic, and evaluates whether the learner can work with it. Interview applies more pressure and checks depth, consistency, and recovery across a longer exchange. The final report has a better view of the session than any single turn does.
Without connecting those outcomes to review scheduling, the features stay separate. Study gives feedback. Interview produces a score. Review shows a topic again on a predetermined day. To the learner, those surfaces look like one product, but internally they behave like separate islands.
This iteration tied session outcomes back to topic review state. A topic the learner explains well can move farther out. A topic they struggle to retrieve comes back sooner. The important constraint was not to treat every small conversational score as the final learning result. A follow-up answer during an interview is useful evidence, but topic progress and review scheduling should be updated from the final report evaluation, where the system has enough context to judge the whole attempt.
FSRS became the scheduling mechanism. Instead of following a fixed table such as one day, three days, and seven days, FSRS updates item-level difficulty and memory stability, then changes the next interval based on recall quality. Strong recall pushes the next review farther away. Failed or weak recall pulls it closer.
That still does not mean the product can declare that a topic is finished forever. The UI needed to stay honest. Due topics, upcoming topics, and strengthened-memory summaries describe the current schedule and recent outcomes. They are not proof that knowledge has been locked into the learner’s head forever. The schedule keeps adapting as the learner keeps retrieving.
Quick Review reused the Study engine
I considered making review its own lightweight quiz flow. It could show a due topic, ask for an answer, score it, and update the next date. That sounds simpler, but it would duplicate the hardest parts of Study.
Study already knows how to manage topic progress, ask guided questions, carry session state, retrieve learner-specific context, and persist evaluation. Review needs the same core behavior. The difference is not the learning engine. The difference is the entry point and presentation: review starts from a due topic and has to make the next retrieval action obvious.
So Quick Review reused the Study engine. The dashboard gained a direct entry point, and the review workspace showed due topics, upcoming topics, and recently strengthened memories. Underneath that surface, the existing Study flow handled questioning and evaluation. The review layer made the timing visible: what should I retrieve now, and how did my next interval change after this attempt?
The workspace needed a few passes. The first version used oversized full-width cards, which made the page feel more like decoration than a working review list. I tightened the layout into a denser primary list with a memory summary, then added a compact expandable NEXT UP label for long topic titles that would otherwise be truncated.
That mattered more than it sounds. Quick Review is supposed to be quick. If the learner has to interpret a heavy page before they can start recalling, the loop loses momentum.
RAG supplies evidence. FSRS decides when.
The easy mistake is to collapse RAG and FSRS into one vague personalization story. They are related in the product flow, but they solve different problems.
RAG brings in learner-specific evidence: the goal, background, and Roadmap-linked context relevant to the current Study or Interview session. The same question should not behave the same way for someone preparing for a job interview, a graduate school interview, a sales pitch, or a team tryout. RAG gives the AI enough context to ask and coach from the learner’s actual situation.
FSRS does not decide which facts are relevant. It decides when a topic should return. It takes the observed recall quality and updates the next review interval. In simpler terms, RAG helps decide what evidence the session should use, while FSRS helps decide when the learner should retrieve the topic again.
Keeping that boundary matters because the product claims can otherwise get too strong. RAG does not guarantee retention just because the prompt has better context. FSRS does not guarantee memory just because it calculated the next interval. The honest claim is narrower: Tail Villain records answer quality, adjusts the next review time from that outcome, and uses the learner’s own context when the topic comes back.
That is enough. It is also much easier to test.
This work made the learning loop feel more like one system. Roadmap decides what to train. Study and Interview measure whether the learner can retrieve and explain it. FSRS turns that result into the next review date. RAG keeps the learner’s context available when the review happens.
There is still room to tune the thresholds, but that should wait until enough real review outcomes exist. Stronger retention claims would be premature. Email or push reminders can also wait. The in-product loop has to work first: open a due topic, recall before seeing the answer, get evaluated, and watch the next schedule change.
Interview preparation is not strengthened by looking at a topic again. It is strengthened when the learner has to produce an answer in their own words. The review schedule is just the mechanism that brings that moment back at the right time.