Data contract for Meta AI ad creative: fields, provenance, review and performance context

Short answer: Treat AI-generated ad creative as a governed derivative of source assets, not as an anonymous black-box output. Store source provenance, generation method, product/claim constraints, reviewer state, serving context and performance observations separately. Meta publishes first-party claims about growth and performance of its AI ad systems, but your data contract should preserve those as vendor evidence rather than account-level guarantees.

Why AI creative needs a data contract

Meta's 2026 company update describes expanding AI use in advertising, including video-generation tools, ads ranking improvements and broader automation. The announcement also contains aggregate performance and revenue claims based on Meta's own internal systems.

That creates two distinct data problems for advertisers:

• tracking what was generated and from which source material;
• measuring what happened without confusing platform-level claims with account-level evidence.

A data contract solves both by making asset lineage and measurement context explicit.

Identity fields

Every generated or transformed asset should have a stable record.

Recommended fields:

• asset_id;
• campaign_id;
• ad_set_id where relevant;
• market;
• language;
• generation_date;
• generation_tool;
• creator_or_operator;
• review_status;
• serving_status.

Do not rely only on a file name or media-library thumbnail.

Source-provenance fields

Record the inputs used to create the asset.

Possible fields include:

• source_image_ids;
• source_video_ids;
• source_copy_id;
• product_feed_reference;
• brand_guideline_version;
• rights_owner;
• usage_rights_state;
• source_verified_at.

If the system derives creative from several inputs, preserve the many-to-one relationship instead of flattening the lineage.

Generation fields

The team should know what kind of transformation occurred.

Examples:

• background generation;
• image expansion;
• video generation;
• copy variation;
• format adaptation;
• product-scene synthesis;
• motion generation;
• compositing.

Use a controlled field such as transformation_type and optionally store a sanitized instruction or configuration reference when policy allows.

The goal is reproducibility and auditability, not prompt hoarding.

Product-truth fields

Creative generation should not alter material product facts silently.

Store or link to approved facts such as:

• product identity;
• variant;
• price scope;
• availability;
• dimensions;
• performance claims;
• legal disclaimers;
• geographic limitations;
• promotion validity.

A visual can be aesthetically plausible while factually wrong.

Claim-control fields

For every material claim, track:

• claim text;
• claim category;
• evidence source;
• allowed markets;
• mandatory qualifier;
• approval owner;
• expiry/review date.

This is especially important when generated copy varies across audiences or placements.

Reviewer-state fields

Use explicit review states instead of a binary approved flag.

Examples:

• DRAFT_GENERATED;
• FACT_REVIEW_REQUIRED;
• RIGHTS_REVIEW_REQUIRED;
• BRAND_REVIEW_REQUIRED;
• APPROVED_FOR_TEST;
• APPROVED_FOR_SCALE;
• REJECTED;
• RETIRED.

Record the reviewer and reason for rejection or correction.

Serving-context fields

The same asset can perform differently depending on where and to whom it serves.

Store context such as:

• placement;
• audience definition;
• campaign objective;
• optimization event;
• geography;
• frequency context;
• start/end window;
• major campaign changes.

Do not treat asset performance as an intrinsic property independent of delivery.

Performance fields

Keep performance observations separate from provenance.

Possible metrics include:

• impressions;
• spend;
• clicks;
• conversions;
• conversion value;
• video engagement;
• downstream qualified outcome where available.

Add interpretation fields:

• comparison_type;
• baseline_asset_id;
• experiment_id;
• confounder_notes;
• causal_status.

A high-performing generated asset is not proof that generation itself caused the improvement unless the comparison design supports that claim.

Freshness and retirement rules

Review generated assets when:

• product facts change;
• promotion expires;
• rights expire;
• brand guidelines change;
• platform policy changes;
• creative becomes misleading because of market conditions;
• a source asset is withdrawn.

Retirement should cascade to derivatives when their source rights or factual basis disappear.

QA checks

A robust QA routine checks for:

• missing source lineage;
• unapproved claims;
• expired rights;
• inconsistent product representation;
• market-language mismatch;
• generated people or scenes requiring stronger disclosure/review;
• duplicate variants with no distinct test purpose;
• performance claims copied from Meta's vendor data into account reporting.

Lineage reconciliation after edits

When a human edits a generated asset, create a new derivative record instead of overwriting the generated version. Preserve the parent asset, editor, reason for change, corrected claim or visual element, and new approval state. If the platform later creates another variation from the edited asset, record that new parent-child relationship as well. This prevents a final approved creative from losing the history needed to explain which facts, rights or design choices changed during review.

The data-contract rule

AI ad creative should be managed as versioned, reviewable derivatives with explicit source and measurement context.

Preserve what the asset came from, what changed, who approved it and how it performed. Keep Meta's aggregate product claims labeled as vendor evidence and use your own experiments and business outcomes for account-level conclusions.

Sources reviewed

• https://about.fb.com/news/2026/01/2026-ai-drives-performance/