One-Way Publishing

One place is authoritative (the vault); everything else — Google Tasks, Projects, a mobile subset, PDF exports — is a one-directional, never-back view generated from it. The vault always wins; downstream targets are disposable and regenerable. Bidirectional sync is the most common way a personal system decays; one-way publishing makes drift structurally impossible.

The word doing the work is structurally. Plenty of people intend to keep one source authoritative — and then edit the copy once, because it was open, because it was faster. Intent doesn't survive convenience. What survives is an arrangement where the wrong thing is impossible rather than merely discouraged: if nothing downstream can write back, there is nothing to reconcile.

Sync sounds like the more generous design, and that's the trap. Two-way means two places can both be right, which means eventually they disagree, which means a merge — and merges of knowledge have no clean resolution. Which version of a note is correct? The system can't know, and by the time you notice, neither can you.

The freeing consequence is that downstream becomes disposable. A published surface holds nothing you'd mourn: delete it, regenerate it, and it's identical. That's what lets you publish generously — to a phone, a share link, a Notion page, a client — without adding a single thing you now have to keep in sync.

What makes it enforceable: the marker

Intent doesn't survive convenience — so the arrangement has to make the wrong thing impossible. In practice that comes down to one thing: every published item carries proof of who owns it.

Beacon's calendar publisher stamps each event it creates with beacon_owned=true, plus a stable source id and a content hash. That single marker does three jobs at once:

• identity — match the item on the next run, so republishing updates instead of duplicating
• ownership — this one is ours; the hash says whether it still matches the source
• selection — the exact set that may be removed

The strong form is what the reader should take away: the publisher's read call filters on the marker. An event someone added by hand isn't skipped by a careful check — it is invisible to the script. There is no code path that could touch it. That's the difference between a rule you follow and an arrangement where the wrong thing cannot happen.

It also answers the question one-way publishing always raises: if the vault always wins, how do I undo a bad publish? Because the marker bounds the set exactly, the whole publication can be withdrawn without touching anything else. Disposable downstream stops being a claim and becomes an operation you can run.

⚠️ The marker is per-API, not universal. Google Calendar has invisible extendedProperties; Google Tasks has none, so there the same job is done by a [vaultid:<path>] string hidden in the notes. Each API its best method — the discipline is constant, the mechanism is not.