What this service holds, what it deletes, and what it can prove about either.
Because the work is copyrighted, we keep a record of what happened around each title: which account accepted our terms and when, the declaration that the rights were held, the documents linked as proof and what our checker made of them, who approved, what was paid, what ran on which files (by their digests), where it was delivered, and who deleted what.
That record holds the minimum of personal data it needs: an email address, an organisation name, and the network address a declaration was made from. It is kept for seven years after the last activity on the account, on the basis of our legitimate interest in defending a rights claim and our legal obligations, and it is not used for anything else. It is not deleted when a project or an account is, because that is exactly when it is needed.
Source stems, the print master, the picture proxy, per-line renders, acoustic features and speaker embeddings are all purged, and the purge produces an attestation listing object counts and timestamps.
The service does not claim to keep nothing. It retains the items in the table below, and the most significant of them is the dialogue text: for an unreleased feature that is most of the screenplay. Saying otherwise would be a misrepresentation of a system whose behaviour can be checked.
| Data | Retention | Purged on request? |
|---|---|---|
| Customer source media (stems, print master, proxy) | Purged on job completion | Purged by default |
| Per-line renders | Purged with the source; retake history survives as metadata | Purged by default |
| Mixed deliverables | Pushed to the customer, then purged | Purged by default |
| Acoustic features and speaker embeddings | Purged with the source | Purged by default |
| Archival package, where ordered | Archival hold, exceeding the platform's window | No, its purpose is to outlive the job |
| Dialogue text, source and adapted | Retained | Yes, customer-elected |
| Job metadata, approvals, review trail | Retained | No, it is the record that the customer signed off |
| Voice casts (brief, engine version, weights hash, seed) | Retained | No, a sequel has to sound the same |
| Access log | Retained | No |
| Evidence record | Retained; survives media purge by design | No |
| Purge ledger and signed attestation | Retained | No, it is the proof the promise was kept |
Voice is treated as biometric personal data. Diarization labels speakers with anonymous cluster identifiers only, SPK_01, never a performer's name, and the documented position is that this is speaker *separation*, not identification.
There is no cross-title or cross-job voiceprint store. Speaker embeddings are deleted with the working cache. The data subjects are third-party performers who cannot give explicit consent, which is why the processing is kept to separation and why a data protection impact assessment is part of onboarding.
The purge attestation is not cryptographically signed. It carries a digest over its own content, and it reports that it is unsigned, because a document that calls itself signed when it is not would be worse than an unsigned one. Signing requires a key service.
This instance has no authentication and no audit log of page views. It is a development surface.
Rub‑a‑Dub Duck