A useful product photography file system answers five questions:
- Which job does this file belong to?
- Which product or shot does it represent?
- What stage is it in?
- Which version or decision applies?
- Is it safe to release?
The answer does not need to live entirely in the filename.
It can live in the folder path, catalog metadata, shot-list mapping, proof version, delivery manifest, or project record.
The rule is that another authorized studio user can recover the meaning from the current system without guessing.
Separate four file states
Source
Original capture, scan, or supplied source material.
Working
Layered, intermediate, selected, or in-progress production file.
Proof
A file or set prepared for a named review and version.
Final
The current client-facing file approved and released under the job policy.
Do not mix the four states in one delivery folder.
Do not call a file final merely because it is a JPEG.
Choose a primary organizing axis
Different studios need different top-level structures.
Use one primary axis and a reliable secondary mapping.
Job first
Useful when the studio works through defined client jobs.
- Client
- Job
- Source
- Working
- Proof
- Final
- Manifest
Product first
Useful when a product library supports several jobs or destinations under a DAM or PIM.
- Product
- Variant
- Source
- Approved asset
- Destination outputs
Production batch first
Useful when the ingest batch is the primary operational record.
- Capture date
- Set or station
- Source
- Selection
- Mapped outputs
Do not combine every possible axis into a deep folder tree.
The shot list, catalog, or manifest can carry the other relationships.
Use stable identifiers
Possible keys include:
- Job number
- Client SKU
- Product ID
- Variant ID
- Shot-row ID
- Asset ID
- Version
- Destination role
- Locale
Do not expose a private database ID to the client when a client-safe identifier exists.
Do not invent an Amazon ASIN or another channel ID before the client has one.
A filename does not need to contain everything
A final delivery name can include:
- Product identifier
- Variant when relevant
- View or asset
- Sequence
- Destination role when needed
- Locale when needed
- Extension
Example:
tt-linen-01_seafoam_front_shopify.jpg
A studio can also use:
tt-linen-01_seafoam_front.jpg
and keep the destination in the folder or manifest.
Use the shortest convention that remains unambiguous in the client's real handoff.
Do not force client, job date, channel, status, retouching treatment, and version into every filename.
Keep source and delivery names separate
A source file can remain:
A003_C014_0822AB.CR3
The working catalog maps it to:
TT-LINEN-01 / Seafoam / Front
The proof can be:
tt-linen-01_seafoam_front_v2-proof.jpg
The released file can be:
tt-linen-01_seafoam_front.jpg
The mapping is more important than forcing the source object to take the final name.
In the reviewed Lenso delivery model, a client-facing delivery name can be applied without renaming the underlying storage object.
Cursor must verify the latest behavior before publishing that statement.
The naming rule only holds if the handoffs around it do — the post-production workflow covers where source, proof, and delivery names get assigned along the way.
Write the version rule
A useful rule identifies:
- What counts as a new version
- How the current version is named
- Whether superseded proofs remain
- How comments remain attached
- When the delivery name loses the version suffix
Example:
- Proof versions use v1, v2, and v3.
- The final client-facing filename omits the proof version.
- The job history records which proof was approved.
Do not use `final`, `final-final`, or `final-approved-new` as the version model.
Keep the delivery set deliberate
The final delivery set should contain:
- Current released files
- Delivery manifest when needed
- Client-facing filenames
- No source files unless deliberately included
- No working files
- No obsolete proofs
- No private internal notes
- No protected preview when an original is required
Test the actual ZIP or download.
Do not assume the folder is safe because its name is `Final`.
Use a manifest when filenames are not enough
A delivery manifest can map:
- Product or SKU
- Variant
- View or asset
- Delivery filename
- Output
- Status
- Secure download link
- Exception
A manifest is useful when several files look similar, one product has several views, one file serves several products, several destinations receive different outputs, or the client needs a machine-readable handoff.
The manifest should match the actual released files.
Organize working files around the editing system
A layered working file can require sidecars, linked objects, external textures, source exposures, catalog databases, caches, or application-specific packages.
Do not move or rename a working project casually.
Use the editing application's supported collect or archive behavior.
This article is not a software-specific backup manual.
Retention is a policy, not a universal number
Define the retention decision for:
- Source files
- Working files
- Proofs
- Final files
- Manifests
- Client messages and decisions
- Access links
Consider the client agreement, legal and privacy obligations, recovery needs, insurance, subscription and storage, active client relationship, product obsolescence, account deletion, and security holds.
Do not publish a universal 30-day, 90-day, seasonal, or permanent rule.
Archive does not mean delete
Archiving can remove a job from the active view, change team behavior, or revoke client access.
It does not automatically mean:
- Source files deleted
- Storage quota reduced
- Legal retention ended
- Client rights changed
Use separate labels for:
- Active
- Archived
- Deleted
- Retained under policy
- Client access revoked
The studio Asset Library and client access are different
A studio-side asset view can aggregate files across the workspace.
That does not create a client-facing cross-project library.
In Lenso:
- the studio can see current workspace creative files under its permissions;
- clients use project-specific access;
- clients do not consume paid studio seats;
- access can expire or be revoked;
- no universal permanent-access promise applies.
Do not market the Asset Library as an enterprise DAM.
Copyable file policy
- FILE POLICY
- Primary organizing axis:
- Job identifier:
- Product identifier:
- Variant identifier:
- Shot-row or asset identifier:
- FILE STATES
- Source:
- Working:
- Proof:
- Final:
- Manifest:
- FOLDER OR CATALOG RULE
- Top-level unit:
- Secondary mapping:
- Working-file collection rule:
- Proof location:
- Final location:
- Manifest location:
- NAMING
- Source-name policy:
- Proof-name policy:
- Delivery-name policy:
- Version:
- Destination:
- Locale:
- Extension:
- VERSIONING
- New-version trigger:
- Current-version marker:
- Superseded-proof policy:
- Approved-version record:
- Final-name rule:
- DELIVERY
- Files included:
- Files excluded:
- Manifest:
- Recipient:
- Release policy:
- Actual download tested:
- Access expiry or revocation:
- RETENTION
- Source review date:
- Working-file review date:
- Proof review date:
- Final-file review date:
- Manifest retention:
- Deletion owner:
- Client notice:
- Legal or security hold:
How this fits in Lenso
Lenso can keep final-file and delivery context attached to the current job.
It can provide current storage, project history, delivery names, ZIPs, manifests, and secure project-specific access under the current implementation.
Lenso is not the studio's complete source-file archive or enterprise DAM.
Use the studio's storage, backup, editing, DAM, or PIM where those remain appropriate.
Questions
What is the best folder structure?
There is no universal best structure. Choose one primary axis and preserve the other relationships through metadata, shot rows, or a manifest.
Should every filename include the channel?
Only when it prevents ambiguity in the real handoff.
Should source files be renamed?
Not necessarily. Preserve a reliable mapping.
How long should raw files be kept?
Use the current agreement and retention policy.
Is archiving the same as deleting?
No.