The short version

Learn is a structured mode for working towards understanding a topic. Where Quick Revision supports a direct conversation, Learn adds an explicit sequence: probe, plan, teach and recap. The model proposes a learning step, but the application controls how that step becomes a question, a route for approval or a feedback card.

The initial question is intended to locate a useful starting point. A student asking about integration might need help with powers, notation or the meaning of an antiderivative. Starting every learner with the same explanation can miss that distinction. Learn asks for evidence before proposing a short route, and the student can request changes or ask to skip diagnostics.

A loop with an approval gate

The server combines the conversation with saved learning state and asks for a structured present_learning_step response. That response contains a stage, explanation, focus and interaction. Instead of interpreting arbitrary prose as a quiz, the application receives named fields it can validate and render consistently.

Learn mode: probe, plan, teach and recap
Figure 1. Learn’s four stages. The loop is adaptive within a conversation; the approval gate is explicitly checked by the application.

During calibration, an ambiguous goal should produce a preference question rather than a graded test. For a clear goal, the model is instructed to check a relevant prerequisite. A wrong answer should lead to a nearby diagnostic or repair, rather than automatically expanding into a longer lecture. The prompt also asks it not to test indefinitely.

The plan contains two to seven concepts, identified by stable IDs and dependency links. Before teaching begins, the learner approves that plan or requests an adjustment. The server restricts unapproved sessions to the earlier stages and rejects a teaching step if approval has not been recorded.

From a wrong answer to a better question

Imagine a learner preparing to study exchange surfaces. A preliminary question asks what happens to a cube’s surface-area-to-volume ratio when its side length doubles. Answering “it doubles” may indicate that the student is tracking area while overlooking volume. It could also be a hurried calculation. The next step should distinguish those possibilities.

01

Probe. What happens to surface area when every length doubles?

Area scale factor=22=4\text{Area scale factor}=2^2=4
02

Separate the prerequisite. Now consider volume.

Volume scale factor=23=8\text{Volume scale factor}=2^3=8
03

Reconnect the ideas. Compare the two scale factors.

(S/V)new(S/V)old=48=12\frac{(S/V)_{\mathrm{new}}}{(S/V)_{\mathrm{old}}}=\frac{4}{8}=\frac{1}{2}

A route might then move from geometric scaling to diffusion distance, and finally to specialised exchange structures. That is an illustrative plan, not a fixed biology syllabus embedded in the code. The model creates the route from the learner’s goal and context; the student can amend it before beginning.

The important unit is a concept that can be explained and checked. A correct response is evidence for the next decision. It is not a permanent label that the learner “knows biology”.

Questions are more than formatted text

Learn’s checkpoint format supports preference choices, objective quizzes, plan approval and non-interactive recaps. Quiz questions use stable option IDs. Correct answers refer to those IDs, so the server can randomise presentation order without confusing the answer key.

Keeping the answer key private until submission
Figure 2. The private/public checkpoint boundary. The public card omits the correct IDs and explanation until an attempt has been submitted.

The application checks the number of options, uniqueness of IDs, validity of the answer key and presence of an explanation. Plan validation also checks dependencies and rejects cycles. A learner cannot quietly skip the approval gate just because a generated response says that the lesson has begun.

After submission, the server checks the selected option IDs and makes feedback available. “I don’t know yet” provides a route to uncertainty without forcing a guess. Earlier checkpoints cannot be submitted as if they were the current step. These controls help maintain coherent state, but a structurally valid question can still contain a subject error or a poor distractor.

How the learning state is built

The model proposes the next step; the application persists the route, stage, approval state, active concept and short observations about known points and gaps. Learning cards are stored alongside their message and the student’s answer. On the next turn, that context gives the model an account of what has already happened.

DecisionImplementation purpose
Stable concept IDsKeep a route recognisable as wording changes.
Dependency checksPrevent a plan from depending on missing concepts or on itself through a cycle.
Private quiz feedbackKeep the answer explanation out of the initial public checkpoint.
Stored attemptsLet the next turn respond to the actual answer rather than an imagined one.

This is adaptive orchestration over a language model, not a separately trained cognitive diagnosis engine. The distinction matters: a list of gaps is a conversational summary, not a psychometrically calibrated assessment. The design keeps these observations small and tied to evidence in the exchange.

For visuals, Learn can accept a constrained polynomial plot when appropriate. That path validates coefficients and domains rather than allowing arbitrary generated executable code or SVG. Most of the learning interface is built from reusable question and outline components.

The research behind the questions

Roediger and Karpicke found that retrieval tests improved delayed retention of studied prose compared with repeated study in their experiments. That supports considering retrieval as part of learning, rather than assessment alone. Their study does not evaluate AI-generated multiple-choice cards or Working. Roediger & Karpicke, 2006.

Self-explanation research provides another design connection: asking a learner why a step works can reveal more than whether they recognise an option. We infer that a checkpoint plus a short explanation may be more informative than a tap alone; that specific interface needs its own evaluation. Chi et al., 1989.

A useful Learn session therefore needs more than a sequence of easy successes. It should include an opportunity to explain a relationship, work without the example, and return to an idea after a delay. The current conversation loop supports questions and repair, but this article does not claim that it implements a validated spaced-repetition scheduler.

What would count as evidence?

Good evaluation would ask whether students can use a concept without the original cues. A practical study could compare matched learning tasks, assess prior knowledge, and include both immediate and delayed questions. Transfer questions should change the surface details, so recognition of familiar wording cannot do all the work.

Question quality also needs direct review. A distractor might accidentally be defensible, a diagram might omit an assumption, or a generated explanation might reveal the answer before submission. The public-card boundary prevents deliberate exposure of the stored key, but it cannot by itself detect every semantic leak in the explanation.

References and implementation notes

  1. Roediger, H. L., & Karpicke, J. D. (2006). Test-Enhanced Learning: Taking Memory Tests Improves Long-Term Retention. Psychological Science, 17, 249–255.
  2. Chi, M. T. H., et al. (1989). Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems. Cognitive Science, 13, 145–182.

Implementation inspected: learning.mjs for the prompt, schema, dependency validation, public-card projection and stored attempts; server.mjs for model requests and approval restrictions; learning-ui.js for cards and route rendering. The workflow describes the current implementation rather than a published learning trial.