ElanoryaJewelry AI · Deleting a result
Deleting a result starts a thirty-day clock
Deletion and permanent purge are two separate events in this app, and the interval between them is fixed in code. This page says what the interval is, what runs at the end of it, and what the record looks like afterwards.
What deleting a result starts
Deleting a generation in Jewelry AI does not end the record's life in the same instant. It starts a fixed interval that ends in a permanent purge, and the length of that interval is thirty days (soft-delete-retention-sweeper.ts:25, verified 2026-08-18).
Two things follow from that shape. The first is that the number is about the gap between your deletion and the purge, not about the app's handling of results in general. The second is that the purge is carried out by a background sweeper, so the thirtieth day is the point at which the work falls due rather than the point at which it is certain to have been done.
What the code fixes, and where
Each line below is a statement from the product's own code, with the file and line it was read from.
- The retention window is thirty days.
- RETENTION_MS = 30 * 24 * 60 * 60 * 1000 (soft-delete-retention-sweeper.ts:25). The value is a constant in that file, not an environment or configuration setting.
- The purge leaves a stamped record behind.
- The purge sets purgedAt to the current time and clears outputAssetId to null (generation.service.ts:943).
- A purged record is no longer eligible as an input to any tool.
- The resolvers that pick a source for a new job, and the collection reads that list saved work, both exclude purged records (generation.service.ts:362-375 and 562-576, collections.service.ts:48 and 164).
- The sweeper runs in batches and raises an alert when it is behind.
- It handles 100 records per round and produces the RETENTION-01 backlog alert (soft-delete-retention-sweeper.ts:145-158).
The values this page rests on
Read from the product's code on 2026-08-18.
| What | Value | Where it is written |
|---|---|---|
| Interval between deleting a record and its purge | 30 days, as a code constant | soft-delete-retention-sweeper.ts:25 |
| Records handled per sweeper round | 100 | soft-delete-retention-sweeper.ts:145-158 |
| Alert raised when a backlog builds | RETENTION-01 | soft-delete-retention-sweeper.ts:145-158 |
| What the purge writes onto the record | purgedAt set, outputAssetId cleared | generation.service.ts:943 |
Why the purge is due rather than scheduled
The sweeper does not clear everything that has come of age in one pass. It takes 100 records per round, and when deletions arrive faster than the rounds can clear them the backlog raises the RETENTION-01 alert for the people running the service (soft-delete-retention-sweeper.ts:145-158).
That is the honest description of the timing, and it is as far as this page goes. Thirty days is when a deleted record becomes eligible for purging; the pace above is what decides the order it is taken in. No maximum time to completion is stated here, because the code read for this page does not set one.
What the record looks like after the purge
The purge does not remove the row. It writes the time of the purge onto the record and clears the reference to the output asset (generation.service.ts:943), so what remains is a record that says a purge happened and points at no output.
If you are looking at a record with a purge time on it, that is the shape of a purged record rather than a failure of the delete action.
Your own copy of a file is a separate matter from any of this, and it is covered by the page on using your own model photo, which sets out what an own-photo run keeps in its job record and what it drops.
Where sellers misread the thirty days
Three readings that look reasonable and are not what the code does.
Clearing out a large batch and expecting all of it to be purged in the same pass.
The sweeper takes 100 records per round, so a large clear-out is spread across rounds; a sustained backlog is what the RETENTION-01 alert exists for.
Quoting the thirty days to a customer as the app's data-retention policy.
State it as the interval between your own deletion of a record and that record's purge. The constant supports nothing wider than that.
Treating a record that carries a purge time as a bug in the history.
That is the documented outcome: the row stays, the purge time is stamped and the output asset reference is cleared (generation.service.ts:943).
Boundaries this page keeps
Boundaries are stated rather than implied.
- Whether a deleted result can be brought back by you before the purge runs. The code read for this page does not establish it in either direction, so no claim is made either way.
- Any maximum time to purge. The window, the batch size and the backlog alert are described; a completion deadline is not, because none was found.
- The general rules for when a record qualifies as the input to a new job. This page states only the narrow point made above and leaves the wider mechanism to a page of its own.
- What the app uploads when you submit a generation in the first place. That belongs to the page on what actually leaves your phone.
- Anything about credits, refunds or what a deletion does to a charge that has already been made.
Questions
Does the thirty-day window apply to every generation I make?
No. It is the interval the sweeper applies to records you have deleted. It says nothing about how long a result you keep is held, and this page states no such period.
Can I change the thirty days for my account or my studio?
No. The value is written into the sweeper's code as RETENTION_MS = 30 * 24 * 60 * 60 * 1000 (soft-delete-retention-sweeper.ts:25). It is not an environment variable and there is no control for it in the app.
What is left once the purge has run?
A stamped record. The purge sets purgedAt to the time it ran and clears outputAssetId to null (generation.service.ts:943), so the row remains and no longer points at an output asset.
Will the purge happen exactly on the thirtieth day?
The thirtieth day is when the purge falls due. The sweeper then works through 100 records per round and raises the RETENTION-01 alert if a backlog builds (soft-delete-retention-sweeper.ts:145-158), so this page describes that pace instead of promising a completion time.