My cofounder is also my girlfriend. We run a music company together, work on separate projects, and plan a shared life.
One Obsidian vault holds all three areas. It has six top-level zones, a separate inbox for each of us, self-hosted sync, and one instruction file that tells AI tools where information belongs.
The structure works because access and ownership are different. We can both access the vault, but every note still has a clear home and, when necessary, a clear owner.
The vault has six zones
Our Vault/
├── 00-inbox/ new material, split by person
├── 01-business/ company strategy, finance, operations,
│ content, product, and meetings
├── 02-mine/ my projects, learning, and personal notes
├── 03-hers/ her projects, learning, and personal notes
├── 04-us/ travel, home, health, shared finance, goals
├── 05-resources/ contacts, references, and templates
└── CLAUDE.md rules for AI working with the vaultThe folder choice answers a practical question:
- Does this decision belong to the company?
- Does it belong to one person’s work?
- Does it belong to our shared life?
- Is it a reusable resource rather than a project note?
Material that has not been classified goes into the inbox. We do not force a final location while capturing an idea quickly.
One vault preserves useful connections
We tried separating work, personal projects, and shared life into different vaults. The separation looked clean, but links stopped at each vault boundary.
A contact may work with the company, introduce somebody for her project, and appear in planning for a shared event. In one vault, a single contact note can link to all three contexts. In separate vaults, the same person becomes several disconnected records.
One vault is useful when the connections matter and both people genuinely agree to shared access.
It is not private storage. A folder named mine or hers does not create a security boundary. If either person needs information the other must not access, that information belongs in a separate encrypted location with separate credentials.
Every captured item has an owner
The inbox is split into two folders. A note sent by me begins in my inbox; a note sent by her begins in hers.
This matters when a voice message contains a task. The system already knows who created the item and who should answer a follow-up question.
We use a small Telegram bot for quick capture. It can turn text, links, images, or voice messages into timestamped files. Voice is transcribed and stored beside the original message.
The bot is a convenience, not the source of truth. The Markdown file in the vault is the record we keep and review.
A weekly review closes the inbox
Once a week, we process new items.
For each note, we:
- identify the subject;
- decide which zone owns it;
- add links to existing people or projects;
- extract any task and assign its owner;
- leave unclear items in the inbox with a question.
An AI can propose this classification, but it should not guess when the author, folder, or sensitivity is unclear.
Skipping the review for several weeks turns the inbox into another pile. The capture tool only helps when a regular process moves useful material into the working system.
CLAUDE.md gives AI the same rules
At the root of the vault, CLAUDE.md describes how an AI should work with the folders.
A simplified section looks like this:
## Identify the person
If the author is unclear, ask which of us is speaking.
## File locations
- company decisions → 01-business/meetings/
- company finance → 01-business/finance/
- unclassified ideas → the author's folder in 00-inbox/
- shared plans → 04-us/
## Limits
- do not delete files without confirmation
- do not move notes between personal zones without asking
- do not send external messages without approval
- do not invent missing ownership or financial detailsThe file should contain real rules from the way the two people work. Generic instructions such as “be helpful” do not resolve a disagreement about where a financial note belongs.
Each person should use their own account and credentials when a service supports multiple users. Shared files do not require shared logins.
We self-host synchronization
The vault contains Markdown files on our devices. We use the community Self-hosted LiveSync plugin with CouchDB on a small server behind HTTPS.
Self-hosting gives us control over the server and backups. It also makes us responsible for updates, access control, encryption settings, monitoring, and recovery.
Before relying on the setup, test four things:
- a change made on each device reaches the other;
- two simultaneous edits create a visible conflict rather than silent loss;
- a new device can be added without exposing credentials in chat history;
- a backup can actually restore the vault.
Sync is not backup. A bad deletion can synchronize perfectly to every device.
The most expensive mistake was putting code inside the vault
I once started a software project inside the vault folder. Installing its dependencies created hundreds of megabytes of files. LiveSync tried to process them, the database failed, and both devices had to be paired again.
We now keep code repositories outside the vault. The vault’s .gitignore and sync exclusions block dependency folders, build output, virtual environments, and large binaries.
We also added external backups and created the shared-life zone earlier. Without 04-us/, travel plans and home decisions kept landing inside company folders.
Start with the boundaries
Do not begin by installing CouchDB or writing a bot.
First decide:
- what both people may access;
- what must remain separate;
- which top-level zones match the real areas of responsibility;
- how a new note receives an owner;
- who reviews the inbox and when;
- what an AI may read, move, edit, or send.
Then choose the sync and capture tools.
The shared-vault template contains the six-zone skeleton, a CLAUDE.md starting point, a self-hosted LiveSync guide, and the Telegram inbox specification. Adapt the boundaries before copying the automation.