Building a Second Brain
I have solved the same problem more than once. Not a similar problem — the same one. The same broken Citrix StoreFront error, the same Caddyfile tweak that finally got HTTPS working on an internal host, the same n8n quirk where a webhook node silently swallows a malformed payload. I worked it out, felt clever, moved on, and six months later sat staring at the identical symptom with no idea what I had done. Past-me had the answer. Past-me did not write it down.
That is the failure this project exists to fix. Not a productivity hack, not a journalling fad — a deliberate piece of personal infrastructure that captures what I learn and makes it retrievable, including by a machine. The notes are plain-text Markdown in a Git repo. The retrieval and reasoning layer is Atlas, my local AI assistant. Together they turn a static pile of notes into something that can answer questions, summarise, and occasionally surprise me by connecting two things I had forgotten were related.
I want to be honest up front about the thing most “second brain” content skips. The system is worthless without the habit. The architecture is the easy part. I will get to the discipline, because it is the part that actually decides whether any of this works.
The problem with where knowledge lives
An engineer’s knowledge is scattered. Mine was spread across a notes app on my phone, a different notes app on my laptop, forty browser tabs I was afraid to close, screenshots of error messages in a folder called Screenshots, Slack DMs to myself, a few Google Docs, and — mostly — my own memory, which is a lossy cache with no backup. When I needed something, finding it was a search across five tools, none of which talked to each other, and a lot of the time the answer was only in my head and had already evaporated.
The deeper problem is that this scattering makes you solve things twice. The cost of writing something down is paid once, immediately, when you are tired and just want the problem to be over. The cost of not writing it down is paid repeatedly, later, with interest, every time you rediscover the same fix from scratch. Past-you was lazy and present-you is paying the bill. I have done this enough times to take it personally.
Then there is the tool-of-the-month trap. I have migrated my notes more than once because the shiny new app promised to organise my life. Evernote, then a wiki, then one of the block-based outliner tools everyone raved about. Each one locked my notes inside its own database and its own export format that never quite round-tripped. One of them changed its pricing to something absurd. Another simply shut down and gave me sixty days to get my data out. Every migration lost something — formatting, links, attachments, the will to live. I learned the hard way that the app is not the asset. The notes are the asset. If the notes only exist inside someone else’s application, you do not own your knowledge, you are renting access to it.
If your knowledge only opens in one company’s app, you do not own it. You are renting it.
The principles I settled on
After the third migration I stopped chasing tools and wrote down the principles instead. These are non-negotiable now, and everything else is an implementation detail.
Own your data. The notes live in a Git repository I control. Not a service. A repo. I can clone it, back it up, grep it, and read every file with cat on a machine that has never heard of my note-taking app. If every tool I currently use vanished tomorrow, the knowledge would be completely intact.
Plain text, forever. Markdown. Nothing else. Markdown is readable as raw text, renders nicely when you want it to, diffs cleanly in Git, and will still open in fifty years. Proprietary formats are a bet that a company outlives your career. Plain text is a bet that text files keep working, which is the safest bet in computing. This is the same conviction that made me move this site off Blogger and onto Hugo and Markdown in Git.
Atomic, linked notes. One idea per note, where practical, with links between them. A note about a Caddy directive links to a note about the reverse proxy migration, which links to the homelab overview. The value is not in any single note; it is in the connections. Knowledge is a graph, not a filing cabinet, and I want the structure to reflect that.
Capture first, curate later. The biggest killer of any note system is friction at the moment of capture. If writing something down requires choosing the right folder and the right tags and the right title, I will not do it when I am mid-incident at 11pm. So capture is dumb and instant: throw it in the daily note, no decisions required. Curation — turning that raw capture into something durable — happens later, deliberately, when I have the headspace.
Write for future-you. Every note is a letter to a version of me who has forgotten everything. That means context, not just the answer. Not “add the directive” but “Caddy wasn’t issuing a cert for the internal host because the ACME challenge couldn’t reach it — switch that host to the DNS challenge with a build that includes the provider, here’s the working version and why”. Future-me is a stranger. Be kind to the stranger.
The system that actually works
The repository structure is deliberately boring. Boring survives. I tried clever taxonomies before and abandoned all of them; the only structure I have kept for more than a year is the one that maps to how I actually think.
second-brain/
├── daily/ # one file per day, the inbox: YYYY-MM-DD.md
├── projects/ # active work, one folder per project
│ ├── atlas/
│ └── energy-optimiser/
├── references/ # facts, configs, how-tos — the lookup layer
│ ├── caddy.md
│ └── citrix-storefront.md
├── evergreen/ # distilled, durable notes — my actual thinking
└── meta/ # templates, conventions, the README
Four kinds of note, each with a job. Daily notes are the inbox — every capture lands here first, timestamped, unprocessed. Project notes are working memory for whatever is live, and they are allowed to be messy because they are temporary. Reference notes are the lookup layer: the working Caddyfile, the Graph app-registration steps, the exact ollama command that pulls the right quant. Evergreen notes are the crown jewels — distilled, rewritten, linked ideas that represent what I actually understand about something, not just what I copied from a terminal.
Naming and linking conventions matter more than they look. Files are lowercase-kebab, dated notes are YYYY-MM-DD, and links are relative Markdown links between files, [reverse proxy](../references/caddy.md). I avoid spaces in filenames so the repo plays nicely with every tool. Tags live in front matter, not scattered through the text, so they are machine-readable. That front matter is the same idea as on this site, and it is what lets a program reason about the notes:
---
title: "Caddy not issuing a cert for an internal host"
type: reference
created: 2025-11-03
updated: 2026-02-18
status: evergreen
tags: [caddy, docker, tls, homelab]
links:
- "[[reverse-proxy-migration]]"
- "[[homelab-overview]]"
summary: >
The ACME challenge could not reach an internal-only host, so no cert
ever issued. Fix: switch it to the DNS challenge. Reasoning below.
---
That summary field is not decoration. It is the thing the AI layer leans on hardest, and writing a one-line summary forces me to know what the note is actually about.
There is also the question of what overlaps with the public site. I run a private brain and a public notebook, and the line between them is real. The private brain holds client specifics, credentials-adjacent detail, half-formed opinions, and anything with someone else’s name on it. The public site — this site — is the curated, sanitised, generalised version: the lessons with the names filed off. An evergreen note about why most AI projects stall in the private brain becomes, after a lot of editing, a public article like why most AI projects fail. The private brain is where I think; the public site is where I publish thinking I am willing to stand behind. Plenty crosses the line; plenty never does, and that is the point of having two.
The AI layer that makes it a second brain
A Git repo of Markdown is a very good filing cabinet. It is not a second brain. A filing cabinet only gives back exactly what you put in, exactly where you put it, and only if you remember it exists. The thing that turns the filing cabinet into a brain is the layer that can reason over the whole of it at once — and that layer is Atlas.
Atlas runs retrieval-augmented generation over the notes. The repo is chunked and embedded into a vector store; when I ask a question, the relevant chunks are pulled back and handed to a local model running on Ollama on the GPU box along with my question. The architecture and the tool-calling are described in full in the Atlas write-up; here I care about what it does for the notes specifically.
Three things, mainly. It retrieves — I ask “how did I fix the StoreFront login loop?” in plain English and get the answer with the source note linked, instead of guessing which of forty files it lived in. It summarises — point it at a noisy project folder and it gives me the state of play without my re-reading three weeks of daily notes. And occasionally it surfaces forgotten connections — because retrieval works on meaning, not exact words, it pulls back a note I had completely forgotten was relevant. That is the closest this gets to feeling like a genuine second brain: it remembers things I have stopped remembering.
Then there is the part that makes it more than a search box. Atlas can act, through n8n. A query is not just answered, it can trigger a workflow — pull the latest tenant findings, kick off a health check, file a new note from a chat, fire a webhook. The note system becomes both the memory and a control surface.
The loop is the whole idea. Capture, curate, connect, retrieve, act — and acting or querying often generates the next capture, so it feeds itself.
I have to be honest about the limits, because the hype around this stuff is dishonest. RAG is only as good as the notes. If a note is wrong, the AI confidently tells me the wrong thing, now with a citation that makes it look authoritative. If a note never got written, retrieval returns nothing useful and the model fills the gap with a plausible guess. And critically, AI does not fix bad capture habits. It cannot retrieve what you never captured. A second brain built on an empty first brain is just an expensive way to generate confident fiction. The AI is a multiplier on the quality of the underlying notes, and a multiplier works in both directions.
The discipline, which is the actual product
Here is the part I would bolt to the front door. The system is worthless without the habit. I have built three versions of this with progressively nicer tooling, and the version that worked was not the one with the best architecture. It was the one I actually used every day.
The discipline has three loops, on three timescales.
Daily capture. Every working day, everything interesting goes into that day’s daily note. No filing, no decisions, no friction — just dump it. An error and its fix, a thing I learned, a half-idea, a link worth keeping. The bar is deliberately on the floor, because a note captured badly is infinitely more valuable than a note captured perfectly tomorrow, which is to say never.
Weekly review. Once a week — Friday afternoon, usually, when I am too fried for real work but fine for tidying — I go through the week’s daily notes and process them. Most lines get deleted; they were noise. Some get promoted into a reference note. A few project notes get updated. This is where dumb capture becomes structured knowledge, and skipping it is how the inbox becomes a landfill nobody can use.
Promoting to evergreen. The rarest and most valuable move. Occasionally a reference note has been touched enough times, or an idea has recurred enough, that it deserves to become evergreen: rewritten properly, linked into the graph, made durable. This is the same instinct as the difference between building knowledge and building documents — a document is written once and rots; an evergreen note is alive and gets better each time you return to it.
Miss the daily capture and the well runs dry. Miss the weekly review and the inbox rots. Miss the promotion and you have a swamp of raw notes with no distilled understanding on top. I have failed at all three at various points, and every time the system’s value collapsed within a fortnight. The architecture does not save you. The habit is the product. Everything else is plumbing.
What I got wrong
I over-engineered the early versions. The first attempt had a fourteen-category taxonomy I designed before I had written a single note, and I spent more time deciding where things went than writing them down. I abandoned it. The structure should grow from the notes, not the other way round.
I also tagged everything obsessively and linked almost nothing, which is exactly backwards. Tags are weak; they group things that happen to share a word. Links are strong; they encode an actual relationship I decided was real. The graph lives in the links. I now spend my curation effort on linking and barely touch tags.
And I reached for the AI layer too early. I built embeddings and retrieval over a corpus of about thirty thin notes and wondered why the answers were rubbish. They were rubbish because the corpus was rubbish. RAG over a small, shallow set of notes is worse than just reading them. The AI only started earning its place once there were enough good notes for retrieval to have something real to find.
Where this goes next
The honest near-term roadmap is mostly about closing the loop between capture and the AI. Right now I curate by hand; I want Atlas to do a first pass on the weekly review — proposing which daily-note lines look like reference material and drafting the promotion — leaving me to approve rather than to do. That is squarely on the list of what I’m building now.
I want capture from more places. A Telegram bot that drops a line straight into today’s daily note. A clipper that saves a page as Markdown with its source. Voice capture transcribed locally, so a thought on a walk becomes a note without me touching a screen. The principle holds — lower the friction of capture and the well stays full.
And I want Atlas to get more proactive about surfacing connections without being asked — a weekly digest of notes it thinks are related but I have not linked, turning the forgotten-connection trick from something I have to prompt into something that arrives on its own. Carefully, because a system that nags is a system you start ignoring.
The thing I keep relearning
The point of a second brain is not to remember everything. It is to make it cheap to remember the right things, and trivial to find them again, so the expensive part of my mind is free to think rather than to store. I do not need to hold the exact Caddy directive in my head if I trust that ten seconds of asking Atlas will return it with its reasoning intact.
But the trust is earned by the boring daily work, not by the architecture. I built a clean repo, a sensible structure, and a genuinely useful AI layer on top, and none of it mattered until I started actually writing things down, every day, even when I did not feel like it. The second brain is real. It just turns out the first brain still has to show up and do the writing.