Retention
What we keep, and for how long.
Generated video only grows. Two things on this page expire, both of them copies rather than work, and neither of them without telling you first. Everything else is kept while you are using it.
This page is published before it is enforced, deliberately. Expiring something on a policy you could read is fair. Deleting it later under a rule invented afterwards is not.
The schedule
| Artefact | Kept |
|---|---|
| Uploaded reference images | While referenced by a live project |
| The take a scene is using | While the project is live |
| Takes you moved on from | 30 days From when you select a newer take on that scene. This is the one that costs a real render to reproduce, which is why it gets notice and a keep-this button. |
| Promoted frames and generated stills | While referenced by a seam pin, a first or last frame, or a group reference |
| Assembled exports | 90 days Re-assembling produces the same file from the settings frozen at export, so this expires a copy rather than your work. |
| Failed or filtered renders | No output to delete; the record is kept for accounting |
| A deleted project | The 1-day cancellable window, then everything reachable only from it goes |
| A closed account | The 7-day cancellable window |
Nothing expires without notice
You get a notice 14 days before anything goes, and again 3 days before. Each one lists exactly what is affected and carries a way to keep it. Nothing can expire that you were not told about, and nothing can expire within 3 days of the first notice — the rule is enforced in the query the sweep runs, not in a procedure someone has to remember.
Four things that stop an expiry
- It is still in use
- A seam pin, a scene's first or last frame, a group reference, or the take a scene is actually using. Anything the storyboard still points at is live content whatever its age.
- You kept it
- Every expiry notice carries a keep this button. Pressing it takes the file off the schedule indefinitely, and you can change your mind again later.
- A legal hold covers it
- Litigation, an open complaint, a law-enforcement request. Only we can lift one of these, and when a hold stops part of a deletion the receipt names it and says why.
- It predates this page
- Anything you had before this schedule was published is exempt from it. Retention starts from publication, not retroactively.
What deletion actually does
Whether something expires on this schedule, or you delete a project, or you close your account, it goes through the same path: the database rows are deleted outright, the files are deleted from storage, the edge cache is purged, the corresponding sessions in our agent runtime are disposed of, and you get a receipt saying what went, what was kept, and why.
One thing worth knowing rather than discovering. Files are stored under a hash of their contents, so two identical files are one stored file. If you delete something whose exact bytes someone else also holds, your record of it goes and the stored file stays until the last reference to it does. The receipt tells you when this happened.
The live schedule your account is on is served by the app itself at
/retention-policy, without a login,
because a policy behind a login is not published. This page and that
endpoint are generated from the same numbers, so they cannot disagree.