Skip to content
Cameron Mills

All projects

The revision engine

Spaced practice sessions that save every answer before the next one

A question-by-question practice engine that follows up until understanding breaks, keeps a weak-spot queue, and saves each answer to a sourced tracker before marking the next, in a chat session or on my dashboard.

Problem

Reading notes back is a poor test of understanding. I wanted practice that asks one question at a time, pushes until the answer breaks, remembers what I got wrong, and never invents material the sources do not hold. A session can also crash or lose its context, so no answer should be lost when it does.

Approach

Split the work cleanly. Everything deterministic (what to ask next, spacing, re-tests, saving) is code. Only judgement, writing a question and marking an answer, goes to a model, as one call per turn that returns JSON the page renders.

Architecture

Each subject has a Markdown tracker built from captured study material. Every row names the file it was read from, and a row an agent inferred is marked as inferred and kept in a separate section. Each tracker opens with a coverage block listing what the material on disk does not hold, and a session says so rather than inventing it. A point heard only in a lecture transcript is marked unverified and never becomes a model answer until a slide matches it.

A session opens with cold re-tests and due weak spots, then new points, and every reply ends with a question. Re-tests are capped at a third of questions, and a missed point comes back three questions later, at most twice.

What I built

A 1,768-line engine runs the same rules on my dashboard as the chat skill does. Both save through one 453-line writer, which changes only the answered row and the weak-spot queue, where a weak answer gets a re-test date seven days out. The write is atomic under a lock file, and a failed save is queued and replayed at the end of the session. A selftest runs a scripted session and checks the tracker bytes against the writer's own command-line output, so both routes leave identical files. Worked multi-step exercises take their model answers from a small solver, and a selftest fails if a printed figure drifts or the totals stop reconciling.

Results

The first question used to wait 30.7 seconds on a model call. A pool written ahead now serves it, refilled after each session and nightly. The next two questions are written while I answer, and a drill card from a prepared bank fills any write that runs long. Drill cards are practice and never touch the tracker.

What didn't work

A smaller, cheaper model was tried for writing questions and was no faster under load, so the speed came from writing ahead rather than from the model.

Stack

  • Python
  • Claude Code
  • Claude Sonnet
  • Markdown