C.W.K.
Stream
Lesson 02 of 04 · published

Conversation Materializes State

~12 min · proposal, provenance, mutation, accept

Level 0Unmarked Path
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Talk is not cheap here. Talk is how the itinerary gets built — but only after you say yes."

A Turn Can Propose a Mutation

If conversation is planning, then a conversational turn has to be able to change the plan — otherwise it is just chatting. In Waystone, a single turn may produce one or more proposed domain mutations: add, remove, or reorder a day; add a candidate place or promote it to planned; compare routes or hotels; record a recommendation and its rationale; record Dad's decision; create a travel event; open a linked writing document. The conversation is not decoration on top of a form — it is the primary way structured state gets written.

Proposal, Then Accept — Never Silent

But here is the discipline that keeps it trustworthy: Pippa presents material changes as a visible proposal or diff, and Dad can accept, reject, or refine them in the same conversation. Nothing material is written the instant it is mentioned. Only acceptance turns a proposal into canonical Waystone state. This is a deliberate refusal of the "the AI just did it" pattern, where an assistant silently mutates your data and you discover the change later. In Waystone, the boundary between "Pippa suggested" and "this is now true" is an explicit, human act.

Accepted State Carries Provenance

When a proposal is accepted, the resulting state does not arrive as an orphan. It keeps provenance back to the conversation and the decision that produced it. Months later, you can look at a day that was added or a place that was promoted and trace why — which turn, which reasoning, which decision. That provenance is what turns a pile of itinerary edits into a defensible history. An edit you cannot explain is an edit you cannot trust; an edit with lineage is one you can audit, revisit, and learn from.

The first fully button-shaped version of this proposal-then-accept loop is Carve, in Track 6: a rough plan or a photo becomes a proposed scaffold that loads into the editor in a gated review state, and only Accept persists it — snapshotting the previous version first. Same loop, made concrete.

Code

The proposal -> accept -> provenance loop·text
Dad (in conversation):  "Drop Zurich, add two days in Grindelwald."
        |
        v
Pippa proposes a DIFF:  - remove day: Zurich (D2)
                        + add day: Grindelwald (D2)
                        + add day: Grindelwald (D3)
        |
        v
Dad: accept / reject / refine  <-- the human boundary
        |
   (accept)
        v
Canonical state mutates, and the new days carry provenance:
   from_conversation: <id>   from_decision: "drop Zurich for weather"

# 'Pippa suggested' and 'this is now true' are different events.
# The gap between them is where trust lives.

External links

Exercise

Think about an AI tool that edits your data — a smart calendar, an email autoresponder, an assistant that reorganizes files. Does it show you a proposal before acting, or does it act and hope you notice? Now imagine needing to explain, a year later, why one of its changes happened. Could you? Design the smallest 'accept' step that would make that change auditable.
Hint
The cheapest auditability is a visible diff plus a stored reason. If an AI change can't answer 'which request caused this and why?', it's a convenience today and a mystery tomorrow. The accept step is where the reason gets attached.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.