Two Truths for Place, Too

"An override never erases the captured sample; map precedence is intended, then captured."

The Same Two-Truth Shape, Now for Place

You met the two-truth rule for time: when a crumb was written versus which day it belongs to. Location has exactly the same shape. Captured location is where you physically were when you wrote the crumb — an automatic foreground sample, when you've granted permission, carrying coordinates, accuracy, sample time, and its source. Intended location is where the memory is about — optional, and often different. You might write a crumb at your kitchen table (captured) about a beach you visited last month (intended). Both are true, and collapsing them into one 'location' field would destroy one of them exactly the way collapsing the two dates would.

The precedence rule keeps them straight: an intended location, when set, wins for display on the map; captured location fills in when there's no intended one. And critically, setting an intended location never erases the captured sample — the record of where you actually were survives, exactly like captured_at surviving a backdate. Same discipline, different axis: keep the two truths separate, let one take display precedence, and never let an override overwrite the honest automatic sample.

A pattern that held once is worth trying on every new axis. The two-truth rule proved itself on dates; place has the same 'where it happened versus what it's about' split, so the same solution transfers wholesale. When you've earned an invariant on one axis, look for its shape on the others — reusing a proven pattern beats inventing a new one, and it keeps the whole model coherent.

Foreground-Only, Secure-Origin, Never on the Save Path

Location capture inherits three hard constraints from Waystone, and each is deliberate. It is foreground-only: Vesta samples location while you're actively using it, never in the background. There is no background tracking, ever — a journal has no business following you around, and the privacy cost of ambient location history is not one this product is willing to impose. It is secure-origin gated: browser geolocation only works over HTTPS, which is exactly why the engine is reachable over a secure origin for mobile use. And it is never on the save path: a slow or denied location fix can never block or delay saving a crumb — location is enrichment, and the thought is safe with or without it.

The Map Stores Nothing

One more boundary closes the loop, and it's the bridge to the next track. The Map is a projection of location truth, not a store of its own — it reads the crumbs' captured and intended locations and draws them, and it holds nothing that isn't already in the crumb store. So location follows the same one-canonical-state rule as every other view: the crumb owns the two location truths, and the Map is just a lens that renders them. Capture the place honestly, keep both truths, and let every geographic view be a projection over the same canonical facts.

Code

Two location truths, with display precedence·typescript

interface Crumb {
  // where you physically were — auto foreground sample, immutable record
  captured_location?: {
    lat: number; lon: number; accuracy_m: number;
    sampled_at: string; source: "gps" | "network";
  };
  // where the memory is ABOUT — optional, author-set
  intended_location?: { lat: number; lon: number };
}

// map precedence: intended first, then captured
function mapPoint(c: Crumb) {
  return c.intended_location ?? c.captured_location ?? null;
}
// setting intended_location NEVER erases captured_location
// no background sampling — foreground only; HTTPS-gated; never on the save path

Exercise

Take a field in a system you know that mixes 'where/when it was recorded' with 'where/when it's about' — a photo's GPS versus its subject, a log's server time versus event time. Split it into two truths with a precedence rule for display, and make sure setting the author-intended one never overwrites the automatic captured one. Then decide the privacy stance: is the automatic sample foreground-only, or is something quietly tracking in the background?

Hint

This is the date two-truth rule wearing a different hat. The captured value is the honest automatic record; the intended value is the author's meaning. Keep both, let intended win for display, and never let it erase captured. And if the automatic sample runs in the background, ask whether the feature actually needs that or is just collecting a location history nobody asked for.

Two Truths for Place, Too

The Same Two-Truth Shape, Now for Place

Foreground-Only, Secure-Origin, Never on the Save Path

The Map Stores Nothing

Code

External links

Exercise

Progress

Comments 0