JM

Jordan Martinelli

Frontend engineer · React / TypeScript

Note · Sep 2026

Studied is not the same as verified

How a real exam problem became a deliberately unforgiving learning protocol, and where that strictness stops helping.

I was studying dense medical concepts where the wrong answers were designed to look almost right. Re-reading helped me recognize the material, but recognition was not what the exam required. I had to retrieve the right answer while several plausible alternatives competed for it.

That exposed an uncomfortable gap: I could feel familiar with a subject without being able to produce a reliable answer.

Familiarity is a poor progress signal

Most study tools are good at recording activity. They can tell me that I opened a chapter, reviewed a card, or answered eight questions out of ten correctly. Those numbers describe what I did. They do not tell me what will hold when the wording changes or the answer is no longer in front of me.

An 80% score is especially ambiguous. It can mean I understand the subject with two small gaps. It can also mean I keep missing the same essential distinction. Averaging both cases into one reassuring number hides the part I need to inspect.

I did not need another measure of exposure. I needed a test that made uncertainty visible before the exam did.

The method existed before the app

The first protocol was deliberately small. I would answer a short set of questions. One mistake ended the attempt. The same set returned in a different order, and I repeated it until every answer came back clean.

The restart changed the task. Each answer had to survive as part of a complete run, not as an isolated success that could be absorbed into an average. Shuffling the retry also removed a useful but misleading cue: remembering that the third answer was false is not the same as understanding why it is false.

This was faster for me, but not because it made the material easier. It reduced the time spent repeating what was already stable and made the weak distinctions impossible to ignore.

Turning the protocol into product rules

Drill is the repeatable version of that method. Its product decisions follow the protocol rather than a conventional flashcard loop.

Runs stay short, usually seven to thirteen cards, because a clean attempt needs to remain attainable and diagnostically useful. A set of fifty cards would make one failure expensive without revealing much about where the understanding broke.

Answers are framed as Truths and Traps. The binary choice is intentionally narrow: it asks whether a precise claim holds, then leaves the explanation available for inspection. This works well for close concepts and plausible misconceptions. It is less useful when the skill itself is open-ended.

There is no partial score at the end of a Run. The useful result is whether the set survived clean. Behind that verdict, individual cards can still move through states such as Untested, Weak, Unproven, and Mastered. The interface separates evidence about a card from completion of the current attempt.

Those rules are stricter than the interfaces people already know. That is deliberate, and it is also the main design risk.

Friction only helps when it carries information

Restarting after one error can create focus. It can also become mechanical repetition. If the learner understands the correction immediately, replaying an oversized set adds effort without adding evidence. That is why the size of a Run is not a cosmetic setting; it controls the cost of failure.

Binary answers have a similar boundary. They are effective when the challenge is distinguishing between claims that are almost true. They cannot prove that someone can construct an argument, perform a procedure, or explain a system from first principles.

The method also depends on the cards being good. AI can turn source material into a first draft quickly, but fluent wording is not the same as a valid claim. A generated card still needs to be inspectable, editable, and traceable to something the learner trusts. Generation reduces setup time. It does not transfer responsibility for the material.

I would not use Drill as the only layer of learning. It verifies a deliberately constrained kind of recall. Reading, explanation, practice, and feedback still have different jobs.

A verdict, not a feeling

The product began with a personal problem, but the more useful design question was broader: what should an interface report when confidence is cheap and evidence is not?

Progress bars and scores are attractive because they make effort visible. They become misleading when the representation is more precise than the knowledge underneath it. Drill chooses a smaller claim. It does not say that a subject has been learned forever. It says that this set of answers survived this protocol now.

That is less comforting than a percentage. It is also something I can act on.