"The well requests a voice; it does not become a voice engine."
Separate need from ownership
Read-along audio is valuable, but speech generation is already a family capability with its own voices, limits, failures, and deployment life. Inkwell is a client, not a second voice foundry.
Shape the crossing
The TTS endpoint sends the requested text and language through the owned voice client, keeps one call in flight, and streams the returned audio bytes. Current Inkwell stores no audio job or artifact row.
The duplication temptation
Bundling a TTS SDK, voice catalog, or provider key into Inkwell duplicates ownership. Generating audio without an explicit read action wastes speech. Read the text selected by the caller and return bytes on demand.
Let requests and references cross
Audit “Bellows Owns the Voice” beyond code imports. Trace which request reaches which owner, that the result is streamed audio bytes, and who explains failure and retry. Credentials, canonical history, or a voice catalog copied into Inkwell are a second system, not a convenient integration.
Write the boundary table
Draw the on-demand request from selected text and language to streamed audio bytes. Include timeout, stale output, sibling unavailability, and schema mismatch. Any blank where both sides assume the other will act is the owner of the next incident.
Owning less makes the product more itself
Inkwell's identity is not another brain or voice engine. It composes original-first flow, penless review, handwriting UX, and late-result landing into one experience. Boundaries are features that make that composition possible.