Continuity Is Canonical, Presentation Is Bounded

"The phone shows a window. The backend keeps the whole room. Never mistake the window for the room."

Two Different Things Called 'The Conversation'

On a phone, screen space and memory are tight, so Pippa Go shows a bounded view: the recent question-and-answer exchanges, not necessarily the entire history. That's the right call for presentation — nobody wants to scroll a thousand turns on a phone. But it creates a dangerous temptation: to treat what the phone is showing as the conversation itself, and to build context for the next turn from that bounded window. That temptation must be refused. Continuity — the real, full context Pippa reasons from — is owned by the backend. Presentation — what the phone renders — is bounded and lossy by design. They are not the same object, and the smaller one must never define the larger.

Never Rebuild Context From the Window

The specific rule: when a new turn is sent, its context must be reconstructed by the backend from the canonical log — full replay, auto-compaction, all of it — never assembled on the phone from the last N visible messages. If the phone built the context, the conversation would silently lose everything scrolled off screen, and Pippa would answer as if the earlier history never happened. The bounded window is a viewport, not a source. Rendering less is fine; remembering less is a bug.

Presentation (phone): shows recent turns, may drop old ones for space. Lossy on purpose.
Continuity (backend): replays the full conversation for every turn. Lossless by design.
The rule: the next turn's context comes from continuity, never from presentation.

Why the Split Is Safe (and Necessary)

Separating these two lets each be optimal at its own job. Presentation can be aggressively minimal — fast, light, phone-friendly — precisely because it carries no responsibility for memory. Continuity can be exhaustive — full replay, compaction, the works — precisely because it never has to fit on a screen. Fuse them and both degrade: either the phone must hold and render everything (heavy, slow), or the conversation's memory shrinks to whatever fits the viewport (broken). Keeping them separate is what lets Pippa Go feel light on the phone while remembering everything in the backend. The window can be small precisely because the room is complete.

Code

Context for the next turn comes from the backend, not the visible list·typescript

// WRONG: build context from what the phone happens to show.
async function askWrong(convId: string, q: string, visibleTurns: Turn[]) {
  const context = visibleTurns.slice(-10);   // last 10 on screen — LOSSY
  return callModel({ convId, q, context });   // forgets everything scrolled away
}

// RIGHT: the backend reconstructs full continuity from the canonical log.
async function ask(convId: string, q: string) {
  return callCanonical({ convId, q });        // backend replays full history
}

// The phone passes an identifier, not a transcript. Memory is the backend's job;
// the visible list is a viewport, never the source of context.

Exercise

Find a chat client and test whether its memory is bounded by its view: scroll far back, start a new turn that depends on something only visible near the top, and see if the model still 'remembers' it. If continuity is tied to the visible window, the model will forget. Then describe how you'd fix it: pass an identifier and let the backend replay full context, instead of shipping the visible transcript as the context.

Hint

The failure signature is a model that 'forgets' anything scrolled off screen — proof its context was built from the presentation window. The fix is always to make continuity a backend responsibility keyed by conversation id, with the phone passing a reference, not a transcript.