Why Files
The vault is a plain folder of Markdown files. It is the assistant’s entire long-term memory, and it is deliberately boring: readable by any editor, browsable in Obsidian, versioned by git, portable to any machine. No databases, no vendor memory features, no state stored anywhere else.
Two non-negotiable properties drove the choice:
- Portability. Vendor memory features tie the assistant’s brain to one product and often one machine. A folder outlives all of that. Switch models in three years and the new one reads the same files.
- Auditability. Every change to the assistant’s beliefs is a git commit you can read, diff, and revert. When it is wrong, you can see exactly when it became wrong, and why.
Three Questions, Three Folders
The structure is called ACE, and it maps to the three questions an operator asks: what do I know, what happened, and what am I pushing. Readers of Nick Milo’s LYT framework will recognise the shape.
Atlas — What Is True
Everything that stays true over time.
- One hub note per venture. Every company, side project, investment, or life area gets
Atlas/ventures/<slug>/VENTURE.md— and family, health, home, and money are ventures with equal standing. There is deliberately no central portfolio blob. Cross-venture synthesis happens by reading several files at brief time, which keeps context from bleeding between unrelated areas. - People are one note each, at
Atlas/people/<Name>.md. A person who appears in two ventures is still one note, referenced by wiki-link from both. The backlinks panel becomes a free CRM. - Projects are one note each, under the venture they belong to, with frontmatter for status and outcome so they are queryable across the portfolio. A venture with more than about seven active projects cannot be reviewed weekly; excess moves to
someday.md. - Hierarchy lives in frontmatter, not folders. Ventures stay one folder deep; a
parent:field expresses ownership trees. Re-parenting is a one-line edit, not a file move — and status (active, dormant, archived) is a frontmatter field too, never a folder name, because folders are permanent homes and status changes. - Decisions, identity, anti-patterns, team charters all live here too:
decisions.md,about-me.md,anti-patterns.md,team/<slug>.md. - Optionally,
resources/inside a venture, for long-lived source artifacts that are neither projects nor decisions: a manifesto, an externally prepared methodology, a reference framework the venture operates against.
Calendar — What Happened
Daily notes (which double as the assistant’s curation log), meeting notes, and an archive of every brief ever delivered. Nothing here is ever rewritten; history stays history.
Efforts — What Is Moving
An inbox/ where every raw capture lands before triage; the routine definitions for the daily and weekly briefs; the cadence file; the feedback log; and a reports/ folder where deliverables land.
The Tree
vault/ <- a git repo, and an Obsidian vault
├── CLAUDE.md <- the constitution
├── HOME.md <- dashboard note for the human
│
├── Atlas/ <- evergreen knowledge
│ ├── about-me.md <- role, voice, escalation triggers
│ ├── decisions.md <- the decision log
│ ├── anti-patterns.md <- known failure modes
│ ├── ventures/
│ │ ├── INDEX.md
│ │ ├── _template/ <- copy when adding a venture
│ │ ├── _archive/ <- retired ventures
│ │ └── <slug>/
│ │ ├── VENTURE.md <- the hub note
│ │ ├── decisions.md <- venture-local tactical calls
│ │ ├── someday.md
│ │ ├── projects/<project>.md
│ │ └── resources/ <- optional durable artifacts
│ ├── people/<Name>.md <- one note per person
│ └── team/<slug>.md <- one charter per sub-agent
│
├── Calendar/ <- time-indexed
│ ├── daily/<YYYY-MM-DD>.md <- daily note + curation log
│ ├── meetings/
│ └── briefs/archive/
│
├── Efforts/ <- active work
│ ├── inbox/ <- raw captures land here
│ ├── routines/ <- daily-brief.md, weekly-review.md
│ ├── cadence.md <- the ritual schedule
│ ├── feedback.md <- corrections, read every session
│ └── reports/ <- deliverables
│
├── delivery/ <- channel config (no secrets)
├── .claude/agents + commands <- runtime for sub-agents and slash commands
└── .beads/ <- the task graph (JSONL, git-tracked)
Editing Judgment
The assistant has full edit authority inside the vault, so the constitution gives it heuristics rather than gates:
- Additive over rewrites. Append a dated note rather than rewording an existing paragraph.
- Never paraphrase the human’s voice. Decision reasoning and identity statements keep their original wording.
- No cosmetic edits. Every edit must reflect a fact change.
- When unsure whether an edit adds value, skip it and surface it in the brief. Letting the human decide is cheap; a wrong edit costs trust.
- Structural changes get a decision record first. Creating or archiving a venture, renaming a slug, changing a tool default — the record is written before the action.
Provenance, Everywhere
When a fact traces back to a capture, the assistant leaves an HTML comment beside it: <!-- src: inbox/2026-04-26-voice-3.md -->. Invisible in rendered Obsidian, durable in plain text. Six months later, “why do we believe this?” has an answer — and when the belief turns out to be wrong, so does “where did the wrong belief come from?”
The Two Places State Must Never Go
- Not in the daily note as a capture surface. The daily note is for structured reflection (top three, decisions made, curation log). Captures go to
Efforts/inbox/. A daily note used as the only inbox is 1,000 lines of unprocessed bullets by month three. - Not in the model’s memory features, and not in the constitution. Both drift; neither is portable; neither is diffable.
See it
The demo vault has the vault this site describes, as one fictional founder’s assistant actually built it. It is fictional, and it was built by Claude Code sessions running the bootstrap prompt — not written by hand.
Hand this to your chief of staff. Plain Markdown: /guides/the-vault.md. Tell it: "Read this guide and tell me what in our system it would change."
Also for your Claude: whole-site index · bootstrap prompt · guide feed