The Departure Baseline

"The moment you start walking, the plan you left with is frozen forever. Everything after is a revision, not a rewrite."

A Special Moment: Departure

Most of a plan's life is fluid — dates shift, hotels swap, days get reordered while it is still just an idea. But there is one moment that deserves to be marked permanently: the moment the journey actually begins. Waystone calls the act of marking it Start Logging, and one of the things it does is freeze the current plan as the departure baseline. From that instant, the baseline is immutable. It is the crystallized answer to a question you will care about later: what did Dad know and intend at the moment he set out?

Later Changes Are Revisions, Not Edits

After the baseline is frozen, the plan does not stop changing — trips are full of changes. But those changes are recorded as revisions layered on top, never as edits to the baseline itself. This is the difference between a version-controlled history and a document you keep saving over. Ask "how far did the trip drift from the original plan?" and the baseline is still sitting there, unaltered, to measure against. Overwrite it and the question loses its anchor — you would be comparing the current plan against itself.

Why Freezing Enables Everything Downstream

The frozen baseline is quietly load-bearing for the whole rest of the engine. Planned-versus-actual comparison needs a fixed "planned" to compare actual against — that fixed thing is the baseline. The reflection at the end of a trip needs something to reflect against — the baseline and the revisions together. Even the map's planned-geometry layer draws from it. Freeze the baseline and every downstream analysis has stable ground; leave it mutable and every one of them is comparing against a moving target. One immutable snapshot at departure is what makes the trip legible ever after.

Start Logging does more than freeze the plan. It transitions the journey from PLANNING to ACTIVE, confirms the local start date and time zone, mints the human-readable journey UID, binds the active consultation thread, and creates the first day. It is a single domain transaction with many effects — the next lesson walks the whole lifecycle it sits inside.

Code

Start Logging: one transaction, many effects·text

StartLogging(journey):
    journey.state       = ACTIVE          # was PLANNING
    journey.start_date  = confirm_local_date_and_tz()
    journey.uid         = mint_human_uid()   # 2026-07-12-switzerland-04
    journey.baseline    = freeze(current_plan)   # <-- IMMUTABLE from here
    bind(consultation_thread, journey)
    create_first_day(journey, local_start_date)

# After this call:
#   baseline is read-only forever
#   every later plan change is a NEW revision on top
#   'what did we intend at departure?' has a permanent answer

Exercise

Think of a project or trip with a clear kickoff. Did you snapshot the plan at that kickoff, or did the plan just keep evolving with no frozen 'this is what we committed to on day one'? If someone asked 'how far did we drift from the original commitment?', would you have a baseline to measure against — or only the current, drifted version?

Hint

The value of a baseline shows up only when you need to measure drift. If your plans have no frozen departure snapshot, you can always see where you are, but never how far you came from where you meant to be. The freeze is cheap; regretting its absence is not.

A Special Moment: Departure

Later Changes Are Revisions, Not Edits

Why Freezing Enables Everything Downstream

Code

External links

Exercise

Progress

Comments 0