Two Truths: Captured vs Intended

"Where you were and where the memory is about are two different facts. Record both; never let one pretend to be the other."

The Location Split

When you leave a breadcrumb, there are actually two location questions, and Waystone keeps them separate. captured_location is where the phone actually was when you submitted — the real GPS sample. intended_location is an optional override for where the memory is about, which you might set later when recording a thought from somewhere else: at the hotel that night, writing about the summit you saw that morning. The rule is strict: an override never rewrites or discards the captured sample, and you cannot even save an intended location without an actual captured one underneath it. The map prefers intended, then captured, then a text place hint — but all three truths remain, and the real GPS sample is never overwritten by the annotation.

The Date Split

The same two-truths shape appears for dates. A crumb has a schedule date (local_date) — the day it belongs to in the itinerary — and a capture date (captured_local_date, captured_at) — when the device actually submitted it. These come apart the moment you file a memory retrospectively: sitting on day 15, you record something that belongs to day 14. Waystone lets you file it under day 14's schedule without pretending it was submitted then. The schedule date says where it lives; the capture date says when it was really written. Correcting the schedule owner later is an append-only revision that leaves the capture truth untouched.

Why Two Truths Beat One

The lazy design stores one location and one date and calls it done — and it is subtly wrong in both directions. Store only the captured values and you cannot record a memory about a place you have already left. Store only the intended values and you have quietly falsified where and when you actually were. Keeping both is what lets retrospective filing coexist with honest evidence: Dad can say "this is about the Eiger, filed under yesterday," and the record still knows he wrote it from the hotel tonight. Two truths is not redundancy; it is the only way to be both useful and honest.

Code

Two truths, for location and for date·text

LOCATION
  captured_location  = actual GPS where you submitted   (never rewritten)
  intended_location  = optional 'this memory is about there' override
  map precedence: intended -> captured -> geocode(place_hint)

DATE
  local_date            = schedule day it belongs to (the itinerary slot)
  captured_local_date   = the day the device actually submitted it
  captured_at           = the exact submission timestamp

# File a D14 memory on D15:
#   local_date = D14   (where it lives)
#   captured   = D15   (when it was really written)
# Neither truth erases the other.

Exercise

Think about a note or photo you filed under a date or place that wasn't literally where/when you made it — a memory logged after the fact. Does your tool record both truths (the real capture moment AND the intended subject), or did it force you to pick one? If you had to choose, which truth did you quietly falsify to make the record look right?

Hint

Most tools store one location and one timestamp, so filing retrospectively silently lies about one of them. The two-truths design is what lets 'this is about yesterday's summit' and 'I actually wrote this tonight' both be true at once — useful and honest, not one at the cost of the other.