← Lab notebook

Learning in order, and seeing what I actually retain

5 min read

The problem

I own and build this site and the AI Maker Lab channel — this is a build log, not an independent review.

In the AI era, my backlog of tools, models, and concepts grows faster than any course I take can cover it. I keep adding things I think I should understand: a model I have not tried, a framework whose abstractions I cannot explain yet, or a concept I used once without knowing whether I could use it again. The list is easy to extend. My position inside it is hard to see.

I can tell when I watched a lesson or copied an example. I cannot reliably tell which parts I still know, which parts depend on something I skipped, or which part should come next for the thing I want to build. Those are different questions, but my notes and course histories leave them mixed together.

That is the problem I want to work on. I do not need another larger pile of material. I want a map of the material, a deliberate way to move through it, and an honest view of what I can still retrieve and use.

Why courses and tutorials keep failing me

I have started more courses than I have finished, and I cannot say which parts I still know. The courses and tutorials I have used usually put lessons in one linear order. That order tells me what the author placed next, but it does not show me the prerequisite structure behind the topic.

The same six topics shown twice: as a single linear list, and as a branching prerequisite structure in which several orders are possible.
For my learning problem, the map exposes dependencies that a single sequence leaves implicit.

When I get stuck, I cannot see whether the problem is the current lesson, an earlier concept I only half understood, or a missing branch the course never covered. When I finish a section, the completion mark records that I reached the end. It does not tell me whether I can explain the idea without the lesson open or apply it after time has passed.

In my own learning, that makes watching and retaining too easy to confuse. A familiar page can feel settled while I am looking at it. Later, I still do not have a visible record of what I can recover without the page.

I want to stop treating the table of contents as the knowledge model. A course can still be useful to me, but I need a separate structure that shows what depends on what and records more than whether I reached the last screen.

The app idea

I am starting with an idea for three connected parts. They are design intentions for software that does not exist, not features I have shipped.

Three intended parts of the planned app: a learning map from goal to prerequisite path, a methods engine that puts retrieval and spacing in the flow, and a mastery view whose per-topic state ages.
The design separates what to learn, how to revisit it, and how to represent its current state.

1. A learning map. I intend to represent topics as a prerequisite graph indexed by a goal. Instead of beginning with “Which course should I take?”, the app would begin with “What do you want to be able to do?” It would then resolve that goal to a path through the topics that need to come first. I want the map to make missing foundations visible without turning every possible topic into an equal priority.

2. A methods engine. I intend to put the study method inside the learning flow rather than leave it as a separate act of willpower. In Dunlosky and colleagues’ 2013 review, practice testing and distributed practice received the authors’ high utility ratings, and the same review cautions that a moderate rating did not mean ineffective and a low rating did not mean useless. That is why the methods engine starts with retrieval practice and spacing. The companion research piece, Learning methods that work, goes further into the evidence; here, the review’s utility ratings and cautions are the limit of the claim. In the app idea, the method would shape what happens next: retrieve something, revisit it after an interval, and use the result to choose the next step.

3. A mastery view. I intend to give each topic a visible state rather than a permanent “learned” checkbox. That state would be decay-aware, so an old success would not have to look identical to a recent one. I do not yet know whether the right representation is a number, a small set of labels, or evidence attached to each topic. I do know what I want it to resist: the idea that seeing something once turns it into settled knowledge forever.

This app does not exist yet, and nothing here is a measured result. These three parts are the current shape of the problem, not a roadmap commitment or a claim that the design will work.

Build in public

This piece is a living record that will be extended as the project progresses. I want it to remain a record of the questions, design changes, dead ends, and decisions that shape the build rather than a polished story written after the uncertainty disappears.

This piece has a narrower job. It records why I am starting, what I currently intend to build, and what remains unresolved.

I may change the map, the methods engine, or the mastery view as I learn more. A change would be part of the record, not evidence that an earlier version produced a result. Until there is software and an evaluation, this remains a problem statement and a design intent.

Open questions to readers

Which topic would benefit most from a prerequisite map rather than another linear syllabus?

Would a mastery number be more useful than a state label such as “learning,” “practiced,” or “stale,” or would the number imply more precision than the evidence supports?

Where should decay be visible: on the topic itself, in a review queue, or only when an old skill blocks a new goal?

How much of the prerequisite graph should be shown at once before the map becomes another backlog?

Which topic do you most need a map for?

Sources

Keep reading