Digital Asset Masters and Derivatives: What Must You Preserve?
Decide what to preserve, what to recreate, and how to keep the history connected
Published
A product photograph arrives as a camera original. A designer corrects its colour, removes a background, and approves a production file. The website receives a smaller JPEG and a thumbnail. Which files should the team preserve, and which copies can it safely recreate?
The answer depends on what each file contributes. The original preserves the capture; the approved edit preserves human work; the web copies serve a delivery channel. A derivative is a transformed copy of a source file. Some derivatives can be recreated easily, while others contain decisions or evidence worth preserving.
1. Give each file an explicit role
Define roles for each asset class. A source original, preservation copy, and approved production master may be different files. File size, format, and a name ending in “final” cannot establish which one is authoritative for a particular use.
| File role | Preservation decision |
|---|---|
| Source original | Preserve the received photograph, recording, or project inputs when they are irreplaceable or required by policy. |
| Preservation copy | Keep a copy selected for long-term use, with its relationship to the source and any conversion history. |
| Approved production master | Preserve accepted retouching, editing, layout, and other human work, including dependencies needed for future changes. |
| Web image, thumbnail, or streaming rendition | Consider regeneration after testing the retained source, processing recipe, output quality, and delivery time. |
| Transcript, captions, or AI description | Distinguish generated drafts from reviewed versions. Preserve corrections and accessibility work that a new model run would lose. |
| Published copy | Retain the exact released file when policy or evidence needs require showing what was published. |
A file can serve more than one role. Record its role, approval state, owner, and retention rule explicitly, so a cleanup job can make a defensible decision.
Also distinguish a version from a rendition. A correction to the production file creates a new version of that file. A web JPEG or caption file has a separate purpose and should have its own identity, version history, and relationship to the source. Keep both the source and the output available while their roles are still needed.
2. Connect each output to its exact sources
Lineage means the history connecting an output to the inputs and work that produced it. Record source identifiers and versions, the transformation performed, the responsible person or service, completion time, and output integrity information. A compiled video may depend on several clips, an audio track, graphics, and captions.
A link to “the latest master” loses that history when the master changes. Keep the source version used for the existing output, then record the new source version when a replacement is produced. Also record where each approved copy was published and which version it replaced.
3. Prove that regeneration is practical
A rendition profile is a saved processing recipe: dimensions, crop rules, colour profile, codec, bitrate, caption format, or watermark settings. Version the recipe and record the tools and dependencies it needs. Fonts, linked artwork, plugins, and software versions can matter as much as the source file.
Test recreation from retained inputs before deleting an output. Check quality, captions, processing cost, and time to deliver. Decide whether acceptable equivalence or identical bytes are required. Encoder changes and AI services can produce different results even from the same source.
Keep human corrections as separate, approved work. For AI outputs, record the service or model, available version information, language, source version, generation time, and review status. Record any limits on reproducing a provider’s model run, and preserve accepted captions and descriptions when rerunning the service cannot reproduce them.
4. Release a complete, reviewed set
Define the files that belong together for each release: a video and its approved captions, or a product image and its required credit. Identify their exact versions, intended audience, rights evidence, and approval decision. A successful conversion establishes that processing completed; release approval establishes that the result is suitable for its intended use. Define which routine renditions can use an approved profile and automated checks, and which changes need human review.
Keep new outputs as candidates until the required checks pass. Track processing jobs and failures so retries do not create duplicate releases, and a late result from an older source cannot replace a newer approved copy. Before updating a channel, confirm the required files are present and still match the selected release.
5. Check both integrity and future usability
A checksum lets you compare a file with a previously recorded value to detect changed bytes. The preservation term for this check is fixity. Protect the baseline, record the algorithm and results, and investigate mismatches before changing the baseline or replacing a copy. Matching checksums do not establish ownership, approval, or that the file can still be opened.
For Amazon S3, use an appropriate explicit checksum and understand whether it covers the whole object or combines part checksums. An ETag is not a universal whole-file MD5 checksum; multipart uploads and SSE-KMS encryption are among the cases where that assumption fails. See S3’s integrity guidance.
Test that retained formats can still be rendered and used with their accessibility files and external dependencies. The Library of Congress Recommended Formats Statement is a useful reference for preservation formats. Choose formats your organisation can support, and retain conversion history when migrating them.
6. Carry rights and privacy controls through publication
Record the owner, licence, permitted channels and territories, attribution, consent, embargo, and expiry where applicable. Check those conditions when publishing or delivering a copy. Metadata describes permission; the application and delivery systems must enforce it.
Review embedded location, device, author, and personal information before release. A public image may need sanitised metadata while the restricted original keeps its context. When rights expire, track withdrawal from the website, portal, or delivery cache as well as changes in the repository.
7. Set storage rules around recovery and retention
Preserve irreplaceable sources and approved work with appropriate copies, integrity checks, access controls, and recovery procedures. Test restoring both files and their metadata, including the keys and software needed to use them.
Reproducible copies may suit cheaper storage or on-demand generation. Account for source retrieval delays, processing capacity, rights checks, and delivery targets. Apply retention requirements and holds before deletion. The ability to generate a similar file does not remove a requirement to retain the actual published record.
Check dependencies before deleting a source version or applying automatic storage-deletion rules. A retained derivative may still need that older source for regeneration. Assign an owner to resolve missing sources, failed conversions, missing captions, and incomplete withdrawals; a relationship record helps identify the problem, but the cleanup process must enforce the decision.
Walk one product photograph through the decision
Keep the capture and the approved edit
Retain the camera original and the approved retouched production file, with the editable project and dependencies needed for later changes. Connect the approval to that specific production version.
Create and review the channel copies
Generate a web JPEG and thumbnail from the approved version using a recorded profile. Check the crop, colour, metadata, required credit, and permitted use. Record approval for those exact outputs and the intended website.
Publish and record the outcome
Send the approved files to the website and record the destination’s result, output identifiers, source version, recipe, and approval. If publication fails, leave it pending for recovery. Retain the exact published JPEG for the period required by the organisation’s release policy.
Test a cleanup candidate
If the thumbnail has no separate retention requirement, recreate it from the retained production version and profile. Confirm acceptable output and delivery time before treating it as disposable. A later production edit creates a new generation with its own history.
Before calling a copy disposable
- Its role, owner, approval state, retention rule, and any hold are known.
- The exact sources, versions, processing recipe, and dependencies remain available.
- Human edits, release approvals, and required publication evidence are preserved elsewhere.
- Recreation has passed quality, accessibility, cost, and delivery checks.
- Rights and access controls are checked for the regenerated copy.
- Recovery tests cover files, metadata, relationships, and processing dependencies.
Preserve the work that cannot be recreated
Keep irreplaceable originals, approved human edits, and required release evidence connected to their derivative copies. Treat an output as disposable only after its retained sources, processing recipe, rights, and tested regeneration path meet the needs of the business.