The Engine Owns the Mechanism, the Brain Keeps the Identity

"Bellows may read a conversation through a documented API, but it never copies the brain."

Two Coherent Domains, One Hard Line

Every long-lived system eventually has to answer: who owns what? Bellows and cwkPippa answer it once, cleanly, and never relitigate. cwkPippa owns identity — the Souls, the conversations, the brain sessions, and the mapping from a Soul to a logical voice profile. Bellows owns the mechanism — provider credentials and catalogs, account-specific bindings, normalization, synthesis, paid-request receipts, cache, playback, and Studio lineage.

The test for which side a thing belongs to is simple: does it decide what to say, or how to make it audible? "Pippa is warm today" is identity — cwkPippa. "This exact text at these settings resolves to that cached MP3" is mechanism — Bellows.

What Bellows Deliberately Does Not Grow

The boundary is enforced by absence. Bellows has no Soul registry, no conversation store, no memory, no model-judgment layer. It is a stated non-goal to grow any of them. If Bellows needs to know which conversation a Studio import came from, it asks cwkPippa through a documented, read-only API — it does not stand up a parallel copy. This is the same posture every cwk sibling takes: Cinder (workspace), Ember (image engine), and Bonfire (music engine) are client surfaces of one brain, not parallel Pippas.

Why the Absence Is the Feature

A voice ID is not an identity. If Bellows started storing "who Pippa is," two sources of truth would drift, and the day they disagreed you'd have a Pippa who sounds like herself but isn't. Keeping identity in exactly one place means the voice can change providers, accounts, and models without ever touching who is speaking.

Code

The ownership boundary, read straight off the schema·bash

# Every persistent domain Bellows owns — and a deliberately short list.
$ rg 'CREATE TABLE' backend/bellows/db.py
provider_accounts   # credential references + compatibility status
voice_profiles      # stable CWK aliases + synthesis defaults
voice_bindings      # account-specific provider voice IDs
synth_jobs          # request identity, receipts, outcome, cache ref
cache_entries       # atomic audio artifacts + access policy
studio_projects     # content-addressed production lineage

# Notice what is NOT here: no souls, no conversations, no memory, no
# model adapter. Those live in cwkPippa. Bellows reads them through an
# API when it must, and never owns them.

Exercise

Take a system you know that has a 'core' service and several client apps. Write one sentence that is clearly identity (what to do / who this is) and one that is clearly mechanism (how to render it). Then find one place where a client app has quietly started storing a copy of the core's identity. That copy is the drift waiting to happen.

Hint

Ask of each stored field: if the core changed this tomorrow, would the client silently keep serving the stale version? If yes, the client has grown a second brain.