The point of my Obsidian setup is not to have a prettier notes app.
It is to give myself a persistent working context: a place where project history, ideas, people, decisions, and half-formed observations can keep accumulating instead of disappearing into Slack threads, meeting notes, screenshots, and whatever I happened to remember that day.
At the time of this draft, the vault has roughly 5,200 markdown notes outside of my imported OSHA reference vault and more than 15,000 internal wiki links. Those numbers are not the accomplishment. They are just a sign that the system has become large enough to be useful.
Why I built it
Most of my work has a long memory.
A safety technology rollout might start as a meeting note, turn into a rough workflow diagram, become an internal implementation plan, and eventually become a public case study. A person I talk to once might matter again six months later. A problem that shows up on one project might become the pattern that explains three other projects.
Without a system, that context stays scattered.
I built the second brain because I wanted:
- More persistent context across my work. I wanted to stop rebuilding the same background every time I switched projects or came back to an old idea.
- A lightweight internal CRM. Not a sales pipeline, but a way to remember people, conversations, follow-ups, project momentum, and long-running goals.
- A knowledge base I could actually use. A place to dump raw material, connect it later, and notice patterns I would not have seen if everything stayed in isolated folders.
- A better interface with AI. The more structured my own notes are, the more useful they become as context for AI-assisted writing, research, planning, and project work.
What the system does
The vault has become part notebook, part project archive, part CRM, part research library, and part publishing pipeline.
A typical note might start as a messy voice memo, a meeting transcript, a project log, or a copied chunk of research. From there, it can become something more structured:
- a project overview
- a technical guide
- a public case study
- a person note
- a meeting briefing
- a future article outline
- a reusable skill or workflow
The important piece is that the notes are not just stored. They are linked.
People connect to projects. Projects connect to tools. Tools connect to problems. Problems connect to articles. Articles connect back to real examples from the work.
That linking is where the system starts to feel different from a folder structure. A folder tells me where I put something. A network of notes helps me see what it relates to.
The CRM layer
I do not use the vault as a traditional CRM. I use it as memory.
People notes let me track who someone is, what we talked about, what they care about, what projects they are connected to, and where a follow-up might make sense later. Meeting notes and project notes give those relationships context instead of leaving them as a list of names.
That matters because a lot of useful work happens slowly.
A conversation today might not turn into anything for months. A small detail from a project meeting might become relevant when a different team hits the same issue later. A long-term goal might look inactive from the outside but still be moving through accumulated notes, decisions, and tiny pieces of progress.
The vault gives those slow loops somewhere to live.
The knowledge base layer
The knowledge base is the messy part by design.
I need a place where I can capture things before I know exactly what they are. Ideas, transcripts, OSHA references, project decisions, article fragments, product notes, screenshots, and rough observations all need to land somewhere before they can be organized.
Obsidian works well for this because the structure can emerge after the capture.
I can start with a rough note, add a few links, come back later, and connect it to a project, a person, a technical guide, or a future article. The note does not have to be perfect to be useful. It just has to be findable and connected enough that it can resurface when it matters.
The publishing layer
A lot of the public writing I want to do starts inside the vault.
Some notes stay private forever. Some become internal documentation. Some become public case studies or Lab posts. The same system can hold all three, as long as I am careful about what leaves the vault.
For public posts like this, the goal is not to expose the underlying notes. It is to describe the system at a high level: why I built it, what role it plays, and what it has changed about the way I work.
That is the privacy line I want to keep. The vault can contain specific work, people, and project context. The public Lab version should only explain the architecture and the lesson.
What changed
The biggest change is that my work compounds more cleanly now.
Before, each project produced some useful residue, but a lot of it stayed trapped in the project itself. Now the residue becomes reusable context. A workflow from one build can become a template. A project lesson can become a case study. A meeting note can become a relationship thread. A random observation can become the start of an article.
The system does not make the work automatic. It makes the work less lossy.
That is the real value of a second brain for me. It is not about perfect organization. It is about reducing the amount of useful context that disappears between projects, tools, meetings, and ideas.
The broader lesson
A second brain is less about note-taking than retrieval.
If the system only captures information, it becomes another junk drawer. If it helps old context show up at the right time, it becomes leverage.
That is what I am trying to build with this vault: not a personal archive for its own sake, but a working context layer that helps me move faster, remember more, and connect ideas across projects that would otherwise stay separate.