Delivery Specs

What this is about

Broadcasters and larger platforms publish documents running to dozens of pages: container and codec, loudness targets, black at the head and tail, subtitle formats, file naming, sometimes a specific structure for audio tracks. None of it is negotiable at the point of handover, and a rejected file often means waiting for the next available slot. The practical move is to read the spec at the start of the project, not at the end, because several requirements — loudness, subtitles, versions — change how the work is scheduled.

A term only helps when everyone on set means the same thing by it — so what follows is how it is used, not a dictionary definition.

What runs differently here

In planning terms, that means:

• Read the specification at the start; loudness, subtitles and versions all change the schedule
• Loudness targets are measured, not estimated — a mix judged by ear will fail the check
• Follow the file naming convention exactly; automated ingest rejects anything that deviates

With TillyGen

Deliverables and their requirements live in the TillyGen project, so the spec is present during planning rather than being looked up the week of delivery.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.