How to write an actionable AI creative defect report

Describe one observable problem per report

Compare these two reports: the video is bad, and the supplied jar has one lid but the generated middle section shows two. The second identifies a product invariant and a visible deviation. It can be investigated even if the recipient has a different opinion about the overall art direction.

A workbench issue needs a different description. If a source preview stays in a checking state after a file is replaced, report the sequence of interface actions and whether the replacement appears. Do not classify that as poor video generation when a paid video request never started. Likewise, a pending task is a processing state, not evidence that its eventual output will be defective.

Locate the evidence precisely

For a still, name the affected region using a stable reference such as the lower-right package corner. For video, record an interval from the actual player or editor and retain the original file. Include an unaffected nearby moment when it helps show what changed. For interface behavior, record the page and the last action that completed successfully.

Adobe describes exporting the frame at a selected playhead position as a still image. Such a capture can make a visual problem easier to discuss, but retain the clip and timing because a screenshot alone cannot show motion or persistence. Adobe’s still-frame export instructions.

Use a compact evidence record

An illustrative still-image report might identify a duplicated zipper pull, the supplied pouch photograph, the selected scene and the saved output. It does not need unrelated account history. For a UI problem, include the browser and approximate time if available; do not invent a software version or claim a repeated failure after only one observation.

Separate reproducible steps from a paid reproduction

Write the steps you actually took in order, including any change to the source after the draft was created. A saved draft, output file and task reference may give support enough information to investigate without another generation. If the behavior can be demonstrated before submission, stop at that point and say that no new paid request was made.

When a defect has occurred only once, label its frequency as unknown or observed once. If you later test another attempt intentionally, record what changed and what it cost using the current quote. Do not silently repeat a chargeable task just to claim that the issue always happens.

Share only the evidence needed and preserve the original

Exclude passwords, API keys, full payment details and unrelated private material from a support message. Crop an interface screenshot to the relevant controls when that preserves the necessary context. Share product or model references only when you have permission to share them with the recipient.

Keep an unaltered copy of the result in your own records and distinguish marked-up evidence from the original. When the issue is resolved, record whether the remedy changed the source, settings, interface behavior or production approach. That closure makes the report useful for the next occurrence without turning it into a vague list of preferences or forcing the same investigation to begin again.