Production-file handover

What this worksheet records

A production-file handover is a version manifest, not merely a folder name. List every file with its exact version, fingerprint and expected specification. Keep visual review, technical report and provider acceptance references separate so the recipient can understand the release gates. An absent gate remains an open condition. Do not claim a file is ready solely because it can be opened, appears in a download or has a calculated byte fingerprint.

Complete and review it

Check the manifest against the actual selected files before sending the package through an authorised route. Remove obsolete files that could be confused with the current production input, while preserving them in permitted history. Ask the named recipient to acknowledge the exact package and any outstanding condition. If a source changes after handover, issue a versioned replacement and explain which prior instruction it supersedes. Never assume a shared folder update automatically reaches or binds the provider doing the work.

Field definitions

• handover_id: A stable identifier for this handover, used to connect related rows without merging unrelated records.
• job_id: A stable identifier for this job, used to connect related rows without merging unrelated records.
• filename: The actual source filename, tied to its exact version; avoid adding private filesystem locations.
• artwork_version: The exact artwork version used for this row; retain earlier versions and revisit affected decisions after a change.
• sha256: The byte fingerprint of the exact file when available; it identifies bytes and performs no production approval.
• file_size_bytes: The byte size of the received or handed-over file; this is metadata rather than suitability evidence.
• specification_revision: The exact specification revision used for this row; retain earlier versions and revisit affected decisions after a change.
• template_revision: The exact template revision used for this row; retain earlier versions and revisit affected decisions after a change.
• visual_approval_reference: The actual attributable source for visual approval reference; a reference is not evidence that a decision was authenticated or its content verified.
• technical_report_reference: The actual attributable source for technical report reference; a reference is not evidence that a decision was authenticated or its content verified.
• provider_acceptance_reference: The actual attributable source for provider acceptance reference; a reference is not evidence that a decision was authenticated or its content verified.
• recipient_legal_entity: The actual party for recipient legal entity, with its responsibility or rights source identified; do not substitute the platform brand.
• sent_date: The actual sent date, with date format or period meaning explicit; distinguish requested, planned, confirmed and observed values.
• receipt_reference: The actual attributable source for receipt reference; a reference is not evidence that a decision was authenticated or its content verified.
• open_condition: The specific unanswered open condition that needs an owned response before the relevant next gate can close.

Prepare a deliberate export

A production package can contain confidential artwork and review metadata. Share only the accepted recipient's scope using an authorised file route. The CSV itself contains metadata and neither transmits the files nor authenticates a release.

Take it to the next job

• Match every handed-over file to its fingerprint and specification.
• Keep distinct release gates and unresolved conditions visible.
• Obtain an attributable receipt of the exact package.