Canonical From Birth

"A Pippa Go conversation isn't a phone draft waiting to be promoted. It's a real backend conversation from its first breath."

Two Ways to Build a Mobile Client — One Is a Trap

There are two mental models for where a mobile conversation lives, and the choice shapes everything:

Draft-then-upload (the trap): the phone owns a local conversation that is the "real" one until it's exported to the backend. The backend is a sync target, a copy of what the phone decided.
Canonical-from-birth (Pippa Go): the conversation is a first-class backend conversation from the very first turn. The phone never owns "the real one" — it presents and captures for a conversation the backend already owns.

The draft-then-upload model feels natural and is a slow-motion disaster. The moment the phone holds the authoritative copy, you have two sources of truth that can disagree, a promotion step that can fail halfway, and merge logic no one wants to write. Canonical-from-birth deletes all of that by never letting the phone be the authority in the first place.

What 'Canonical From Birth' Buys

Because the conversation is canonical immediately, it inherits every backend guarantee for free — from the first turn, not eventually:

Full context replay. The backend can reconstruct the whole conversation for any future turn, because it always had it.
Branching semantics. The conversation can be branched and explored using the same machinery as any other, because it is any other.
Durable ground truth. The conversation lives in the backend's append-only log from turn one; there's no window where it exists only on a phone that might be lost.

The phone's local outbox from Track 2 doesn't contradict this. The outbox is durable capture — the phone's staging area for input in flight. The conversation itself is canonical in the backend. Two durable stores, two different jobs: the outbox protects the question on its way in; the canonical log owns the conversation once it lands.

The Question the Model Answers

Ask of any mobile client: "if the phone falls in a lake right now, what's the state of the conversation?" Under draft-then-upload, anything not yet promoted is gone — the phone was the truth. Under canonical-from-birth, every turn that reached the backend is intact and every question still in the outbox is a known pending capture; nothing authoritative was ever exclusively on the phone. That answer is the whole point of refusing to let the client be the brain.

Code

Two models, one lake test·text

DRAFT-THEN-UPLOAD                 CANONICAL-FROM-BIRTH
  phone = the real conversation      backend = the real conversation
  backend = a later copy             phone  = capture + presentation

  phone in a lake:                   phone in a lake:
    unpromoted turns = GONE            delivered turns = safe in backend
    two sources can disagree          pending turns   = known captures
    promotion can fail halfway        nothing authoritative was phone-only

// Canonical-from-birth doesn't 'handle' the two-source problem.
// It never creates the second source in the first place.

Exercise

Apply the 'phone in a lake' test to two designs of the same chat feature: one where the phone holds the conversation until upload, one where every turn is canonical in the backend immediately. For each, list exactly what survives and what's lost when the phone disappears mid-use. Then identify the promotion/merge code the second design never has to write.

Hint

The draft-then-upload design must answer 'what if promotion fails halfway?' and 'what if both sides changed?' — questions the canonical-from-birth design never faces, because the phone was never the authority. Deleting a source of truth deletes its entire class of bugs.