Jewelry AI · Collections

The same image in two collections, without a second copy

Adding a generated image to a collection does not duplicate it. The app records that the collection contains that generation, and the single rule it enforces is that one image cannot sit in the same collection twice.

A collection points at the image, it does not copy it

When you add a generated image to a collection, the app records that this collection contains that generation. It does not write a second image. Membership is stored as the pair of collection and generation, and the database enforces uniqueness on that pair (packages/db/prisma/schema.prisma, @@unique([collectionId, generationId]), checked 18 August 2026).

Because the record is shared rather than copied, deleting the generation removes it from every collection it belongs to at the same time.

That leaves exactly one restriction on membership: the same image cannot sit in the same collection twice. It can sit in as many different collections as you want, and nothing in the code caps that number. Treat that as an absence of a limit in the code rather than a promise printed on the product.

What the rule allows and what it refuses

Four statements cover the whole of it; everything else on this page follows from them.

One image, any number of collections.: The uniqueness constraint applies to the pair, so the same generation can sit in several collections at once without anything being duplicated.
The same collection twice: refused, and quietly.: A repeat add is not an error and creates nothing. The server reports that item as already present and the collection is left exactly as it was.
The counts you are shown are the server's answer.: Each item is answered individually with added and already-present (apps/api/src/collections/collections.service.ts, checked 18 August 2026), so the line telling you how many were already in the collection is a result, not a guess made by the app.
Membership is not a backup.: Every collection holding the image points at the same record, so a collection keeps an arrangement of your results and not a separate copy of them.

What an add reports back

An operation that touches several images ends in three counters, not two. Each item lands in exactly one of them.

Outcome	What happened in the collection	How Undo treats it
Newly added	The pair did not exist, so the collection now points at this image.	This is what Undo takes back.
Already in the collection	The pair existed before you tapped. Nothing was created and nothing was changed.	Undo leaves it where it is.
Failed	A network error interrupted the add, so the item is counted on its own rather than as added or as already present.	Undo covers only newly added items, so a failed item is not part of it.

The entry point decides what can be filed

The result screen and the library selection are not two doors onto the same rule.

Situation	Choose	Why
You are looking at the result screen of a finished job.	File it from there.	The add-to-collection button on the result screen is shown for a completed job and carries that job alone (apps/jewelry-mobile/src/features/generation/screens/result-screen.tsx, checked 18 August 2026).
You want to file several results in one go.	Long-press in the library and build a selection.	The bulk add applies no eligibility filter, so a job that is still running or has failed can be filed along with the finished ones.
Your selection contains images you filed before.	Send it as it is.	A repeat add creates nothing and comes back as already in the collection, so trimming the selection first changes the summary and not the outcome.
You find a failed job sitting inside a collection.	Read its status badge rather than its position.	Those items keep their status badge in the collection detail, and a failed job held in a collection is designed behaviour.

Assumptions that do not hold

You file an image into a second collection expecting that collection to hold its own independent copy.
It does not. Both collections point at the same record, and neither of them stores a separate image.
You add a batch and read the already-in-the-collection number as damage.
Nothing was written for those items and nothing was removed. That number describes what the collection already held.
You wait for an Undo button that will never appear.
The button exists only when the operation newly added something. When every item was already present or every item failed, there is no button by design.
You assume a bulk add refuses anything that is not finished.
It does not filter at all. Check the status badges in the collection detail rather than assuming the collection holds only completed results.

Limits of what is described here

The behaviour on this page was read from the API and the jewelry mobile client. Anything outside that is not established here.

Whether collections appear anywhere else, including a web or admin panel, is not covered.
Sharing a collection, exporting it, sending it to someone else, or searching, filtering and hand-ordering inside one are not described on this surface.
No performance claim is made about a long collection list. Neither the list nor the detail view pages its results, and when that becomes noticeable to you has not been measured.
How long a deleted result is kept, and whether any retention job runs in production, is not established here; a constant written in code is not evidence of what runs.
Nothing here describes how a generation is produced, how the provider behaves, or how an instruction lands in the output.
Price, credit amounts, packages and plans are out of scope. This surface contains no billing code.

Before you add a batch

Know which entry point you are on: the result screen files one finished job, the library selection files whatever you selected.
Expect three numbers back — newly added, already in the collection, failed — and not two.
Read the already-in-the-collection count as a statement about the collection, not as an error to correct.
Look for Undo only after something was newly added; otherwise the button is not there.
Treat a collection as an arrangement of your results rather than a second copy of them.

What this page does not cover

Naming a collection, the order in which its contents appear and which image becomes its cover are decided elsewhere and are not described here.

How a bulk selection is built in the library, and how the different bulk actions treat the items inside it, belongs to the page about what a selection actually contains.

What deleting a collection does compared with deleting a single image, and how far each of those reaches, is a separate question from the one answered here.

Questions

Does adding an image to a second collection create a second copy?

No. The collection records that it contains that generation; the image itself is not duplicated, and every collection holding it points at the same record.

What happens if I add an image that is already in that collection?

Nothing is created and nothing fails. The server reports that item as already present, and it is counted in the already-in-the-collection line of the summary.

Why is there no Undo button after my bulk add?

Undo appears only when the operation newly added something. If every selected image was already in the collection, or every add failed, no button is shown.

Can a job that is still running be added to a collection?

From a library selection, yes: the bulk add applies no eligibility filter, so running and failed jobs can be filed. The add button on the result screen is shown for a completed job.

The same image in two collections, without a second copy

You file an image into a second collection expecting that collection to hold its own independent copy.

You add a batch and read the already-in-the-collection number as damage.

You wait for an Undo button that will never appear.

You assume a bulk add refuses anything that is not finished.