AI creative approval workflow: make review states distinct from generation states

An AI creative approval workflow starts where generation status stops. A succeeded job means that a generation result was returned; it does not mean the image is accurate, on brand, correctly cropped, or approved for publication. Give those decisions explicit states in your application.

Genace’s remote job states describe generation work. Draft, in_review, approved, and withdrawn are local editorial states that you design and enforce. Keeping the two state machines separate prevents a completed render from being published automatically without a meaningful review.

Define the object being approved

Approve an exact export derivative, not an open-ended concept folder. The record should identify its source assets, copy revision, crop, and destination. If any of those change materially, create a new derivative and require the appropriate review again.

Name reviewers by responsibility. A product owner can verify facts, a designer can review visual execution, and a publishing owner can confirm placement. One person may hold several roles, but the decision should still identify what was checked.

Use explicit transitions

Current state	Allowed action	Evidence saved
Draft	Submit for review	Exact derivative and review scope
In review	Approve or request changes	Reviewer and reason
Changes requested	Create revised derivative	Parent reference and correction notes
Approved	Publish mapped derivative	Destination asset identifier
Published	Withdraw or replace	Publication record and action outcome

This table is an example application policy, not a set of Genace API states. Adapt it to your production process, but do not allow a filename change to bypass it.

Make changes invalidate approval

A corrected word, different crop, or replaced product layer can alter the meaning of a creative. Record which changes require renewed review. Even a seemingly small export change can make text unreadable or hide an important detail.

Keep the old approved derivative immutable. A revision should point back to it rather than overwrite it. This lets operators understand which file was live at a particular moment and why a replacement was chosen.

For collaborative review, attach comments to a version and region. A note saying move this left is difficult to interpret after several candidates have been replaced. Include the derivative identifier and, where useful, a marked preview.

Plan withdrawal before publication

An approved asset may later need to be withdrawn because the campaign changed or a factual detail was corrected. Preserve destination mappings so the operator can identify every publication using that derivative.

Distinguish withdrawing publication from deleting source evidence. Removing a public asset should not erase the approval history needed to explain the change. Apply your organization’s retention choices in your own storage system.

Do not assume the generation platform can retract files from your website or publishing service. Your application must own those actions and verify their result.

Acceptance checklist

Walk one candidate through draft, revision, approval, publication, and withdrawal in a staging workflow. Confirm that unapproved exports cannot publish, changed bytes do not inherit approval, and a withdrawn derivative can be located across all destination mappings.

Read asset lineage, campaign naming, and variant evaluation.

Continue with creative workflows

• AI asset version lineage: trace generation sources and every edited derivative
• synthetic avatar style catalog: organize fictional characters as reusable reviewed assets
• AI blog hero image workflow: connect the article brief to an approved publication crop
• Browse all creative workflows guides