Give Product Image Prompts a Clear Contract

A structured brief for XPT image edits, with explicit invariants and review criteria for Amazon secondary images.

An image-editing prompt can be treated as a small specification: identify the input, name the permitted change, and state what a reviewer should check afterward.

For Amazon product visuals, this makes the boundary between the product and its presentation explicit. It does not make generation deterministic or guarantee that the product will be preserved.

Represent the brief as data

Here is a fictional brief for a photographed desk stand:

{
  "asset_role": "secondary_studio_image",
  "source_file": "stand-front-original.jpg",
  "allowed_changes": ["background"],
  "preserve": [
    "stand geometry",
    "hinge position",
    "rubber pads",
    "surface finish",
    "visible markings",
    "camera angle"
  ],
  "background": "plain light-gray wall and matte surface",
  "exclude": ["devices", "accessories", "text", "new features"],
  "review_status": "unreviewed"
}

This JSON is a planning format, not an XPT API payload. It can live in a local file or a project brief without requiring an integration.

Translate the brief into an editing instruction

The process described in XPT's reference-image workflow for Amazon uses a real product photograph and a text instruction. The example above becomes:

Edit the uploaded desk-stand photograph for a secondary studio image. Change only the background to a plain light-gray wall and matte surface. Preserve the geometry, hinge position, rubber pads, finish, markings, and camera angle. Add no devices, accessories, text, or new features.

The benefit of the structured brief is reviewability. Someone can see which changes were requested without reconstructing the intent from a long conversation.

Turn each invariant into a review question

“Preserve geometry” becomes “Do the visible edges and proportions still match the original?” “Preserve rubber pads” becomes “Are the pads present in the same positions?”

Record each answer with the candidate filename. A useful outcome is one of three states: accepted for final checks, needs another background edit, or rejected because the product changed.

Do not turn a visual similarity score into automatic approval. This example proposes a human review process, not a tested computer-vision evaluator.

Version the request as well as the image

If the background is too dark, change that field and leave the invariants alone. Save the new prompt with the resulting candidate. This lets a reviewer distinguish a deliberate brief change from an unintended model change.

Keep marketplace validation separate. Check Amazon's current photography guidance and category requirements before upload; a complete brief does not establish compliance.

The same structure can support other image-editing tasks where part of the source must remain stable. Its value is making the requested transformation and the review decision explicit.

This article was drafted with AI assistance. The JSON and prompts are illustrative; no XPT API integration or benchmark is claimed.