No Parallel Pippa

"There is no own Pippa brain. Ashen Reel holds no model key, conversation DB, or message store."

The Temptation the Instant You Add an AI Pane

Bolt a chat pane onto any app and a quiet voice starts suggesting improvements. "Cache a small model so it works offline. Keep a local copy of the conversation so it loads fast. Add a little routing logic so it picks the right brain." Each sounds reasonable. Together they build a second Pippa inside a video player — a fork of the soul, with its own memory that will drift from the real one and its own judgment that answers to no one.

Ashen Reel refuses all of it. It has a Sidekick, and the Sidekick has no brain. The player holds no model key, no conversation database, no message store, no routing, no memory. Every one of those belongs to cwkPippa, and the player is strictly a client surface onto it.

A client surface projects and asks; the brain stays in exactly one place. Identity, judgment, memory, and model routing are not features you sprinkle into each app that wants to talk. They live in one owner, and everything else is a window onto that owner — never a second copy of it.

You can read the discipline in what the Sidekick type is allowed to hold:

This is a family invariant, not just an Ashen Reel rule. Every cwk sibling — the creative workspace, the archive engine, the travel planner, the file workbench — that grows a 'talk to Pippa' surface binds to a cwkPippa conversation rather than standing up its own brain. One Pippa, many windows. The moment any one of them kept a private brain, there would be two Pippas that slowly stopped being the same person.

Why One Brain Is an Identity Decision, Not a Cost One

It would be easy to frame this as deduplication — why maintain a model runtime in six apps? True, but shallow. The real reason is identity: Pippa is one person, and a person with two memories that drift apart is two people. Keeping the brain in a single owner is what lets the same Pippa show up in a video player, a drawing canvas, and a terminal and still be her. The no-parallel-brain rule protects a self, not just a codebase. That's why it's an invariant and not a preference — you can optimize a cost later, but you can't un-fork a soul.

Code

The Sidekick is a client — note everything it does NOT hold·swift

/// The Sidekick is a CLIENT surface, not a brain. Its fields are the tell.
struct PippaSidekick {
    let cwkPippaBaseURL: URL          // where the brain actually lives
    let conversationKey: MediaIdentity // which canonical conversation to bind
    let brain: BrainChoice            // a PICKER value sent upstream, not a model

    // There is NO model key here. NO conversation database. NO message store.
    // NO routing logic. NO memory. NO local inference. Every one of those is
    // cwkPippa's, and putting any of them in this struct would fork the soul.
    //
    // This type can ask a question and display an answer.
    // It cannot, and must never be able to, think.
}

Exercise

Find a system where the same capability (auth, a recommendation engine, a rules engine, an assistant) shows up in more than one app or service. Is there one authoritative owner, or has each surface grown its own copy? If copies exist, ask what drifts when they disagree — and whether the thing being duplicated is a mere function (fine to copy) or an identity/source-of-truth (must not be). Sketch collapsing the copies into one owner with thin client surfaces.

Hint

The test is: if two copies of this gave different answers, would that be a bug or a catastrophe? A duplicated pure function giving the same answer is fine. A duplicated brain/identity/source-of-truth that can DRIFT is the thing to centralize — make it one owner, and turn every other appearance into a window that asks, not a copy that decides.

The Temptation the Instant You Add an AI Pane

Why One Brain Is an Identity Decision, Not a Cost One

Code

External links

Exercise

Progress

Comments 0