ADR-0001 · Google Drive as SSOT

A separate Obsidian vault synced via Syncthing (peer-to-peer across Mac, Phone, VPS) was considered as the primary knowledge store, with Google Drive as a secondary collaboration layer. Google Drive was chosen as the single source of truth instead. Originally, an rclone mount on the VPS was envisioned for agent access; the final access path is the Google Workspace API (see ADR-0011).

The deciding factors: Francois’s existing PARA structure and years of history already live in Google Drive. Running two sync systems (Google Drive Desktop + Syncthing) on the same files risks conflicts. Google Drive natively handles collaboration (.gdoc, .gsheet) which a Syncthing vault cannot. The only gap — editing .md on mobile — is solved by Markor + Hermes via Slack, not by adding an entire sync layer.

Considered Options

• Syncthing + Obsidian vault (separate from Google Drive): Provider-agnostic, local-first, excellent for .md. But requires migrating existing content, creates two sources of truth, and adds Syncthing ops on every device.
• Google Drive SSOT + rclone on VPS: Keeps existing workflow, one source of truth, no migration needed. Trades provider-agnosticism (Google dependency) for simplicity and continuity. (Access path since superseded by the Workspace API — ADR-0011.)

Consequences

• The estate depends on Google Drive availability. If Google locks the account, the Workspace API access and all agent access stops until resolved.
• Weekly backups to external HD mitigate this risk.
• Switching to a different cloud storage later requires migrating files and reconfiguring the access layer (the API client OAuth, or rclone if a mount is ever reintroduced — rclone supports 70+ backends, so the VPS-side change is minimal).