Delivery Manifest Template
Give the recipient a verifiable file list and reopen the package independently.
Deliver files, not temporary links
Agree file type, channels, sample rate, bit depth, duration range and naming with the recipient. Confirm loudness for the intended use; a broadcast recommendation is not a universal platform target. List native MIDI, stems or projects only when they are actually available.
| File | Contents and version | Timing | Specification | State |
|---|---|---|---|---|
| cue_v05_mix.wav | Approved stereo mix | Picture origin and complete tail | Agreed, measured properties | Opened and auditioned |
| cue_v05_stems/ | Available stems | Common origin | Channels and formats per file | Completeness checked |
| notes.txt | Revisions, sources and missing items | Corresponds to v05 | Readable text | Recipient can read it |
This is a fictional teaching package, not audio generated by this site. A checksum can help confirm transfer integrity where needed; a matching checksum does not establish musical quality or rights.
A simple folder structure
project_delivery/
mix/
stems/
notes.txt
file-list.txtKeep the agreed delivery version here and store intermediate work separately. State missing material explicitly, such as “no original project; stems were separated from a mix.” An empty folder is not a deliverable.
Reopen before sending
Copy the package to a fresh location and open each listed item. Check starts, endings, channel layout and names. For a project file, check external samples and plug-in dependencies. Archive the approved specification with the final version so a later revision does not accidentally start from a listening copy.