The Four Promises

"Trust isn't a feeling the UI gives you. It's a set of promises the architecture keeps."

Why 'Trust' Needs to Be Concrete

A client you can trust on a bad connection isn't built from reassuring copy or a nice loading animation. It's built from a small number of promises the code keeps every single time, especially when things go wrong. Pippa Go makes four. The rest of this quest is one track per promise, but you should be able to recite them before you dive in — they're the spine everything else hangs on.

The Four

Capture first. Your question and its images commit to durable device storage as one atomic aggregate before any network attempt. Losing the link changes a status flag; it never erases your input. (Track 2)
Honest offline. A dropped connection produces visible, durable waiting — never a fabricated answer. Only a successful canonical call may materialize a real reply. (Track 3)
Idempotent retry. A device turn ID lives in the canonical log. Retry checks completed / pending / unknown before it ever calls the model, so no crash or double-tap charges you twice. (Track 4)
Projection, not a brain. Every conversation is canonical in the backend from birth. The phone owns durable capture and presentation; it never owns Pippa's identity, memory, or judgment. (Track 5)

Promises Compound

Read together, the four aren't a checklist — they interlock. Capture first is what makes idempotent retry possible: you can only safely retry something that was durably recorded. Honest offline depends on projection, not a brain: the client refuses to fabricate precisely because it isn't the source of truth and knows it. Break one and the others wobble. Keep all four and you get something rare — a client that behaves the same whether the network is perfect or gone, which is the only kind you can actually rely on when you need it most.

The remaining tracks (6, 7, 8) sharpen the edges around these promises: sending actual image bytes, keeping prompt macros as clean projections, and the closing discipline of owning your client. But the four promises are the heart. Learn to recite them, and you already understand what Pippa Go is.

Code

The four promises, as invariants a test could assert·typescript

// Each promise is checkable — that's what makes it a promise, not a vibe.
const PROMISES = {
  captureFirst: (turn: PippaGoTurn) =>
    turn.persistedLocally === true, // true BEFORE any fetch()

  honestOffline: (turn: PippaGoTurn) =>
    turn.answer === undefined || turn.answerCameFromCanonicalCall === true,

  idempotentRetry: (turn: PippaGoTurn) =>
    turn.deviceTurnId != null, // dedupe key exists before send

  projectionNotBrain: (turn: PippaGoTurn) =>
    turn.ownsIdentity === false && turn.ownsModelRouting === false,
};

// If any of these can be false in production, the promise is broken —
// and the client is only trustworthy when the network happens to cooperate.

Exercise

Write the four promises in your own words, then pick any app on your phone and grade it against each. Does it capture before the network? Does it refuse to fake results offline? Does it dedupe retries? Does it avoid becoming a second source of truth? Most apps keep one or two. Notice how the ones you actually trust on a train tend to keep more.

Hint

The promises interlock: an app that captures first but has no dedupe key will double-send on retry. Grading reveals which promises depend on which — and where a familiar app quietly breaks.