The problem the binder pattern created
The previous lesson ended with a win: about a dozen sibling apps, each with a Pippa surface, and zero new chat stacks — and the count kept climbing. The binder made adding a host nearly free.
Nearly free at the wiring layer. What it did not make free was the question that only appears once you have thirty of them: which brain is each of those surfaces actually using right now?
The operational need is easy to state and miserable to satisfy by hand. See which brain each function uses. Redistribute when one provider is constrained. Restore a known-good allocation afterwards. Do it without opening roughly thirty apps one at a time.
So on 2026-08-13, after a Family Council, cwkPippa grew a control plane.
The ownership rule, which is the whole design
One paragraph carries it: cwkPippa owns the canonical brain definitions and the central assignment state. A family hub is the family-wide control surface, not a second store. Each app may read and edit only its own slots. No app may modify another app's settings, and that boundary is enforced by the write API — not by hiding a control in a UI.
The subtle line is the next one. When you change a brain inside an app's own settings, you are not creating a local override. You are editing that app's central value from a convenient place. There is one value, and several windows onto it.
This also superseded an earlier ruling. Device-local ownership had been the rule for settings, and it still is for most of them — connection, host, session, soul, voice, macros, explanation mode all stay local. Brain and reasoning effort left that list. They decide which provider's capacity a feature spends — and when one provider is constrained, capacity is a household-level fact, not a per-device preference.
The slot is the unit
Assignment is per slot, not per app — and the slot is defined by something already visible: wherever an app's own settings show a brain picker, that is a slot. A writing engine has a writing slot and a reviewer slot per language. An editor has one editor slot. A travel engine has one actions slot.
Defining the unit by an existing control rather than by a new abstraction is what let a dozen apps enrol in waves without each one needing a bespoke model of itself.
The picker rule turned out to be a floor, not a ceiling, and it was corrected in both directions the same day. A brain doing standing work with no picker at all — a scheduled daily brief steered by an environment variable — is a slot anyway; Dad's line was that there should be no hidden working brains. And a picker that only seeds the default brain for a new Sidekick thread is not a slot, because the Sidekick is cwkPippa's own surface and its brain is picked inside the panel, per conversation. The line runs between the brain that does the app's work and a starting value that gets overridden anyway.
Always-visible state
One rule applies to every app that owns a slot: it must show its current brain state persistently in its main interface. cwkPippa's own status bar is the reference — the brain and its model, always on screen.
The reason is narrow and practical. If opening Settings is the only way to learn which brain an app will use next, then every observation costs a navigation, and a person managing thirty apps simply stops observing. Ambient state is not decoration; it is what makes a fleet legible without being audited.
Snapshots, and a recommendation that only proposes
Bulk changes take a snapshot first, so a redistribution made under pressure is recoverable and auditable afterwards. That is the same instinct as the outbox's sealed store and the share inbox's kept-but-unreadable manifests: the state that lets you undo is worth more than the tidiness of deleting it.
And the recommendation service — the part that looks at the matrix and suggests a better allocation — produces inspectable proposals. It does not move anything. A proposal that has not been accepted is not an assignment, and a stale one is refused as stale rather than applied late.
What was deliberately not built
This is the part worth carrying away. Automatic fallback routing and real-time limit-aware optimisation are named in the plan as deferred research tracks — explicitly not assumed solved, explicitly not to be smuggled into the first delivery.
Both are the obvious next features. Both touch live jobs that must not switch brains mid-run, duplicate side effects on retry, and telemetry that is incomplete. Writing them down as unsolved is what stops a later reader from assuming the matrix already handles them.
One boundary closes the loop with the phone. The native client never reads this plane at all — it takes its brain per conversation from cwkPippa's own settings. The plane assigns slots to other apps, and the phone is not another app. It is cwkPippa.