A Memory With More Than One Layer

My second brain had plenty of memory. It was just asking the same files to remember very different things.

I found that out on August 24, while building a place in The Hub to preserve design decisions. When we were done, the agent helping me decided that the design of this new mechanism did not need a write-up. The conventions were already in a README, so why write the same thing twice?

Because the README said what we had built. The conversation held why we built it that way. I had to ask for the reasoning to be preserved, while we were literally building the place to preserve it.

Documents do not carry the whole case

In Day Zero, the foundation was a structured Markdown vault: contexts, conventions and a history of work. By late August, my personal administration was testing that structure much harder than any software project had.

A household repair, a passport renewal and a vehicle inspection all produce documents. They also produce questions. What is the current status? Who am I waiting for? Which fact still needs checking? What happens next?

A Drive folder can contain every letter and still answer none of those questions. A session log can record that I looked into something without telling the next session whether I finished.

I already had partial answers scattered across the vault. Some running cases lived under Tracking/. The administration protocol described how to recognize related documents. A larger personal dossier had its own directory and index. Three good ideas, three different places.

The new Dossiers/ folder gave them one home.

A working document next to the archive

The split is simple: Drive holds the source documents, a Hub dossier holds the working understanding of the case.

That means a summary, a status, a timeline, document references and open actions. The dossier knows where the evidence lives without copying every attachment into Git.

There are two kinds of document in there. A running dossier follows a finite case through active, waiting and closed. A permanent register keeps facts about something that keeps existing: the car, the house, a set of subscriptions.

That distinction stops a repair case from becoming the accidental home of everything I know about the house. The case closes. The house register stays.

References use Drive IDs as the canonical identity, with paths as readable hints. Folders get moved and renamed all the time; an ID survives that. A dossier can point at files across several administrative collections without caring where they currently sit.

I also resisted building yet another reminder system. Expiry dates belong in the registers, and the task mechanism The Hub already has can point at them. Another scheduler would just have been another place to forget to look.

Current state and history have different jobs

Building the dossiers exposed the next gap immediately.

The session log could say I introduced the folder, describe the schema and record the delivery. But the logging convention is deliberately short: one sentence and at most five bullets. It is an index I can scan across months of work, and it is good at that precisely because it is short.

So where does the why go? Why do running cases and permanent registers share a folder? Why are source references a list? Why call it a dossier at all? Those were real design choices, with alternatives discussed and rejected.

Stuffing all of that into the session log would make the log worse at its job. Putting it in the README would mix operating instructions with history. Leaving it in the transcript means a future reader has to reconstruct the discussion from a chat.

I needed something between the short entry and the raw conversation.

The obvious folder was in .gitignore

My first instinct was Output/. The repository instructions already sent generated artifacts there.

Then I checked .gitignore. Output/ is deliberately untracked: a dump zone for previews, temporary reports and generated files. Great for that. Useless as the versioned home of a decision I want to find again in six months.

So Reports/ was born, for durable write-ups linked to a session. The first report it ever held was, fittingly, the dossiers design.

A report carries the context, the findings or design, and the open ends. Its frontmatter points back to the originating session and the related files; the session entry links forward to it. It captures the reasoning at that date. If I learn something new later, that gets its own report rather than a silent edit.

The shape of the memory became clear:

Place	Question it answers
Source archive	What document supports this?
Dossier or register	What is the situation now?
Session entry	What happened during this work?
Report	Why did we decide this?
Resumable reference	Where is the original conversation?

These layers have different update rules, and that is the whole point. A register should change the moment a fact changes. A report should keep saying what the decision rested on at the time. Treat both as “notes” and you lose exactly that difference.

A folder does not make an agent use it

The debrief workflow got a step that asks whether a session warrants a report, plus a separate command to write one mid-session or afterwards. That helps. It does not decide for the agent what is worth keeping; that judgment is still the hard part.

The structure also did not magically finish the work. By September 5, both scan intakes were empty, while about ninety open checkboxes remained across twenty dossiers. Filing was way ahead of resolving.

Good to see, actually. An empty intake tells me the incoming pile is processed. Open actions tell me whether the underlying cases are done. Those are different dashboards.

A broken fridge shelf

The best test of all this came a month later, and it was not an architecture question at all.

On October 3, a glass shelf in the fridge lost one of its plastic edge strips. I started where the layers say to start: the appliance register. It knew the model and the year. From there the agent and I checked which replacement part actually fit (the part numbers an AI chat had suggested earlier did not), ordered the full shelf, and filed the invoice in the house administration on Drive.

The register now holds the part number, the measurements and a link to the invoice. The session log has one entry saying it happened. Next time something in that fridge breaks, nobody has to reconstruct the repair from a chat thread.

Small, boring, and exactly what I built it for.

Memory I can enter at the right level

I don’t want every future session to start by rereading every source. I also want to be able to dig down when a summary smells wrong.

The layers give me both routes. Start with the current state, follow the relevant action or decision, open the evidence or the conversation only when needed. The routine path stays short; the reasoning stays recoverable.

The Hub started as a place to put information. This gave the information a job description: some files keep the evidence, some keep the present, and some explain how I got here.

That is a memory I can actually work with.