Create a video delivery file manifest

Distinguish the archive from the delivery package

An archive can contain source recordings and work in progress. A delivery folder should contain only the items being handed over now. Sharing the complete working directory makes the recipient choose among plausible filenames without knowing which one was approved. Separate publishable assets from reference material.

The manifest should identify each file, purpose, language, version, parent video ID, approval state and receipt check. Later additions receive a new entry. Avoid silently changing the contents behind the same filename after the recipient has already reviewed or downloaded it.

Record purpose and dependencies

A compact naming rule such as project_language_purpose_version is useful, but it cannot carry every delivery condition. Use separate columns for orientation, burned-in captions and whether a file is editable source or a finished export.

Attach every sidecar subtitle file to the exact video version it was checked against. A language variant with a longer introduction may need different timing even when its translation text has not changed. Language alone is therefore not enough to establish compatibility. Record the parent video ID and the outcome of a playback check with the actual subtitle file.

Reconcile both directions before sending

First check that every manifest entry exists. Then check that every file in the package has a manifest entry. A one-way check can miss an extra review copy accidentally left in the folder. File count, size and duration provide useful secondary checks without replacing playback.

Open the video and captions through a route similar to the recipient’s workflow. If using a Descript or VEED sharing link, distinguish permission to view a project from receipt of a finished file. Establish which access is needed and how the recipient obtains the publishable export.

Example: two languages and two caption types

In a fictional package, deliver V-041-ja-v3.mp4, V-041-en-v2.mp4, one subtitle file for each language and two thumbnail images. The six manifest entries explicitly connect Japanese captions to Japanese version 3 and English captions to English version 2.

Remove V-041-ja-review.mp4 from the delivery folder. Ask the recipient to open the Japanese video with its matching captions, then repeat for English. A message saying “six files attached” is less useful than a manifest that explains what each file does and which combinations should be checked together.

Handle omissions and corrected files

Even a caption-only correction needs a clear replacement instruction: which file changes and which files remain valid. If resending the full package, distinguish it from the previous folder so the recipient does not select an old copy. For already published assets, check each destination separately.

Differentiate message delivery from successful access and from acceptance of the release version. A recipient who received the email but could not download a large file has not received the package. Keep that item open until the access problem is resolved and the correct file can be opened.

Start with a simple manifest

A CSV manifest and a shared folder are enough for many small deliveries. Before adopting another system, decide who maintains the list and who approves the package. Check export access, retention, download conditions and correction delivery alongside the editor’s subscription cost.

If delivery becomes automated, record file creation separately from successful handover. A job finishing on the sender’s computer does not prove the recipient can access the result. Acceptance requires agreement between the approved list and the actual files, plus a recipient who can identify the versions intended for publication.

• Tools and procedures for retaining video source material
• Keep Japanese and English subtitle releases aligned with the approved video
• Manage video review comments with timestamps, versions and clear approval