A model name in a menu shows what the interface offers or says it will request. It does not, on its own, prove which system produced one downloaded image. To make a reliable statement about a result, distinguish the display label, the service's catalog, the task's recorded selection, and any execution information the service actually makes available.
Read four different kinds of evidence
| Evidence | What it supports | What it does not establish |
|---|---|---|
| Menu label | The option shown to the user | A completed generation |
| Catalog entry | The identifier is listed as available | The route of a particular output |
| Saved task selection | What that task requested | Whether an undocumented fallback occurred |
| Documented execution record | The fields actually recorded for that task | Details absent from the record |
These are not four mandatory screens in Imagild. They are a way to read whatever evidence your service provides. Do not invent a hidden execution report or imply that a user can see supplier internals when the product has not exposed them.
Keep the exact identifier without treating it as a specification
Services sometimes use a friendly label that differs from an API identifier. A label such as GPT Image 2.5 should therefore be read in the context of the service supplying it. An identifier's spelling is not a substitute for an official model specification, independent evaluation, or guarantee of a particular vendor's implementation.
Imagild's public image-model catalog can help check the advertised choices and current availability. Reading a catalog is different from generating an image. A successful catalog response does not show image quality, editing accuracy, generation latency, or the actual execution route of an older job. It is useful evidence, but for a narrower question.
Save a small, non-secret task record
Before a task, note the visible selected option, date, requested operation, reference filenames, and quoted estimate if relevant. Afterward, keep the result file and the task identifier or status information the product safely exposes. When reporting a discrepancy, show the label and non-secret task details together so support can inspect the same event.
Do not include API keys, access tokens, private request headers, or another person's reference images in a public complaint. You do not need those secrets to ask: “For this task, was the selected image model used, and is there a documented fallback policy?” The service may need to investigate privately; absence of a visible route should be reported as unknown, rather than filled in from the image's style.
Make the claim match the record
If only the menu is known, write “generated with the option labeled X.” If task metadata documents more, state exactly that information. If a client requires verified provenance before approving publication, agree on the evidence required before spending on production. A recognizable visual style or a comparison screenshot is not conclusive routing evidence. This distinction helps you describe Imagild and other creative services accurately without promising records they do not expose.