Stop Using final-final.png: Track Generated Assets with YAML

Ten minutes before a fictional café website goes live, someone asks:

Which banner is final?

The project folder offers four answers:

hero-final.png
hero-final-2.png
hero-new.png
hero-use-this.png

They look similar. Nobody remembers which one was approved, whether it used a reference photo, or if the mobile crop was checked.

The problem is not the filename. The file has lost its history.

A short YAML manifest can keep that history beside the asset.

Record What the Team Needs

The café banner shows a coffee cup beside a rainy window. A developer opening it next month may need to know:

• Where will the image appear?
• Which model was used?
• Can the original task still be found?
• Were reference files involved?
• What has been checked?
• What still needs approval?

The manifest can stay small:

example_only: true

asset_id: cafe-hero-03
file: cafe-hero-03.png
placement: homepage_header
status: staging_only

created:
  date: 2026-09-14
  prompt_version: v4

source:
  model_label: "<copy from task screen>"
  task_id: "<save if available>"

references:
  used: true
  files:
    - cafe-cup-reference.jpg
  rights: review_required

checks:
  desktop_crop: pass
  mobile_crop: pass
  product_details: review_required
  publication_rights: review_required

notes: "Leave space on the left for the heading."

Use review_required when something is uncertain. A blank field or a guess can easily be mistaken for approval.

The staging_only status also matters. The file may be ready for layout testing while its references or publication rights still need review.

Explain Why a Version Was Rejected

There is no need to document every draft. Record only why the closest alternatives were rejected:

rejected:
  - file: cafe-hero-01.png
    reason: "Cup handle changes shape."

  - file: cafe-hero-02.png
    reason: "Heading covers the cup on mobile."

This prevents the same comparison from being repeated.

If the team works with ZMS AI or another shared model workspace, copy the model name and relevant settings shown for the task. Do not rely on memory because names, controls, and available options may change.

Avoid storing private tokens or signed download links in the manifest. A task ID is usually enough to locate the source without exposing temporary access details.

Test It in the Real Layout

A banner can look fine by itself and fail inside the page.

Check it on the actual website:

• Is the subject visible on a phone?
• Does text cover an important detail?
• Is there enough contrast behind the heading?
• Is the file too large?
• Do labels, hands, reflections, or product details look wrong?

In the café example, the cup sits neatly on the right in the desktop layout. The mobile crop removes half of it. “Image approved” is therefore not enough; the manifest should record which placements passed.

For video, check the thumbnail, first frame, last frame, captions, and sound timing as separate items.

Approval Is More Than Appearance

A polished asset may still be unsuitable for publication.

Before it reaches production:

• Confirm that every reference may be uploaded, processed, and reused for the project.
• Remove names, addresses, access codes, private locations, and unreleased client material.
• Review recognizable people, logos, copyrighted characters, packaging, and generated text.
• Verify factual and product details with reliable sources.

A generated product shot does not prove that the real product has the same appearance or performance. A generated action is not a safety demonstration.

If viewers could mistake the result for a real person, place, event, or product test, label it as illustrative.

Keep the Names Boring

Once the useful context lives in the manifest, filenames can stay simple:

cafe-hero-01.png
cafe-hero-02.png
cafe-hero-03.png
cafe-hero-03.yaml

That is easier to maintain than another folder full of files called final-final, and it removes the guesswork around which asset was approved.