Only a Canonical Call Materializes an Answer

"The phone can carry a question anywhere. It cannot author the answer. Those are two different authorities, and the client only holds one."

Who Is Allowed to Speak as Pippa

An answer isn't just text on a screen — it's Pippa saying something. And there is exactly one place with the authority to make Pippa say something: a successful canonical call to the backend, where her real identity, memory, judgment, and model routing live. The phone has no such authority. It can capture a question, display an answer that came back, and store it — but it can never author one. "Materialize" is the precise word: a real answer only comes into existence when the canonical call succeeds, and never a moment before.

Two Tempting Impostors

Two shortcuts constantly offer to speak for Pippa, and both must be refused:

A local model on the phone. Even a genuinely good on-device model is not Pippa — it lacks her memory, her routing, her context. An answer from it would be a different entity wearing her name. Convenient, and a lie about who spoke.
Cache-as-answer. Showing a previous answer to a similar question as if it were the reply to this one. It looks instant and helpful; it silently answers a question the user didn't ask.

Both are appealing precisely because they remove the wait. But the wait is honest and the shortcut is not. A client you can trust holds the line: no canonical success, no answer — full stop.

The Materialization Gate

Make the rule structural, not a matter of discipline. There should be exactly one code path that can write an answer onto a turn, and it should be reachable only from a verified successful canonical response. If it's physically impossible for any other path — cache, local model, optimistic placeholder — to set answer, then the honesty guarantee holds even when a future contributor forgets the rule. The gate isn't a comment saying "don't fake answers"; it's an architecture where faking one has nowhere to write.

Code

One gate: only a verified canonical response may write an answer·typescript

// The ONLY function allowed to set turn.answer.
async function materializeFromCanonical(turn: PippaGoTurn) {
  const res = await callCanonical(turn);      // the backend, the real Pippa
  if (!res.ok) throw new DeliveryError();      // no success -> nothing written
  await db.update(turn.deviceTurnId, {
    answer: res.answer,                        // materialized here, and ONLY here
    answerCameFromCanonicalCall: true,
    syncStatus: "answered",
  });
}

// There is no showCachedAnswer() and no runLocalModel() that writes 'answer'.
// Cache and local guesses can render HINTS, but they can never become THE answer.

Exercise

Find every place in a hypothetical client where an 'answer' could be written: the network success handler, a cache lookup, a local fallback, an optimistic UI update. For each non-canonical source, decide whether it should be forbidden from writing the answer field. Then design the single gate that lets only verified canonical success through. How many write sites did you have to close?

Hint

If more than one code path can set the answer field, honesty depends on all of them behaving. Collapse them to a single materialization function reachable only from a verified canonical response — then there's just one place to get right.