On Automatic
The Campaign Vault

The campaign is a folder. The apps just visit.

Hexes exports into the Campaign Vault: a plain folder of markdown notes with YAML frontmatter, publicly specified, readable in Obsidian with zero apps installed. Dungeons on Automatic writes into the same folder. The vault is yours whether or not any of them stay installed.

What Hexes writes

One export produces a region tree like this. Every note carries a stable oa_id, so links keep working after renames.

your-campaign/
├── regions/greenfield/
│   ├── region.md              overview, factions sketch, road & travel table
│   ├── hexes/                 one note per content hex (terrain, features,
│   │   ├── hex-0302.md        obstacles, residents, field description)
│   │   └── ...
│   ├── settlements/           a stub per town — Towns on Automatic's future inbox
│   ├── sites/                 a stub per dungeon site
│   └── state/                 the machine copy Hexes reopens (hoa-*.json)
├── factions/              faction notes + relationship map
├── commissions/
│   └── the-sunken-grotto.request.json   work order for Dungeons on Automatic
└── _index/                compiled ids and relationships (validator output)

The rules that keep it safe

Sites become dungeons by paperwork

Hexes places a dungeon site and knows only what the overworld knows: where it sits, what terrain surrounds it, roughly what lives nearby. That's exactly what goes in the work order.

The format is deliberately boring: versioned spec, JSON schema, reference validator and an example vault live in the public CampaignsOnAutomatic repository. If you want to write tools against it, that's the contract.