The System-Folder Projection

"Projection isn't a copy and it isn't a cage. It's a label that says where a conversation was born, without changing what it is."

Where Phone-Born Conversations Show Up

A Pippa Go conversation is canonical from birth — but the backend still wants to know it came from the phone, so it can be organized, filtered, and reasoned about. Pippa Go does this with two lightweight touches: each conversation is tagged with an origin surface ("this was created from Pippa Go"), and it's projected into a server-owned system folder that gathers all phone-born conversations in one place. Neither touch changes the conversation's nature. It's still an ordinary canonical conversation; it just carries a stamp of where it started and appears in a tidy home.

Projection vs. Fork vs. Copy

The word "projection" is doing precise work, so contrast it with the alternatives it is not:

Not a copy. There's one conversation, in the canonical store. The system folder doesn't hold a duplicate; it holds a view that includes the conversation by reference.
Not a fork. The phone didn't spawn a separate lineage. The conversation is the same object the rest of the system sees, with the same history and the same future.
A projection. An organized, labeled surfacing of the one canonical conversation — the way a folder groups files it doesn't own exclusively. Move it, and you're moving a reference, not relocating the truth.

Why the Stamp and Folder Earn Their Keep

The origin-surface tag and system folder aren't bureaucracy; they buy real clarity. They let the backend answer "which conversations came from the phone?" without guessing, keep phone-born conversations from cluttering other views, and give a clean seam for phone-specific behavior (like the auto-title-after-first-turn rule these surfaces use). And crucially, they do all this without making phone conversations second-class or special-cased in the core: they're normal conversations wearing a name tag, filed in a labeled drawer. Organization, not exception. That restraint is what keeps the projection honest — the phone influences where a conversation is filed, never what it fundamentally is.

Code

An ordinary canonical conversation, stamped and projected·json

{
  "conversation_id": "conv_7d21…",
  "origin_surface": "pippa-go",     // the stamp: where it was born
  "system_folder": "PIPPA-GO",       // the projection: where it's filed
  "canonical": true,                  // same first-class status as any other
  "turns": [ /* normal turns, normal replay, normal branching */ ]
}

// Remove origin_surface and system_folder and nothing about the
// conversation's truth changes — they organize it, they don't define it.

Exercise

Design the metadata that marks a phone-born conversation without changing its nature: what tag identifies its origin, what folder gathers such conversations, and what surface-specific behavior (if any) hangs off the tag. Then verify your design passes the 'remove the metadata' test: if you strip the tag and folder, is the conversation still a complete, valid canonical conversation? If not, you've smuggled truth into organization.

Hint

The metadata should be purely additive. A correct design lets you delete origin_surface and system_folder and still have a fully valid conversation — proving the phone influenced only organization, never the conversation's essential content or status.