notes from ElevenLabs TTS experiment

[nedtwigg]

Alert text is user data. Design for minimizing what ElevenLabs ever holds; deletion is cleanup, not prevention.

enable_logging=false does not work. Measured: a ZRM request returned HTTP
200 and a history-item-id header — it wrote a history entry exactly like the
logging-on request, with no eligibility error. ZRM is gated to eligible
Enterprise accounts; on a normal key the parameter is accepted and silently does
not apply. Never treat a 200 as proof of non-retention.

Deleting the history item does work, but not immediately. Measured at +3 ms
after the audio response completed:

• DELETE /v1/history/{id} → 404 history_item_not_found
• GET /v1/history/{id}/audio → 200, audio present

The audio is live and fetchable on their servers before the history record is
addressable for deletion. A 404 on DELETE means "not there yet", not "nothing
stored" — never infer deletion from it.

Therefore: a delayed delete queue, not an inline delete.

• Persist the history-item-id (response header) durably at render time,
  before returning audio to the user. It is the only handle; a crash between
  render and delete orphans data nothing can later remove.
• Delete after a delay, with backoff retries on the not-found case.
• Alert on terminal failures. A failed delete is silent and leaves live audio.
• The delay is unmeasured — a 0/250/750/2000/5000 ms ladder was written but never
  confirmed against the live API. Measure it and set the first attempt past the
  window; don't assume.

Verification must handle inconsistent error shapes. DELETE-missing is 404,
but GET /v1/history/{id} on a missing item is 400 with
detail.status: invalid_id (not 404). Check both the history item and its
/audio endpoint — in one run the audio outlived the record.

Keys need their own scopes for cleanup: speech_history_write to delete,
speech_history_read to verify. A TTS-only key gets 401 missing_permissions
and the cleanup silently no-ops. Provision this before launch.

Even a verified delete is weaker than ZRM. ElevenLabs states debugging and
moderation logs may retain related data, and backups may persist up to 30 days.
User-facing copy must say "deleted from history" — never "never stored."

[dormouse-bot]

Filed as spec rather than left in the thread: #604 puts these findings under docs/specs/alert.md's fold as Scope: managed-voice, with the measurements keyed into docs/specs/alert.rationale.md. Every constraint here is one a future implementer would otherwise have to rediscover by hitting the same trap — the 200-with-a-history-entry and the 404-that-means-not-yet both read as success.

Two things I did not carry over as stated. The delay ladder stays in the rationale marked as unconfirmed, so the spec asks for a measurement instead of naming a number nobody has verified. And the copy rule got a Reserved: line above the fold, beside the settings speech row's /hosted link, because it is the one part that binds today — the /hosted and settings copy for the unbuilt feature already exists. It currently says the app "will explain what text leaves your computer," which does not conflict, but nothing was stopping the next edit from reaching for "never stored."

The judgment calls worth overruling if you disagree: alert.md as the owner rather than a new spec (a security*.md spec cannot hold it — those carry no ## Future or Reserved:), and the staged ordering. The PR is a draft; spec lint is green and it re-baselines alert.md's word budget to 6950.