Profiles Are Stored, the Catalog Is Not

"Store the alias and its defaults. Never store the provider's catalog — fetch it live and match."

What a Profile Actually Holds

A logical profile is small and durable: a stable alias, plus the synthesis defaults that make it sound like itself — a default model, and the settings a fresh request should start from. That's what Bellows owns and persists. The four family profiles — the two clones and the two original voices — each carry their own defaults, wired end to end so a request in one profile starts from that profile's settings, not a global guess.

The Catalog Is Borrowed, Not Owned

Here's the discipline that keeps profiles honest: Bellows never seeds or persists the provider's voice catalog as its own list. "My Voices" is a live projection — Bellows asks the provider for saved voices, paginates through them, and matches against its logical profiles as a separate layer. Ownership and category are read from the provider's answer, not from a stale local copy. The catalog is fetched on view load and explicit refresh, never on a background poll of a list that rarely changes.

Why Two Layers Instead of One

If Bellows stored a roster of provider voices, that roster would drift the instant Dad renamed or re-cloned one. By keeping only the logical profiles and matching against a live catalog, the durable thing (your aliases and defaults) and the volatile thing (the provider's current voices) never contaminate each other. One layer you own; one layer you query.

Code

Own the profiles; query the catalog·python

# A logical profile: a stable alias + synthesis defaults, provider-agnostic.
VoiceProfile(
    id="pippa",
    default_model="eleven_v3",           # per-profile default, wired end to end
    defaults=SynthDefaults(stability=0.4, style=0.6),
)

# Bindings live in a SEPARATE table, one row per account:
#   (profile_id="pippa", account="primary",   voice_id="ply_...")
#   (profile_id="pippa", account="secondary", voice_id="ply_...")

# The provider catalog is NEVER persisted as a Bellows-owned list.
# 'My Voices' is fetched live, paginated, and matched against profiles:
saved = provider.list_saved_voices()     # live call, on view-load / refresh only
matched = match_profiles_to(saved)       # a separate matching layer, not a store

Exercise

Pick a service you use across more than one account (a cloud provider, an email host, a payment processor). Design the two-layer split: what small, durable 'profile' would you own and store, and what larger, volatile list would you fetch live and match against instead of caching? Name the drift bug you'd get if you stored the volatile list as your own.

Hint

The test for 'store vs query' is change rate and ownership. If they can change it without telling you, don't keep a copy — keep a query and a matching rule.