"Normalize, resolve, cache-or-pay, play. Everything else is detail on those four."
One Request, Four Steps
When a consumer asks Bellows to speak, the engine does exactly four things, always in the same order. Normalize the text — turn what's on the screen into what should be spoken. Resolve the logical profile to a provider binding on the currently active account. Cache-or-pay — compute a content-addressed identity over the normalized text and every setting, then either return the cached audio for free or make exactly one paid request. Play — hand the audio to the single persistent worker that owns the output device.
Every track after this one is a deep dive into one of those four. Bindings are Track 3. The cache identity is Track 4. Recovery when the paid step goes wrong is Track 5. Owning the audio device is Track 6. Normalization is Track 7. Hold the four-step shape in your head and the rest of the engine snaps into place.
A Request Is a Little State Machine
Under the hood, each request becomes a synth_jobs row: its exact state, a non-secret request identity, provider receipts, an outcome, and a cache reference. That row is what lets Bellows answer "what happened to this?" long after the moment passed — which is the whole reason the paid step can be made safe.