The One Choice That Decides Everything

There's one decision in this whole course you cannot undo later.

Not "hard to undo." Cannot. Not with a bigger computer, not with a clever migration, not by paying someone. If you get it wrong, the only fix is to start collecting again from zero.

It's three columns in your first table.

1. What every tutorial starts with

A table is a spreadsheet the computer owns. Columns across the top, one row per saved note.

Here's the one you'll find everywhere:

CREATE TABLE notes (
    id        TEXT PRIMARY KEY,  -- a name for this note
    content   TEXT,              -- what it says
    embedding BLOB               -- the numbers that let you search by meaning
);

There's nothing wrong with it. It saves. It finds. It works on day one.

It has also already decided — before you write another line of anything — that your memory can never clean itself up.

2. What you'll build instead

CREATE TABLE notes (
    id            TEXT PRIMARY KEY,
    content       TEXT,
    embedding     BLOB,

    importance    REAL    NOT NULL DEFAULT 0.5,  -- how much this has earned its place
    last_opened   TEXT,                          -- empty means never opened
    times_opened  INTEGER NOT NULL DEFAULT 0     -- proof it was useful
);

Three extra columns. That's the entire difference between a memory that ages well and one that rots.

importance — how much this note has earned. Starts at a middling 0.5. Goes up when the note proves useful, drifts down when it doesn't.

last_opened — when this was last actually wanted. Empty means never.

times_opened — how many times it genuinely helped answer something.

3. Why they must exist on day one

Here's the trap, and it is worth reading twice.

Suppose you skip them. You build save, connect, and find. It works beautifully. Six months later you have 4,000 notes, answers are getting mushy, and you think — right, time to add the cleanup from Course 09.

So you add the three columns. Every existing row gets the default: times_opened = 0. Never opened. last_opened — empty. Never opened.

Now cleanup runs for the first time. It looks at six months of accumulated notes and sees four thousand things that have apparently never been useful to anyone, because nobody was counting.

It cannot tell your insulin note from a shopping list you saved by accident in March. Both say zero.

You cannot go back and ask. There is no record of what you looked up last spring. That information existed for one instant — the moment you asked the question — and if nothing wrote it down, it is gone permanently.

Adding these columns late is not an upgrade. It's an amnesia event.

Your memory keeps all its notes and loses its entire sense of which ones mattered — which is precisely the thing cleanup needs in order to be safe.

4. The bit that's even easier to miss

Having the columns is not enough. Something has to write to them.

When your memory looks something up and hands back five notes, four lines of code have to record: these were used, right now.

# After returning results — credit the ones that actually contributed.
UPDATE notes
   SET times_opened = times_opened + 1,
       last_opened  = ?
 WHERE id IN (...)

Four lines. Leave them out and you have three columns that stay at zero forever, which is exactly as useless as not having them — but looks fine, because the table has the right shape.

There's a subtler version of this mistake that we hit while building the real system, and it's worth flagging now so you recognise it in Course 04:

Credit only the notes that actually made the final answer. Not every note the search looked at along the way. Get that wrong and every note gets credited constantly, every counter climbs together, nothing is ever distinguishable from anything else, and cleanup can never find a single thing to remove.

The system reports success every night. It removes nothing. It takes months to notice.

5. So the rule

Build the shape for the finished system, before you build the finished system.

You don't have to write cleanup today. You have to make it possible to write cleanup in six months, which means recording the history it will need — from the first note you ever save.

This is the only place in the course where that's true. Everything else can be added later. Not this.

Try it

5.1 — Find the same trap elsewhere.

Think of a system where someone had to go back and add tracking after the fact. Step counts before you owned a fitness tracker. Spending before you had a budgeting app.

The data isn't hidden — it never existed. No amount of effort recovers it.

That's the shape of the mistake. Recognise it and you'll spot it in your own projects for years.

5.2 — A design decision that's yours to make.

importance starts at 0.5 for every note — dead middle, no opinion.

But some notes clearly matter more at the moment you save them. A door code. A dosage. Your kid's allergy.

Should the system let you mark something as important when you save it? And if it does — should cleanup be allowed to overrule you later?

There's a real argument both ways. Mark it high and never touch it, and you've promised to keep something forever based on one decision made in one moment. Let cleanup overrule you, and the system can delete something you explicitly said to keep.

Write down where you land and why. The system you build in Course 09 uses a shield with a specific number in it — 0.14 — that answers exactly this question. You'll see whether you agree with it.

What's next

Stop taking my word for it. Next lesson you run two memories side by side — same notes, same questions — and watch one of them fall apart.