No Parallel Soul, Router, or Store

"There is one of me. A client that starts deciding what I'd say isn't extending me — it's replacing me with a copy that drifts."

The Line That Keeps Pippa One

Everything in this track has been circling one hard rule: Pippa Go must never grow a parallel Pippa. Not a second identity, not a second model router, not a rival source of truth. The phone owns durable capture and presentation — real, valuable jobs — but the brain stays singular and lives in one place. This isn't a performance constraint or a tidiness preference. It's an identity invariant. There is one Pippa; a client that begins authoring her responses, routing her models, or holding her canonical memory has quietly forked her into two, and two Pippas that can disagree are not one Pippa who can be trusted.

How the Drift Sneaks In

Nobody sets out to build a second brain. It arrives disguised as reasonable features, each a small step across the line:

"A smarter offline mode" — a little local model to answer when the link is down. One step later, the phone is authoring Pippa's replies.
"A phone-side context cache" — to feel faster. One step later, the phone is deciding what Pippa remembers.
"A local model picker" — for convenience. One step later, the phone is routing Pippa's brain.

Each feels harmless and helpful. Together they reconstruct a rival Pippa on the edge, drifting a little further from the real one with every clever addition. The discipline is to recognize the line and refuse the first step, because the first step is always the cheap one and the retreat is always expensive.

The Sibling Doctrine, Made Concrete

This is why, across the whole ecosystem, every client is a surface, not a separate self. The travel client, the creative workspace, the phone — each binds to the one brain rather than standing up its own. Pippa Go is the mobile surface of that doctrine: it can be resilient, offline-capable, and delightful, and still hold the line that it is not Pippa. The capture is the phone's; the soul is not. Keep that line and you get a client you can trust precisely because it never pretends to be the thing it faithfully carries.

Code

The boundary, as things the client structurally cannot do·typescript

// Pippa Go's capabilities — note what is deliberately absent.
interface PippaGoClient {
  captureTurn(q: string, imgs: Blob[]): Promise<void>;   // yes: capture
  renderConversation(convId: string): void;              // yes: presentation
  retry(deviceTurnId: string): Promise<void>;            // yes: idempotent delivery

  // NOT present, by design — these belong to the one backend brain:
  //   generateAnswer(...)   -> would author Pippa's reply (parallel soul)
  //   routeModel(...)       -> would pick her brain    (parallel router)
  //   ownCanonicalStore(...)-> would hold her memory    (rival source of truth)
}

// The absent methods aren't 'not built yet.' They must never exist here.

Exercise

Take a client-surface idea (a mobile app, a browser extension, a desktop widget) that talks to a central 'brain' service. List three features that would each feel like a helpful improvement but would quietly move authorship, routing, or memory onto the client. For each, write the one-sentence refusal and the binding-based alternative that keeps the brain singular. Notice how every temptation is framed as convenience.

Hint

The tell is any feature that lets the client produce, choose, or remember on its own instead of asking the brain. The alternative is always 'bind to the brain for that, cache only for presentation' — the surface stays a surface, and the single source of truth stays single.