# Your File System Is Already a Graph Database

Rumproarious's April 2026 post argues that a plain folder of markdown files with wikilinks already is a graph database for personal knowledge. The reduction is blunt: files are nodes, wikilinks are edges, folders are taxonomy. No vector store, no Neo4j, no RAG pipeline. Combined with an LLM that can read the files, you get a natural-language query interface over your own knowledge.

The author runs this at serious scale — roughly 52,447 markdown files. The layout extends [[para-method|PARA]] with a few practical conventions:

- `/projects/{name}` — active projects, PARA-standard
- `/areas/{topics}` — ongoing responsibilities
- `/people/{slack_handle}` — one file per person, keyed by their Slack handle
- `/daily/{year}/{month}/{day}/` — daily logs
- `/meetings/{year}/{month}/{day}/` — meeting notes

The `/people/` and temporal (`/daily/`, `/meetings/`) scaffolding are the key additions. PARA on its own doesn't have a natural home for "notes about a colleague" or "what happened on this date" — the extended structure gives both a predictable path. Since Slack handles are stable and unique inside a company, keying people files by handle makes wikilinks from meeting notes trivial to write.

The most interesting reframe in the post is calling the whole thing a "context engineering system" rather than a knowledge base. The point isn't retrieval. It's that every LLM interaction starts cold by default — no prior decisions, no meeting history, no architectural context. If you've been writing meeting notes and decision logs all along, you can feed the relevant slice of the graph into a new conversation and get materially better output. The graph's value shows up in the *next* conversation, not the current one. This matches the philosophy behind [[llm-wiki-pattern]] — the persistent artifact is what compounds.

The author is honest about what doesn't work: automated inbox processing. Consistent rules for "what to do with this clip" keep breaking on the diversity of content types. Multiple attempts, no stable solution. This lines up with the experience in this very wiki — the `inbox/` workflow still relies on human intervention for each clip, and full automation has been deliberately avoided.

The starter recipe is minimal: create the folders, write meeting notes linked to people and projects for one week, then use whatever graph emerges to seed a real writing project. The graph doesn't need to be comprehensive to be useful — it needs to cover the specific decisions and people that come up in your next LLM conversation.

For this Second Brain specifically, the post validates the core bet: markdown + wikilinks + an LLM that maintains the graph is sufficient. It also suggests two concrete additions worth considering — a `/people/` directory and dated meeting/daily notes — that aren't currently part of the structure. See [[files-as-graph-database]] for the underlying concept and [[context-engineering]] for the broader reframe.