Digital Asset Version Control: Revisions vs Variants

final.psd, final-final.psd, final-FINAL-v3-approved.psd. Each filename tries to explain both the file's history and whether someone should use it. That explanation becomes unreliable as soon as another edit appears.

Creative file versioning works better when the team distinguishes a revision, a parallel variant and a delivery representation. Record which source is authoritative for each use, preserve meaningful changes, and keep approval separate from recency. Every new export does not need to become another creative version.

Separate revisions from parallel variants

A revision is a later iteration of the same creative work. If summer-hero-v05.psd corrects the price text in summer-hero-v04.psd, v05 can supersede v04 for that creative. The revision label describes a sequence; a short change note explains why the new file exists.

A variant exists alongside another creative for a different context. English and Polish campaign artwork can both be current. A desktop composition and an independently art-directed mobile composition can both be needed. Neither becomes obsolete merely because the other was saved later.

The numbering can differ across variants. The English hero might be at v05 while the Polish hero is still at v03. Record the current revision for each variant instead of looking for one newest file across the whole campaign.

A logo project illustrates the distinction:

Revisions of the master:
logo-master-v01.ai
logo-master-v02.ai

Parallel logo treatments:
logo-white.svg
logo-black.svg

Technical output from the white treatment:
logo-white-256.webp

The white and black treatments can have separate usage roles. The 256px WebP is a delivery output if it is reproducibly generated from the chosen treatment. Its dimensions and format do not establish a new creative revision.

Delivery representations have a different job

A delivery representation adapts an authoritative source for a consuming application. It may change pixel dimensions, crop, output format or a repeatable visual treatment. Its purpose is to display or distribute the chosen creative.

approved image source
├── 1200px WebP
├── 640px JPEG
└── thumbnail

Those outputs can usually be recreated when the source and recipe are retained. They do not automatically need independent creative asset records. Keeping every width and format beside the master makes it harder to distinguish a creative change from another export.

A crop needs more judgment. A standard center crop can be a delivery recipe. A designer who repositions the subject, moves the headline and retouches the mobile composition has made a creative variant. The aspect ratio alone does not decide which category the file belongs to.

Vyso's image delivery model generates requested representations from a stored source through explicit transformations. A layered design master and an approved raster image can have different roles: retain the editable master in the production workflow and choose a supported image source for delivery.

For repeatable outputs, image effects and adjustments with delivery URLs explains the recipe model. Responsive images from one source with Vyso covers generating different image candidates from the same source.

Classify a new file before saving another version

When a file arrives, ask what changed and why it exists:

1. Is it a later iteration of the same creative? Record its revision and what it supersedes.
2. Is it a parallel treatment for another language, placement or composition? Give it a variant identity and track its revisions separately.
3. Is it a technical output that can be recreated from a retained source and recipe? Treat it as a delivery representation.
4. Does it have independent editorial meaning, such as a new campaign concept? Give it its own asset identity.

These are operational classifications. A file extension, upload timestamp or visual similarity cannot supply the answer on its own.

Latest and approved are separate decisions

The newest file can still be experimental, incomplete or awaiting review:

v06: latest working revision
v05: approved for the current release

A publishing team that sorts by newest should not have to guess which of those files is usable. Record the selected revision, the intended use and where the approval decision is documented. Approval for one market or placement does not automatically settle another use.

If sign-off happens in a project tracker or review platform, keep that record connected to the identifiable file. A label such as approved in descriptive metadata can summarize the decision, but the underlying evidence explains who selected which revision and for what purpose.

A later edit needs its own decision. Copying an approved filename or tag onto v06 does not establish that someone reviewed v06. This is a team rule to implement in the actual workflow system; it should not be attributed to automatic DAM enforcement.

Use filenames for identity and metadata for context

A short naming convention helps when files leave the library:

project-role-vNN.ext

summer-campaign-hero-v03.psd
summer-campaign-hero-v04.psd

Add a locale or composition label when it distinguishes a parallel variant. Agree on the convention once and use it consistently. Avoid making every filename carry the full project history.

FINAL, LATEST and USE-THIS describe decisions that can change. A copied file can retain those words after it has been superseded. Revision labels remain useful when the current selection is recorded elsewhere.

Use descriptive context to answer questions that a filename cannot: what changed, which variant this is, which previous revision it replaces, and why an older milestone is retained. For example, a change note might say, "Price text corrected from desktop v04; Polish creative unchanged."

Test retrieval with the terms the team actually uses, such as the campaign name, hero, en and v05. Consistent human terms help people find the relevant files. They do not create a formal revision relationship or permission rule.

Distinguish working files from authoritative release assets

A working master contains the editable material needed to continue the creative work. An authoritative release asset is the selected file for a stated use. A delivery representation is the technical output consumed by a website or another channel.

Those roles can require different files. A designer may retain a layered master while supplying an approved raster image as the source for web delivery. The publishing team needs the selected source reference and presentation recipe, not every intermediate working file.

Keep the relationship understandable in the project record or descriptive metadata. If a new working master has not been released, it should not silently replace the publishing source merely because it is newer.

When an externally delivered file must be retained exactly, preserve that deliverable as evidence of what was sent. A recipe for regenerating a representation is useful, but it does not substitute for every retention requirement. Decide according to the purpose of the record.

Preserve meaningful history before reviewing duplicates

Keep revisions that document approved milestones, substantial creative changes, external deliveries or work that may be reused. Follow the organization's retention requirements where applicable. Saving every temporary preview forever is a different decision.

Accidental duplicate exports and redundant format conversions are candidates for review once their sources and uses are known. A small visual difference may be the corrected price, a translated disclaimer or an approved treatment. Similar is not the same as obsolete.

Before cleanup, identify the current authoritative source for each variant, the historical milestones worth retaining and the placements that still use older files. Only then assess redundant copies. Even identical files can have different downstream references that need to be accounted for before removal.

Vyso's Library Health surfaces duplicate and near-identical candidates for review. Those groups help locate files to inspect; they do not decide which creative is approved or which revision should survive. Keep that decision with the people who understand the project.

Where Vyso helps with asset organization

Vyso can store uploaded assets and retain the source used for image delivery. Its user-managed metadata includes userTitle, userDescription and userTags. These fields can hold a revision label, campaign, locale or change note.

For a saved image, a title such as "Summer campaign hero, desktop, v05" and tags such as summer-campaign, hero, en and v05 give the team practical retrieval context. A description can explain that it supersedes desktop v04. These are user-entered descriptions, not structured version or approval fields.

Collections can group campaign revisions, localized variants and related assets. Grouping them does not create a parent-child revision chain. The search API supports library retrieval; use consistent names and metadata, then check whether the expected files can be found.

Uploading several revisions as separate files does not automatically establish which one supersedes another. Generated image descriptions also cannot establish project sign-off from the pixels. Keep that business context in human-managed records.

Asset organization and formal revision control have different jobs

A formal revision system records relationships between changes and retains recoverable historical states. If the workflow depends on restoring an earlier file, verify that the chosen system stores that file and provides the required restore behavior.

Comparison tools, reviewer comments, approval locks and audit records are further capabilities to verify. A collection, an approved tag or several similarly named files does not provide them. Vyso's current public asset-management contract should not be treated as a documented version-history or rollback system.

A team can use a design or review tool for working history and sign-off, then use a media library to organize the selected sources and variants. The responsibilities need to be clear even when the tools differ.

A handoff that identifies the usable file

Before handing a creative to another team, check that the record answers these questions:

• Which exact source is authoritative for this use?
• Is this a revision, a parallel variant, a reproducible representation or a separate creative asset?
• Where is the decision to use this revision documented?
• Which historical files must remain available, and why?
• Which outputs can be recreated from the retained source and recipe?

The recipient should be able to identify the intended file without comparing timestamps or interpreting a sequence of "final" filenames.