Version Control for Brand Creative Assets

Ask a marketing team to produce the exact file that ran as their Q1 hero ad and time how long it takes. Under ten minutes is a well-run team. Between ten minutes and an hour is normal. Over an hour — or "I think it's in Dave's downloads folder" — is the majority, and it's the majority even at companies with a proper DAM, because the DAM holds the finals and the actual working history lives in Slack threads, shared drives, and three people's local machines.

AI generation made this dramatically worse, and not for the reason you'd guess. It isn't that there are more files, though there are. It's that the variants are now nearly identical. When a campaign produced three concepts, telling them apart was trivial. When it produces forty variants of one concept differing by a lighting clause and two seconds of runtime, filename discipline stops being pedantry and becomes the only thing standing between you and shipping the wrong cut.

This is the version control system that works for creative teams — not a git tutorial, and not a DAM sales pitch. Conventions, rules, and a retention policy.

Software version control doesn't map cleanly

Worth stating plainly, because someone will suggest putting everything in git. Three reasons it doesn't fit:

• Binary files don't diff. Git can store a 400MB MP4; it can't tell you what changed between v3 and v4, which is the entire point of version control.
• Creative branches rarely merge. Two variants of a video don't combine into a third. They compete, and one wins.
• Approval, not history, is the primary need. Developers need to know what changed. Marketers need to know what's approved and what shipped.

So the system you want is closer to a library with a lineage record than a repository. Every asset knows its parent, its status, and where it went.

A naming convention that holds up

Filenames are the cheapest metadata system available and the only one that survives being emailed, downloaded, and re-uploaded elsewhere. Use a fixed order, and use it everywhere.

[campaign]_[asset]_[aspect]_[variant]_[status]_[date]

For example: spring26_herodemo_9x16_v04_APPROVED_260615

The rules that make it work:

• Campaign code first, so alphabetical sorting groups the campaign.
• Aspect ratio in the name, because 9:16 and 16:9 versions of the same asset are the most commonly confused pair in existence.
• Variant number never resets and never gets reused. v04 is v04 forever, even after it's rejected.
• Status is one of four words: WIP, REVIEW, APPROVED, LIVE. Not "final," never "final2," and absolutely never "FINALfinal."
• Dates are YYMMDD, which sorts correctly and is unambiguous internationally.

Ban the word "final." It's not a joke about designers — "final" encodes an intention rather than a state, and intentions change. APPROVED is checkable: either someone approved it or they didn't.

The approved-master rule

One rule, and it prevents most version disasters:

Exactly one file per asset per aspect ratio carries the APPROVED status at any time. Everything else is WIP, REVIEW, or archived.

When v05 is approved, v04's status changes. Not "v04 stays around in case" — it moves to archive with its status downgraded. If two files both claim to be approved, somebody will publish the wrong one, and it will be the one that was easier to find.

Corollary: LIVE is set by whoever publishes, not by whoever approves. The gap between "approved" and "actually running" is where a surprising number of mistakes hide — an asset approved on Tuesday and a different cut uploaded on Thursday is a failure nobody detects for weeks.

Handling AI variants specifically

This is where the volume problem lives. Forty near-identical generations from one prompt is a normal Tuesday, and storing all forty with full naming ceremony is absurd.

Use a two-tier model:

Tier 1 — the generation pool. Everything the model produced, kept in the generation history rather than in your asset library. Unnamed, unversioned, searchable by prompt and date. Most of it will never be touched again. Generation history in the platform serves this purpose, which means you don't need to download rejects at all — a habit that alone cuts the clutter dramatically.

Tier 2 — the asset library. Only what a human selected and intends to use. These get the full filename convention, a lineage record, and a status. Typically 5–10% of tier 1.

The promotion from tier 1 to tier 2 is a deliberate human action, and it's the moment metadata gets attached. Anything that never gets promoted never needs naming. This is the single change that makes version control tractable at AI volume — you're not versioning generations, you're versioning selections.

The lineage record

For every tier-2 asset, store four things beyond the file:

Field	Why it matters
Source prompt + model	Lets you regenerate a matching asset months later
Parent asset	"v05 is a retake of v04's third scene"
Approver + date	Answers "who signed off" without archaeology
Destinations	Which platforms, which campaigns, which dates

The source prompt field is the one people underestimate. Six months later, marketing wants "another one like the spring hero, but for autumn." Without the prompt and model recorded, you're reverse-engineering your own work from a video file. With it, you regenerate a matched asset in ten minutes.

If the asset came out of a saved multi-scene structure, the structure itself is the record — running a stored workflow again with new inputs is a much stronger form of reproducibility than any filename. That's the argument for promoting recurring formats into workflows rather than treating each production as a one-off, and it connects directly to how you organize reusable material, covered in asset libraries and reuse in AI content production.

Retention: what to keep and for how long

Storage is cheap; search is not. The reason to delete is findability, with legal exposure a close second.

A policy that works for most marketing teams:

• Generation pool: keep 90 days, then let it age out. If it wasn't promoted in three months, it isn't going to be.
• Tier-2 rejected variants: keep 12 months. Occasionally useful for "why did we pick this one" conversations.
• Approved masters: keep indefinitely. These are small in number and high in value.
• Anything that ran as paid media: keep for as long as your advertising claims substantiation requires — often longer than marketing expects, so ask rather than assume.
• Source references (product photos, brand assets, reference images): keep indefinitely, versioned separately. These are inputs, not outputs.

That last category is worth separating physically. Reference images used for character or product consistency are not creative outputs; they're upstream dependencies. If someone deletes the reference set, every future asset in that campaign becomes unreproducible.

Making it stick

Three practices, in order of impact:

1. Name at promotion, not at download. The naming happens once, at the moment of selection, by the person selecting. Retroactive naming projects never finish.
2. One folder structure, campaign-first. /campaigns/spring26/video/9x16/. Not by person, not by date, not by tool. People leave; campaigns don't.
3. Audit quarterly with one question. Pick three assets that ran last quarter and try to produce the approved master plus its prompt in under five minutes. If you can't, the system isn't working, and you'll learn exactly where it broke.

Pair this with a review process so that "approved" means something specific — quality control for AI-generated marketing assets defines the gates that produce the status this system tracks. Version control without a real approval step just records the order in which files appeared.

FAQ

Do we need a DAM for AI-generated creative assets?

Not initially. A disciplined folder structure with a strict naming convention handles a team of two to six producing a few hundred assets a quarter. A DAM earns its cost when you have multiple teams, external agencies, or rights-managed assets to track — before that, it's usually a place where undisciplined files go to be undisciplined more expensively.

Should we keep every AI generation?

No. Keep the generation pool for about 90 days in your platform's history, promote only what a human selected into the named asset library, and let the rest age out. Downloading every variant is the fastest way to make your storage unsearchable.

How do we stop people using outdated versions?

The approved-master rule: exactly one file per asset per aspect ratio carries APPROVED at a time, and superseded versions get their status changed and move to archive immediately. Most wrong-version incidents happen because two files both looked current in the same folder.

What's the most important field to record besides the file?

The source prompt and model. It's what lets you produce a matching asset months later without reverse-engineering your own output, and it's the field most teams discover they need only after they've already lost it.

How does version control work for multi-scene videos?

Version the whole assembled cut for approval purposes, and version the reusable structure separately. If a single scene changes, that's a new version of the cut — but the underlying workflow definition is what you actually maintain over time, and re-running it is a stronger reproducibility guarantee than any archived file.

Run the five-minute audit this week: pick three assets that shipped last quarter and try to produce the approved master with its prompt. Whatever slows you down is the part of the system worth fixing first.