The Difference Between a Draft and a Deliverable

Teams often use “final” to mean several incompatible things: the newest creative version, the version ready for comments, the version approved in principle, or the file ready to send. That ambiguity is costly because each state asks people to behave differently. A reviewer may keep changing a file intended for export; a producer may send a review copy that lacks required components.

The clearest remedy is to use draft and deliverable as operational states, not compliments. A draft is material that remains open to change. A deliverable is a defined package that has met its agreed conditions. A piece can be creatively strong and still not be a deliverable.

Give drafts permission to be unfinished

Label a draft by its purpose: story review, pacing review, sound exploration, technical proof, or internal read-through. The label tells recipients what feedback is useful and what has not yet been solved. A draft can contain temporary audio, incomplete captions, alternative text, or an unresolved opening, provided those conditions are visible.

Ask a limited question with each draft. In an imagined unpublished short, a v03 story draft might ask whether the central choice is legible before any polishing occurs. It should not also be treated as proof that the export, captions, and delivery metadata are ready. Separating those jobs lets reviewers focus their attention.

Keep drafts in an area where comments and experimentation are expected. Preserve prior versions when a decision depends on comparison, but do not make a reviewer sort through every exploratory file. One current review target and a short change note are usually enough.

Define a deliverable by its contract

A deliverable begins with a contract, even a small internal one. Name the intended format, duration or layout requirement, language assets, source version, and the checks that must pass. If the work will be handed to another team later, include the package structure and any documentation necessary to use it safely.

Use an acceptance list that distinguishes creative approval from technical completion. Creative approval might confirm the edit and sound intent. Technical completion might confirm file type, dimensions, captions, naming, and that the package opens as expected. Neither category should silently stand in for the other.

When an item fails, return the asset to a specific state rather than calling the whole project “not final.” For example, an approved edit with a caption issue can be approved_pending_caption_qc. That state is more truthful than a generic failure and gives the correct owner a precise next action.

Protect the boundary between states

Store delivery candidates separately from working exports and make their status visible in the filename or release record. Restrict changes to a marked deliverable: a late change should create a new version, identify its reason, and trigger only the checks affected by that change. Silent replacement makes later verification impossible.

Do not turn the distinction into ceremony. A short internal piece may have a two-line delivery contract; a more complex package may need a detailed checklist. The amount of documentation should match the handoff risk, not an abstract idea of professionalism.

What matters is that recipients can tell whether they should comment, decide, verify, or distribute. Drafts invite the first two. Deliverables require evidence for the last two. Making that boundary explicit reduces accidental releases and makes creative review safer.