What a Memory Actually Has to Do

Most courses list four jobs: save, connect, find, use.

Here's the full list.

The first four make a database. The last three make it a memory.

The four everyone builds

Save. Write the note down somewhere it survives a restart.

Connect. Record that this relates to that.

Find. Get it back later from a vague, half-remembered question.

Score. Notice which memories actually got used.

That fourth one already gets skipped, and skipping it is fatal — we'll come back to it in the next lesson, because it's the single most expensive mistake in this whole course.

The three almost nobody builds

Fade. Anything you haven't touched in a while gets quieter. Not deleted — quieter. It ranks lower, so it stops crowding out things that matter.

This is the gentlest possible intervention and it does most of the work. A note you haven't wanted in six months probably shouldn't be beating one you used yesterday.

Rehearse. What you actually used gets stronger — and so does whatever it's connected to.

That second half is the interesting part. Use a note about your dog's medication, and the note about your vet gets a little stronger too, because they're linked. Over time the memory naturally organises itself around the parts of your life you actually live in.

Your brain does this while you sleep. It's the closest thing here to something genuinely borrowed from biology, and it's the reason the whole system is named after the hippocampus.

Let go. Delete what's clearly dead. Faded to nothing, never used, old enough to be sure.

And write down what you deleted, and why, before you delete it. Every time. No exceptions. That record is what makes the difference between a system that forgets on purpose and one that just loses your things.

Why the order matters

These aren't a menu. They run in sequence, every night, and the order is load-bearing:

fade  →  let go  →  settle  →  rehearse  →  reward

Fade before let go, or deletion has nothing to work with — everything still looks equally strong, so either you delete nothing or you delete at random.

Settle before rehearse, or you strengthen three copies of a fact that should have been merged into one, and now the duplicate is three times as loud as the truth.

Swap any two and the whole thing still runs. No error. It just quietly ruins itself over months.

Course 09 builds all five in order, and explains what breaks for each swap.

None of this is hard

Worth saying plainly, because "seven jobs" sounds like a lot:

Each one is under 80 lines of code. The whole memory engine in your starter kit is about 300 lines and has zero dependencies — plain Python and SQLite, both of which came with your computer.

This isn't difficult. It's just that almost nobody thinks to build the last three, because the first four already look like they work.

Try it

4.1 — Score yourself against the list.

Think about any note-taking system you've used — Notes app, Evernote, Notion, a folder of text files, a shoebox of paper.

Which of the seven does it do?

Almost certainly: save, yes. Connect, maybe. Find, sort of. Score, fade, rehearse, let go — none.

That's why every note system you've ever used eventually became a place notes go to die. You kept saving. Nothing ever left. Finding got harder. Eventually you stopped opening it.

You have already lived through this problem. You just didn't have a name for it.

4.2 — The one you'd skip.

Of the seven, which would you be most tempted to leave out of a first version?

Most people say score — it feels like bookkeeping with no payoff.

Next lesson is about why that specific answer is the most expensive mistake you can make here, and why you cannot fix it later.

What's next

Three extra columns in your very first table. Leave them out and no amount of work afterwards can put things right.