The campaign is a folder. The apps just visit.

One folder, several hands

A vault in play looks like this. Every note carries a stable oa_id and names its own generator, so links survive renames and every claim has a source.

your-campaign/
├── campaign.md              GM-owned: calendar, party position, tone
├── regions/<region>/        written by Hexes: gazetteer, hex notes,
│   ├── region.md            travel table, encounter & weather aids
│   └── hexes/
├── settlements/ · sites/   stubs and keyed places
├── npcs/ · factions/      the cast; declared relationships
├── quests/ · sessions/    the running game (spec 0.2: reveals, dates)
├── commissions/             work orders: a stub site → a keyed dungeon
├── player/                  derived player-safe vault (this app writes it)
└── _index/                  compiled ids and relationships (derived)

Who writes what

• Hexes on Automatic writes regions: the gazetteer, hex notes, settlement, site and faction stubs, travel and encounter aids, and a commission envelope per dungeon site.
• Dungeons on Automatic answers the commissions with keyed sites.
• Campaigns on Automatic writes only the derived and sanctioned lanes: the player/ tree, reveal states, the campaign clock, faction goal checkmarks, and tonight's session-note skeleton.
• You own everything else, in any editor — and the editor this was built around is Obsidian, which gets wikilinks, backlinks and the graph for free.

Shaped for Obsidian

The format does not require an editor, but it was written with one in mind and the design shows. Campaigns on Automatic has no text editor in it and never will, so the assumed setup is Obsidian open on the same folder — you write there, the lens reads here, both watching the same files.

What the format borrows

• The folder is the vault. Open your campaign directory in Obsidian and it works: no import, no conversion, no second library. The two apps read the same bytes off the same disk.
• Wikilinks are the prose link. Machine-readable cross-references live in oa_refs frontmatter, but the links the generators write into prose are ordinary [[note]] wikilinks, so backlinks, autocomplete and the graph light up with nothing configured.
• Frontmatter is plain YAML. Every field the spec defines is an ordinary property Obsidian can display, search and sort on.
• No plugins. Nothing in the spec depends on a community plugin, a theme or a paid add-on. If one ever helps, it will be a suggestion and not a dependency.

What it does not assume

• Obsidian is not part of this family. It is a separate app by separate people, unaffiliated with and unendorsed by anything here. No On Automatic app ships it, installs it, or checks whether you have it.
• Nothing breaks without it. The vault is UTF-8 markdown in ordinary folders. Git, grep, VS Code, Vim and every other editor read and write it just as well; only the graph, backlinks and wikilink autocomplete are Obsidian's to hand you.
• Sync is yours. The apps touch only the folder you point them at. How that folder reaches your other machines — Obsidian Sync, git, a shared drive, nowhere at all — is outside the spec and outside the app.

The rules that keep it safe

• One writer per file. Each note is owned by the app that minted it; nothing else touches it. Cross-app references live in oa_refs frontmatter, never in app state.
• Generated prose sits in fences. Machine text lives between oa:generated markers. Everything you write outside them is never overwritten, by anyone, on any pass.
• Locks freeze what you've settled. Mark a note's content, narrative or geometry with oa_locks and regeneration leaves it alone.
• Reveals are data. Spec 0.2 gives notes, sections and relationship edges a reveal state; the player view and the player/ derivation both follow the same leak rules, so the table sees one consistent world.
• No app required. It's markdown. Git, grep, a text editor and Obsidian all work; the reference validator is the format's gate, not any app.