murmur-vault

name	murmur-vault
description	How to coexist with Murmur's notes in an Obsidian vault — note anatomy, front-matter keys, managed sections you must never edit, wikilink discipline, entity stubs, where files live, the locked-folder disappeared-file rule, and the add-freely/prefer-append coexistence contract. Use when reading, editing, or creating notes in a vault that Murmur also writes to.

Coexisting with Murmur in an Obsidian vault

Murmur is a meeting-notes app that writes plain Markdown notes into this Obsidian vault. Its database (not the vault) is the canonical copy of every note it generates. You can read everything freely, add your own notes anywhere, and append to Murmur's notes — but there are managed regions you must never edit and a few rules that keep the two of you from destroying each other's work.

Note anatomy

A Murmur meeting note is a single Markdown file that begins on its first line with a YAML front-matter fence. The keys Murmur emits are English and fixed — never rename or translate them (Obsidian parses them by name):

---
title: Sprint Planning
date: 2026-06-30
duration_minutes: 45
tags: [meeting]
participants: [Anna, Bob]
---

Additional front-matter keys Murmur may inject, all English and content-free:

• ai-provider: / ai-model: — which AI produced the note (provenance).
• privacy-cloud-calls: 0 — stamped when the note was produced entirely on-device (nothing left the machine). For a cloud summary you instead see privacy-egress-host: (the destination it went to) and privacy-pii-redacted: (how many PII items were scrubbed first).

After the closing ---, the body uses headings like ## Summary, ## Key points, ## Decisions, ## Action items (GitHub-style - [ ] checkboxes), and ## Notes. The exact sections vary by the note's style, but the front-matter contract above is constant.

Managed sections — NEVER edit inside these

Murmur owns certain regions of a note and rewrites them programmatically. Treat them as read-only:

• ## Re-Truth updates — an append-only log of facts that later meetings superseded. It holds callouts of the form > [!superseded] <date> (on the note whose fact changed) and > [!supersedes] <date> (on the note that changed it). Murmur keeps these idempotent and in order; editing them by hand corrupts that log.
• ## Pinned moments — anchored timestamps with Obsidian block references (^block_id).
• ## Meetings inside an entity stub (see below).
• The YAML front-matter block and its keys.

Editing content outside these managed sections is fine (see the coexistence contract), but never rewrite the callouts, the block-ref anchors, or the front-matter keys.

Wikilink discipline — link only to notes that exist

Murmur links conservatively: when it references another note it uses [[Exact Title]], and it only ever links to a title that already exists as a file in the vault — it is given the list of existing note titles and told never to invent a link. Match that discipline. Before you write a [[Some Note]] link, confirm a note with that exact title (the filename without .md) exists in the vault. A dangling wikilink to a title Murmur can't resolve is noise Murmur would never have created.

Note titles are file stems. Obsidian-reserved characters (* " \ / < > : | ? # ^ [ ]) never appear in a Murmur-created filename — it sanitizes them to spaces — so a title with those characters won't resolve.

Entity stubs

For a recurring person or project, Murmur maintains a stub note under a kind directory — People/<Name>.md, Projects/<Name>.md — that starts with # <Name> and a ## Meetings section listing - [[<meeting title>]] backlinks, one per meeting that mentioned them. Opening a person's page in Obsidian then shows every meeting with them; the graph self-assembles. The ## Meetings list is a managed section — Murmur keeps it de-duplicated. Add your own prose elsewhere in the stub, but don't hand-edit the backlink list.

Where things live

• Meeting notes land at the vault root by default, or in an AI-chosen subfolder when auto-filing is on. The filename is YYYY-MM-DD HHmm - <title>.md.
• Standalone notes live under Notes/… (each note-folder maps to a Notes/<folder> path).
• Memory rollups — Murmur's periodic syntheses of what it has learned about you — live in brain/memory/*.md, each with murmur: memory-rollup in its front-matter. These are regenerated by Murmur; treat them as managed.

The disappeared-file rule: locked ≠ deleted

Murmur can lock (seal) a folder. When it does, it encrypts that folder's notes and removes their .md files from disk. The files reappear, byte-for-byte, when the user unlocks the folder — the canonical content is safe in Murmur's encrypted database the whole time.

So: a note that vanished from the vault is very likely locked, not lost. Never "restore" or recreate a note that disappeared — you'd be forking content that still exists, sealed, in Murmur. If a file you saw earlier is gone, assume its folder was locked and leave it alone.

The coexistence contract

Murmur's database is the source of truth for the notes Murmur generated. When it needs to update one of those notes, it rewrites the file from that database. Follow these rules so your work and Murmur's survive each other:

1. Add new notes freely, anywhere. Notes you create are yours; Murmur never touches a file it didn't create. This is the safest and most useful thing you can do — new syntheses, summaries, index pages, and explorations all belong to you.
2. Prefer appending under your own heading over rewriting a Murmur-generated note. Add a ## <your section> at the end and write there. Appending is safe; a wholesale rewrite of a Murmur note is the risky operation, because Murmur may later re-derive that file from its database.
3. Never edit inside a managed section (front-matter keys, ## Re-Truth updates, ## Pinned moments, an entity stub's ## Meetings list).
4. Expect Murmur to protect your out-of-band edits. When Murmur is about to rewrite one of its own notes and finds it changed on disk since it last wrote it, the intended behavior is to preserve your version as a sibling file (named like <Title> (external edit 2026-07-16 1430).md) rather than overwrite it — so your edit is never silently destroyed. If you see such a sibling appear, it's Murmur telling you it had to re-derive the canonical note and set your edit aside for you to reconcile. (Until that guard ships in your installed version, assume a rewrite of a Murmur-owned note can be overwritten on Murmur's next update — which is exactly why rule 2 says prefer append.)