A Practical Wine Asset File Naming Convention

Give every downloaded file enough identity

This guide is for alcohol importer operations teams naming bottle images, label images, tech sheets, sell sheets, logos, photography, and other files that move between producers, importers, distributors, agencies, and sales teams. It provides a convention, controlled values, examples, an adoption procedure, and a final quality check.

The goal is not to pack the entire product record into a filename. The goal is to preserve enough identity that a colleague can recognize a file after downloading it, while structured metadata and the asset record carry details that do not belong in the name.

Use this base pattern:

producer-wine-release-market-asset-detail-revision.ext

A typical file looks like this:

rio-claro-reserva-2024-us-front-bottle-r02.jpg

The same order should apply across the portfolio. The U.S. National Archives recommends conventions that are descriptive, consistent, and meaningful, with components such as dates or versions kept in the same position in every name. Its guidance also recommends using lowercase letters, numbers, underscores, and hyphens rather than spaces in filenames. See the NARA file naming guidance.

Decide what the filename must answer

A distributor who sees a file outside your library should be able to answer:

Which producer or brand is this?
Which wine or product is this?
Which release does it represent?
Which market does it belong to?
What kind of asset is it?
Which approved revision is it?

Those questions define the filename fields. Do not add a field merely because it exists in the product database. Bottle volume, language, item code, pack, channel, and image view should appear only when they distinguish files that would otherwise have the same name.

Use required and conditional fields

Field	Rule	Example
Producer	Required	`rio-claro`
Wine	Required for product assets	`reserva`
Release	Required when the asset is release-specific	`2024` or `nv`
Market	Required when market versions exist	`us`
Asset	Required	`front-bottle`
Detail	Add only to resolve a real distinction	`750ml`, `en`, `hero`
Revision	Required for controlled outputs	`r02`
Extension	Preserve the correct file format	`.jpg`

For a producer-level asset, omit fields that do not apply rather than filling them with vague words:

rio-claro-logo-primary-r03.svg

For a bilingual, market-specific sell sheet, add the language because it changes which file the recipient should use:

rio-claro-reserva-2024-us-sell-sheet-es-r01.pdf

For two active bottle sizes, add volume because the package differs:

rio-claro-reserva-2024-us-750ml-front-bottle-r02.jpg

Define each segment before renaming files

The convention becomes reliable only when each segment has one meaning. Write the allowed values into a short naming dictionary and make one person responsible for changes.

Producer and wine

Use the portfolio’s approved display identity in a filename-safe form. Remove punctuation, replace spaces with a single hyphen, and choose one transliteration rule for characters that partner systems may not handle consistently.

Do not alternate among legal entity, producer, brand, and informal shorthand. Choose the identity distributors actually use to find the product, then store the legal entity and other aliases as metadata.

Examples:

Display identity	Filename value
Domaine du Lac	`domaine-du-lac`
Cuvée No. 7	`cuvee-no-7`
Château L’Orme	`chateau-lorme`

An importer SKU can be added when several products share confusingly similar names or when the distributor’s workflow depends on that code. Keep the human-readable wine name too:

rio-claro-reserva-rc104-2024-us-tech-sheet-r01.pdf

Release

Use the four-digit vintage shown for the applicable product release. Use one controlled token, such as nv, for a non-vintage product. Do not use current, new, old, last-year, or next-vintage.

Vintage is product identity, not merely a date in a filename. TTB describes a vintage date as the year of the grape harvest and notes that, when one appears on a wine label, an appellation of origin is required on the brand label. See the TTB Anatomy of a Wine Label. The file should match the exact release shown or described in the asset.

A brand history, logo, or general estate photograph may apply across releases. Leave the release field out when the owner has confirmed that the asset is not vintage-specific.

Market and language

Use a controlled market code when labels, importer statements, packaging, item codes, copy, or approvals vary by destination. A country code may be enough for one portfolio. Another portfolio may need a country plus a state, province, or distributor territory.

Keep market and language separate. us identifies the market. es identifies Spanish-language content. A Spanish sheet used in the United States could therefore contain both:

rio-claro-reserva-2024-us-tech-sheet-es-r01.pdf

Do not add market or language to every file if the distinction never exists. Conditional fields should resolve ambiguity, not make every filename longer.

Asset type and image detail

Use a small controlled vocabulary. Choose one preferred term for each type and reject synonyms at intake.

Preferred value	Use for	Avoid
`front-bottle`	Front bottle product image	`bottle-shot`, `packshot`, `btl`
`back-bottle`	Back bottle product image	`reverse`, `back-pic`
`front-label`	Flat or isolated front label	`label1`
`back-label`	Flat or isolated back label	`label2`
`tech-sheet`	Technical product sheet	`specs`, `tech-info`
`sell-sheet`	Sales-oriented product sheet	`sales-pdf`, `one-sheet`
`logo-primary`	Approved primary logo	`main-logo`, `logo-final`
`logo-mark`	Approved symbol or mark	`icon-logo`
`producer-photo`	Producer or team photograph	`people-pic`
`vineyard-photo`	Vineyard photograph	`landscape`
`map`	Approved geographic map	`location-art`

A filename can identify the view, but image metadata should still preserve description, creator, rights, and other retrieval information. The IPTC Photo Metadata standard defines administrative, descriptive, and copyright information for images. Filename and embedded metadata solve different problems.

Revision

Use a zero-padded revision token such as r01, r02, and r03. Increment it whenever the released file changes. Keep approval state, currentness, reviewer, and change reason in the asset system rather than encoding them as approved, final, or latest.

A revision number answers, “Which copy is this?” It does not answer, “May I use it?” That decision belongs to the asset record and distributor-facing publication view.

If dates are central to a document, use an unambiguous date in YYYYMMDD order. Put it in a fixed position defined by the convention:

rio-claro-reserva-2024-us-price-list-20260926-r01.pdf

Do not use a date instead of a revision when two corrected outputs can be released on the same day.

Use one portfolio template with documented branches

A single rigid pattern does not fit logos, bottle images, and sales documents equally well. Use one base order, then document the permitted branches.

Product and release assets

producer-wine-release-market-asset-detail-revision.ext

Examples:

rio-claro-reserva-2024-us-front-bottle-r02.jpg
rio-claro-reserva-2024-us-back-label-r01.tif
rio-claro-reserva-2024-us-tech-sheet-en-r03.pdf
rio-claro-reserva-2024-us-sell-sheet-es-r01.pdf

Non-vintage product assets

producer-wine-nv-market-asset-detail-revision.ext

Examples:

maison-verte-brut-nv-us-front-bottle-750ml-r01.jpg
maison-verte-brut-nv-us-tech-sheet-en-r02.pdf

Producer-level brand assets

producer-asset-detail-revision.ext

Examples:

rio-claro-logo-primary-r03.svg
rio-claro-logo-primary-white-r03.png
rio-claro-producer-photo-ana-rivera-r01.jpg
rio-claro-vineyard-photo-east-block-r02.jpg

Multi-product assets

Use the producer or collection name, then name the scope explicitly:

rio-claro-portfolio-overview-us-en-r04.pdf
rio-claro-spring-collection-us-sell-sheet-r01.pdf

Do not force a single wine or vintage into a file that intentionally covers several products. Record every included product relationship in metadata.

Keep filenames readable and system-safe

Use lowercase letters, digits, and single hyphens between segments. Keep the extension lowercase. Remove spaces and avoid punctuation that can be interpreted differently across systems.

Apply these mechanical rules:

one hyphen between words and fields
no leading or trailing hyphen
no repeated hyphens
one period before the extension
no spaces
no slashes, colons, quotation marks, question marks, or symbols
no unexplained internal abbreviation
no approval claim such as approved or final
no personal initials as the only revision history

The National Archives notes that operating systems and file systems differ in supported names, path lengths, and character sets. Its platform-independent guidance is a useful baseline even when the assets are not federal records. It also advises keeping a complete file path within 255 characters. See NARA’s platform-independent naming recommendations.

Treat that path length as a ceiling, not a target. A filename should remain legible in an email attachment list and a distributor’s download folder. Shorten controlled producer or product values only through documented aliases, not improvised truncation.

Separate your internal convention from partner specifications

A retailer, distributor, data pool, or agency may require a delivery filename that differs from your internal readable name. Preserve the governed internal identity, then generate or store the required delivery name as a separate rendition.

The GS1 Product Image Specification contains its own rules for digital images and filename construction. If a trading partner requires that specification, follow the exact applicable GS1 rule rather than inserting parts of it into a homegrown convention.

Use a mapping record:

Asset record	Internal filename	Partner delivery filename	Requirement owner
`A-01842`	`rio-claro-reserva-2024-us-front-bottle-r02.jpg`	Partner-required value	Named account owner

This prevents a partner-specific delivery name from replacing the importer’s recognizable source identity. It also lets the team reproduce a delivery package without manually renaming the master file each time.

Build the convention from real collisions

Do not start by debating separators. Start with twenty to fifty current files that represent the portfolio’s actual variation.

Step 1: inventory representative files

Include:

two producers with similar wine names
vintage and non-vintage wines
overlapping active vintages
more than one bottle size
front and back bottle images
market-specific labels
translated tech or sell sheets
logos with several approved treatments
one multi-product presentation
one file with multiple revisions

Step 2: identify collisions

Draft the shortest possible name for each file. Add a field only when two different assets receive the same name or a recipient cannot identify the correct file.

For example:

rio-claro-reserva-2024-front-bottle-r01.jpg

If separate United States and Canada packages exist, add market. If 750 mL and 1 L packages exist within the same market, add volume. If neither distinction exists, leave those fields out.

Step 3: write the naming dictionary

Record:

field order
required fields
conditional fields and their triggers
allowed asset types
market and language codes
transliteration rules
non-vintage token
revision format
examples for each asset family
owner of the convention

Step 4: test outside the library

Download the files into one empty folder. Sort by name. Ask a colleague who did not design the convention to identify the producer, wine, release, market, asset type, and revision.

Then attach several files to a test email and view them on the devices used by the team. Confirm that important distinguishing information has not been cut off in ordinary interfaces.

Step 5: approve and freeze version one

Publish the dictionary where everyone who receives or releases assets can find it. Record the effective date. Route exceptions to the convention owner rather than letting each user invent a new token.

Rename existing assets without losing history

A mass rename can break links, duplicate files, and obscure which revision was previously distributed. Migrate one controlled portfolio slice before touching the full library.

Use this procedure:

Export the current asset inventory, including paths, links, product relationships, statuses, and owners.
Assign a stable asset ID that will not change with the filename.
Generate the proposed filename from controlled fields.
Flag duplicates before renaming anything.
Have the product or asset owner resolve ambiguous producer, wine, release, and market values.
Preserve the original filename in metadata.
Rename or create a governed rendition without overwriting source evidence.
Update managed links and distributor collections.
Test downloads, previews, and direct links.
Retire the old current-use path only after the replacement is confirmed.

Keep a migration table:

Asset ID	Original filename	New filename	Status	Link checked
`A-01842`	`bottle_final2.jpg`	`rio-claro-reserva-2024-us-front-bottle-r02.jpg`	Current	Yes
`A-01843`	`RC tech NEW.pdf`	`rio-claro-reserva-2024-us-tech-sheet-en-r03.pdf`	Current	Yes

Do not infer approval from a word in the old filename. final2 may be an editing label rather than evidence of review. Resolve status from the actual approval record and responsible owner.

Apply the name during intake and release

Naming should be a controlled step in the asset workflow, not an occasional cleanup project.

At intake:

Preserve the received source file and original name.
Link it to the correct producer, product, release, package, and market.
Select the asset type from the controlled vocabulary.
Generate the working filename.
Record creator, source, rights, and descriptive metadata where applicable.

At release:

Confirm that visible content matches the filename fields.
Confirm the exact revision that received approval.
Generate the released filename.
Publish it to the intended distributor view.
Remove the predecessor from default current access when it has been superseded.
Preserve the predecessor and distribution history internally.

For a broader operating model around approvals, publishing, replacement, and retirement, use the wine brand asset management guide. For folder structure, metadata, and distributor access, see how to organize wine brand assets for distributors.

Handle the common edge cases explicitly

The vintage is unknown

Do not guess. Hold the asset in intake until the product owner confirms whether it is release-specific. If the asset genuinely applies across releases, omit the release field.

Two vintages are active

Name both with their actual vintage. Currentness and availability belong in the product and asset records, not in old and new filename labels.

A label image and bottle image show different markets

Treat them as separate market assets. The TTB label guide identifies market-relevant label elements including brand name, class or type, vintage when used, alcohol content, health warning, and the bottler or importer name and address. Use the TTB wine label reference during qualified review, not the filename as a substitute for that review.

The logo has light and dark versions

Use a controlled treatment value such as white, black, or full-color after the asset type:

rio-claro-logo-primary-full-color-r03.svg
rio-claro-logo-primary-white-r03.svg

Record usage guidance separately. A color token identifies the file but does not explain where the logo may be used.

A photo has several crops

Keep one stable asset identity and name renditions by purpose or aspect only when recipients need to distinguish them:

rio-claro-producer-photo-ana-rivera-original-r01.jpg
rio-claro-producer-photo-ana-rivera-square-r01.jpg
rio-claro-producer-photo-ana-rivera-wide-r01.jpg

Preserve creator, caption, copyright, and licensing details as metadata using fields supported by the IPTC Photo Metadata standard.

A correction does not change the visible filename fields

Increment the revision. Record the change reason and approval against the exact new file. Never overwrite the released binary while leaving the revision unchanged.

Use a filename generator instead of manual typing

Once the dictionary is stable, generate names from controlled asset fields. The generator can be a spreadsheet formula, a script, or a workflow inside the asset system. Its job is mechanical consistency.

The generator should:

normalize approved producer and wine aliases
insert fields in the defined order
omit conditional fields when they do not apply
convert spaces to single hyphens
reject unapproved asset-type values
reject missing required fields
reject duplicate proposed names
preserve the correct extension
produce a preview before rename or release

It should not decide which vintage, market, product, or approval applies. Those are ownership decisions.

The pre-launch Depletement workspace for alcohol importer operations is being designed to connect product and catalog details with bottle and brand assets, technical sheets, sell sheets, distributor asset access, and vintage updates. That product relationship is the useful foundation for generated filenames: the name can be assembled from approved fields instead of retyped from memory.

Run a final filename QA check

Before releasing an asset, confirm:

A useful convention is predictable rather than clever. Put stable identity first, keep fields in one order, add conditional detail only when it prevents a real mix-up, and let the asset record carry the governance that a filename cannot.