
This worksheet sets a simple custody process for finished versions. Use it alongside your existing file system rather than inventing a complicated new naming convention. It covers the status of the asset, not the full checklist for uploading it to a website or social channel.
Give each state a clear meaning
Start with a few states the team can use consistently. For example: working, ready for review, changes requested, approved for specified use, and superseded. Define who can move an item between them. A reviewer saying “looks good” may not be the person authorised to approve public use.
Keep approval specific. Identify the exact film, associated caption or transcript files, intended uses and any restrictions. Avoid relying on the latest email in a long chain when the email does not identify what was watched.
An approval state should not suggest that every possible future use is cleared. The release record needs to travel with the file.
Choose one authoritative register
Use a register in a system the publisher can access. Its purpose is to answer: which asset should I use, where is it and what is it approved for? It does not need to duplicate every editing note.
Assign a release owner who maintains that record and a deputy for absences. The owner should confirm that the approved item has been correctly identified, not personally assume every specialist approval. Keep references to those decisions where appropriate.
The delivery folder, review platform and register may be different systems. Write down which is authoritative for release status so that a date sort or attractive preview does not become the deciding rule.
Make replacements deliberate
When a file changes after approval, decide whether the change needs renewed review and by whom. Do not overwrite an approved item while leaving an old approval record attached to it. Ask the supplier how versions will be distinguished and follow an agreed process.
If the publishing system can replace media behind an existing link, that convenience still requires a controlled decision. Record what changed and retest the viewer-facing result. If it cannot, identify where the new link must go. Do not assume the link behaviour of one platform applies to another.
Copy this release record
- Film/project and release owner:
- Exact video filename or asset identifier:
- Review version from which it was approved:
- Associated caption/transcript identifiers:
- Current state:
- Approval reference, authority and date:
- Approved use and restrictions:
- Authoritative delivery location:
- Publisher and receipt confirmation:
- Previous item superseded by this release:
- Destinations requiring replacement:
- Replacement checked by and date:
Record “not applicable” where a companion file is not part of the agreed delivery. Do not leave the publisher to guess whether a missing file was forgotten or never commissioned.
A fictional example: the right film, the wrong captions
An invented project team approves a revised film that corrects a product name. Its publishing folder also contains captions from the previous edit. The publisher chooses the newest video and the only caption file available, creating an inconsistent release.
The team's revised process lists the video and caption identifiers together. A release is marked ready only when the named owner has checked that the accompanying files belong to that version. This example describes a preventable mismatch, not an actual Live Images delivery.
Retire copies without losing the decision trail
Ask your information owner how superseded items should be retained. The practical aim is to keep them out of ordinary publishing choices while preserving whatever records your organisation needs. This article does not prescribe retention periods or deletion rules.
Tell people who already received a superseded version what they should stop using and where the replacement is. A private file rename will not correct a copy already downloaded by a partner.
Before closing the release, ask someone other than the editor to follow the register and locate the approved package. If they cannot distinguish it confidently, simplify the record. Then move to the publishing handover checklist for destination-specific checks. The useful outcome is a clear chain from approval to the exact asset published, not a longer filename.
Sources and editorial note
- Live Images publishing handover checklist — related existing guide covering approved files and destination checks. This release-state workflow is an original proposed method, not a software specification or retention policy.
Prepared with AI assistance for Live Images. This is original general planning guidance; the relevant owners and written production scope determine the arrangements.