Your Second Brain, Answered by AI: Obsidian Plus a Model That Reads Your Vault

Obsidian stores notes as plain Markdown in a folder you own, which makes your vault the easiest high-value corpus an AI assistant can read. Structure it for retrieval (dated filenames, a one-line summary at the top, frontmatter for project and system, explicit links), then ask it the questions with a fourteen-month lag: why is the cut-off 15:30, have we seen this failure before, what did we promise in March. Require the filename in every answer.

Somebody asks you, in a meeting, why the settlement cut-off is 15:30 rather than 16:00. You know you know this. It was a workshop, maybe fourteen months ago, and there was a reason involving a downstream batch. You say you will come back to them. You never do, and next quarter somebody proposes changing it and nobody can produce the constraint.

That specific failure is what a second brain is for. This is part eight of The AI Analyst, and it is where the notes you have been keeping stop being a write-only archive and start answering questions.

Why is a vault of Markdown files the best corpus you have?

Because of four properties that no note-taking app gives you at once.

They are files. Plain text, on your disk, in a folder. Any assistant with filesystem access reads them directly. No export, no API, no integration, no vendor permission. The whole setup is pointing a tool at a path.

They are complete. Your vault holds what the official record does not: the thing a developer said in passing, the reason behind a decision rather than the decision, the pattern you noticed but never wrote up. Confluence holds conclusions. Your notes hold the reasoning, and the reasoning is what people ask for later.

They are yours. You wrote them, so you can assess whether an answer drawn from them is right, in a way you cannot for a corpus somebody else wrote.

They are stable. Markdown from 2019 opens today. Whatever assistant you are using in 2030 will read these files.

If you have not built the vault yet, start with Obsidian as an analyst’s second brain for the structure and the analyst’s second brain for the capture discipline. This article is the layer on top: what changes when a model can read all of it.

How do you connect an assistant to the vault?

Three routes, from simplest to most capable.

Point a terminal assistant at the folder. Claude Code or an equivalent, opened in the vault directory. It can list, search, and read every file. This is the most capable option for analyst questions because nothing is chunked or filtered: the assistant decides what to read, follows links between notes, and can grep for a term you half remember.

cd ~/vaults/work
# then ask, in plain language, with the assistant running here

A filesystem MCP server. Connect your assistant to the vault folder through a Model Context Protocol server scoped to that one directory. Same capability, available inside your normal assistant interface rather than a terminal. Part five covers what MCP is and how the scoping works; here the scope is one folder, read-only, which is about as contained as a connection gets.

An Obsidian plugin. Several plugins call a model with the current note, or with a retrieval index over the vault, as context. Convenient for writing inside a note. Weaker for the cross-vault questions below, because retrieval returns the chunks that scored highest on similarity rather than everything relevant, and the answer you need is often in the note that used different words.

Start with the first. It is the one that makes the vault feel different.

How should the vault be structured?

Not beautifully. For retrieval. Four habits do almost all the work, and all four also help the human reader, which is why they survive contact with a busy week.

1. Date every filename. 2026-03-14-payments-workshop-cutoff.md. Chronology becomes readable without opening anything, and “what was decided before the March release” becomes a question about filenames rather than content.

2. One-line summary at the top. The first line of every note says what the note is. Workshop on settlement cut-off. Decision: 15:30, driven by the 16:00 downstream batch in the ledger. This single line is the highest-leverage habit in the whole system: it is what a model reads when scanning forty candidate files to decide which three to open in full.

3. Frontmatter for filtering. A handful of fields, used consistently:

---
project: pay-modernisation
system: [settlement, ledger]
type: workshop        # workshop | incident | decision | investigation | reading
people: [ops-lead, dev-lead]
date: 2026-03-14
---

Consistency matters more than the schema. Five fields you always fill beat fifteen you fill sometimes, because a filter that misses half the notes is worse than no filter.

4. Link explicitly. [[2026-01-08-ledger-batch-timing]] is a stated relationship, and a stated relationship beats any similarity score. When an assistant follows links, it walks the reasoning you already did rather than reconstructing it from word overlap.

That is the whole structure. Do not build a taxonomy. Analysts who build taxonomies stop taking notes within a month, and an empty well-organised vault answers nothing.

The questions worth asking your vault

Not “summarise my notes.” These are the ones with a lag, which are the ones you currently fail at.

Why did we decide this?

Search the vault for anything about the settlement cut-off time.

Build a timeline: every note that mentions it, the date, what it
says, and the reasoning given.

Then state the current position and what constraint drives it.

Cite the filename and the line for every claim. If the reasoning
is not in my notes, say so rather than reconstructing it.

Fifteen seconds, and you answer the meeting question instead of promising to come back. The final instruction is the important one: without it, a model will supply a plausible rationale for the cut-off, because there always is one, and you will repeat it as fact.

Have we seen this failure before?

Read every note of type: incident.

I am investigating: payments stuck in PENDING with no downstream
event, starting around 15:45.

Find any previous incident with a similar mechanism, even if my
notes describe it in different words. For each: filename, date,
what happened, what the root cause turned out to be, and why you
think it is related.

Rank by how similar the mechanism is, not the symptom.

“Different words” and “mechanism, not symptom” are what make this work. You wrote 2024’s version as “stuck payments” and 2026’s as “missing settlement confirmations,” and no text search connects them. The mechanism is the same both times, and the fastest route through an incident is knowing that. This is the vault paying back everything it cost, and it pairs with how a technical BA investigates a failed payment and reading production logs.

What did we promise this stakeholder?

Find every note mentioning the operations lead over the last 9
months.

List every commitment made to them or by them: what, when, by
whom, and the current status if my notes say.

Flag anything that looks unresolved.

Filename and date for each.

Run this before any significant meeting with anyone. Walking in already knowing what was promised in March, and that two of those things quietly lapsed, is the difference between a defensive conversation and a controlled one.

Where do my own notes contradict each other?

Read all notes with project: pay-modernisation.

Find contradictions: two notes that cannot both be correct.

Quote both, with filenames and dates, and say which is more recent.
Do not resolve them.

Uncomfortable and valuable. Your vault contains things you believed in January and things you learned in June, and the January version is still sitting there looking authoritative. Running this quarterly is how the vault stays a source rather than an archive of former beliefs.

What should I have written up and did not?

Read notes from the last 30 days.

List anything that looks like a decision, a risk, or a system
behavior that is only recorded in my personal notes and probably
should be in the team's shared documentation.

For each, say which shared artifact it belongs in (specification,
decision log, runbook, data dictionary).

This is the one that converts private value into team value, and it is the honest answer to the criticism that a personal vault is hoarding. Run it monthly and publish two or three items. Over a programme that is the difference between a knowledge base and your knowledge.

Require the filename, every time

One rule makes the whole system trustworthy: every claim cites a filename.

“The cut-off was agreed in March because of a downstream batch” is unverifiable and, worse, feels verified because it is specific. “2026-03-14-payments-workshop-cutoff.md, line 22” is a five-second check. Add it as a standing instruction and reject any answer that arrives without it.

This matters more in a vault than anywhere else in this series, because you half-remember the content. A model’s reconstruction of something you vaguely recall is the most convincing wrong answer you will ever be given, since it matches the shape of the memory. The filename is the only defence, and it is a good one.

Keep the vault clean at capture time

Your vault is probably the most complete unofficial record of your programme that exists. Treat it that way.

• No customer data, ever, at capture time. Not names, not account numbers, not the transaction reference from the incident call. Write “the disputed transaction” and keep the reference in the ticket where it belongs. A vault you plan to sanitize later is a vault you will stop using, because sanitizing is never today’s task.
• No credentials. Obvious, routinely violated, because a token pasted into a note during an investigation is the fastest thing to do at the time.
• Think about the model you point at it. An approved enterprise assistant or a locally running model is the right answer for a vault containing internal programme detail. The full classification is in the guardrails.
• Back it up. It is a folder. git init in the vault, commit daily, and you have history, diffs, and recovery. Git for analysts covers the four commands this needs.

Where the vault sits in the system

It is your working memory, and it is deliberately not the team’s record.

Vault	Confluence
Half-formed observations	Agreed conclusions
What a developer said in passing	What the specification says
Patterns across incidents	The incident report
Your reasoning	The decision
Fast, private, unedited	Published, governed, reviewed

That privacy is the feature. You write freely in the vault precisely because nobody is reading it, and freedom of capture is what makes it complete enough to be worth querying. Publish the parts that belong to the team, using part six, and keep the rest.

Feed it from part seven: decisions and contradictions from every workshop land in the vault as a dated note with a one-line summary. Within a quarter you have something that answers questions no colleague can, and within a year you become the person the programme asks, which is a career position more durable than any tool skill.

The takeaway

Point an AI assistant at your Obsidian vault and it stops being an archive. Structure for retrieval with dated filenames, a one-line summary at the top of every note, consistent frontmatter, and explicit links. Ask the questions that have a fourteen-month lag: why did we decide this, have we seen this failure before, what did we promise, where do my notes contradict each other, and what should I have published. Require a filename with every claim.

Keep customer data out at capture time, version it with git, and feed it from your meeting pipeline. The compounding is slow and then it is not: nothing changes for two months, and then one afternoon you answer in fifteen seconds a question that has been open for a year.

Next: part nine, where all of this grounding gets pointed at the biggest artifact an analyst owns, a complete test plan built and traced end to end. The full path is on The AI Analyst.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Knowledge Management, Obsidian, Productivity