What "keep intact" actually sends

Most image editors now offer some version of a "keep this unchanged" control: tick face, tick text, tick lighting. The control is easy to draw and easy to get wrong in two ways that cancel each other out in testing and diverge in production.

The constraint goes after the request, not before

The intuitive order is to lead with the constraint — Change only the background. Now: put the product on marble. It reliably produces images that are about the constraint. The model weights the opening of a prompt most heavily, and an opening that talks about what not to change is a prompt whose subject is preservation.

Reversed, it behaves. The reader's own sentence is the request; the constraints are a qualifier on it:

<what the user typed>

Change only what is described above. Keep unchanged: the face and identity
of every person; all text, labels and typography exactly as written.
Leave every other part of the source image exactly as it is.

Each tick becomes a phrase, and the phrase is the specification

A tick labelled "text" has to become something the model can act on. "Keep text" is ambiguous — keep the glyphs, the font, the position, the language? The phrase we settle on is all text, labels and typography exactly as written, because it names the three things that drift separately.

Same for the others. "Framing" becomes the camera angle, framing and composition. "Product" becomes the exact shape, proportions and geometry of the product — geometry stated explicitly, because that is the one that silently changes and the one a client notices.

Keeping the phrases in one table beside the checkbox ids, rather than inline in the component, matters more than it looks: the server has to be able to build the same sentence the browser previewed.

Why the server rebuilds the prompt

If the browser composes the final prompt and posts it, then the constraint is a client-side decoration. Anyone can post a request that pays the edit price and omits the constraint — or worse, the feature silently stops working after a refactor and nobody notices, because the tests exercise the browser path.

So the ticks travel as structured data, the server composes, and the composed string is the only thing that goes upstream. The reader's own words are what gets stored against the job, which is also what you want when somebody asks why their picture changed.

One side effect worth planning for

Constraints lengthen the prompt, and prompts have a ceiling. A user whose typed text was comfortably under the limit can still produce a request that is over it, because four ticks added two hundred characters after they stopped typing. The failure arrives as a length error about a prompt the user never saw.

Either count the composed length client-side, or make the resulting error say we add the mode instructions on top of what you typed. We do the second; the first is better and we have not done it yet.

The edit mode this came out of is at gptimage25.top/image-to-image.