A research desk with Markdown notes, a graph view, and Git history

Obsidian is attractive for research because it does not try to own the notes. A vault is mostly a folder of Markdown files. That sounds boring, but for long projects it is exactly the right kind of boring: readable files, local control, links that still make sense outside the application, and a structure that can be versioned with Git.

I do not think a research note system should become a second research project. It should be simple enough to survive deadlines, paper revisions, teaching, and the weeks where nothing is perfectly organized. My rule is: if I cannot maintain the system when I am tired, the system is too complex.

A small vault structure

I would start with something like this:

research-notes/
  00-inbox/
  10-projects/
  20-literature/
  30-methods/
  40-meetings/
  50-teaching/
  assets/

The exact names do not matter much. What matters is that the folders describe the role of a note, not a perfect taxonomy of the world. A note about a paper goes in 20-literature/. A note about a numerical scheme goes in 30-methods/. A note about an ongoing article or code base goes in 10-projects/.

The inbox is useful because not every note deserves classification immediately. A copied idea, a meeting remark, or a quick equation can live there until it becomes clear whether it belongs to a project, a method, or nowhere.

The temptation is to make one giant note per project. That works for the first week, then it becomes a document you never want to open. I prefer smaller notes:

  • one note for a paper;
  • one note for a method;
  • one note for a benchmark;
  • one note for a decision;
  • one note for a recurring problem.

Links are useful when the notes have real boundaries. A project note can link to [[space-time cut-cell method]], [[manufactured solution]], [[Stefan problem]], or [[ICCFD 2026]]. The graph view is not the point, but it becomes a helpful diagnostic: isolated notes are probably unprocessed; over-connected notes may need to be split.

Git changes the way I write notes

Git is not only backup. It gives a history of thinking.

For research notes, commits do not need to be perfect. A useful rhythm is:

git add .
git commit -m "Add notes on reactive transfer benchmarks"

The value appears later. When a paper draft changes, when a benchmark result is replaced, or when a hypothesis quietly disappears, the history is still there. It is also easier to be honest in notes when old versions are not lost. You can rewrite a page aggressively because Git keeps the previous version.

What I would keep out of the vault

Not everything belongs in Obsidian. Large raw datasets, generated figures, build artifacts, and simulation outputs should usually stay elsewhere. The note should link to them, describe them, and explain why they matter. It should not become a fragile archive of everything.

For PDFs, I prefer a pragmatic approach. Keep the PDF somewhere stable, create a Markdown note for the paper, and write the useful content there: main question, assumptions, equations, numerical method, limitations, and why the paper matters for the current work.

A note template for papers

# Paper title

## Why I opened it

## Main contribution

## Model and assumptions

## Numerical method

## Results worth reusing

## Limitations

## Links

The important section is “Why I opened it.” Without that, literature notes become summaries detached from the project. A paper is rarely useful in the abstract; it is useful because it answers a question, gives a method, provides a benchmark, or contradicts something.

The role of AI

LLMs fit naturally around this workflow, but only as assistants. They can turn rough notes into a cleaner page, extract assumptions from a paper, propose links to existing notes, or produce a first draft of a meeting summary. They should not silently rewrite the record.

The best pattern is explicit:

Read this note and propose links to existing concepts.
Do not delete information.
Separate source-backed claims from interpretation.
List uncertain points at the end.

That keeps the vault as a human research memory, not just a pile of generated summaries.

My preferred rule

Every important idea should eventually have three things: a note, a link, and a reason. The note stores the idea. The link places it in the project. The reason explains why it was worth writing down.

Obsidian provides the writing surface. Git provides the memory. The rest is discipline.