footage_offload_workflow v1.0.0

name: footage_offload_workflow description: Get shoot footage off camera cards and into safe storage without losing a shot: two verified copies on separate devices before any card is formatted, checksum verification on every file, shoot day folder and roll naming, a card state system, an offload log, and an end of day reconciliation that catches a missing card while a reshoot is still possible. Ships a tested checksum copy script with a clearance gate. Use when offloading camera or sound cards on a shoot, setting up a DIT or data wrangling station, training a crew on media handling, or reviewing why footage was lost or corrupted after a shoot day.

Footage Offload Workflow

Purpose

A camera card is the only copy of the shoot until the offload proves otherwise. This skill runs the offload as a protocol, not a copy: every card gets two checksum verified copies on separate physical devices, a manifest, a log line, and a visible state, and no card is formatted until all of that is true. A plain Finder or Explorer drag is not a verified copy, because those tools write the bytes and never read them back to compare.

The protocol scales from a one person shoot with a laptop and two portable drives to a multi camera day with a dedicated DIT. The clearance gate and the end of day check stay the same at every size.

Workflow

1. Set up before the first card fills. Build the day folder on every destination: project, then YYYY-MM-DD_DayNN, then one subfolder per camera and one for sound, plus a _LOGS folder. Pick one hash algorithm for the whole production (guidance in references/checksums-and-tools.md) and write it at the top of the log. Put out the card state system: red tape or a red bin for unverified cards, green for cleared cards. Full layout and state rules are in references/protocol.md.
2. Take the card in and name the roll. A card arrives in its case from the camera assistant, who states the clip count from the camera. Assign the next roll number for that camera (A001, A002, B001, sound rolls S001). The roll number, never the card's own folder names alone, is how the roll is tracked for the rest of the production.
3. Copy with verification to two destinations at once. Run python3 scripts/offload.py copy --source <card mount> --dest <drive A roll folder> --dest <drive B roll folder> --roll A001 --log <day _LOGS folder>/offload_log.csv from this skill folder. The script copies every file with its full card structure, hashes the source as it reads, reads each copy back and re-hashes it, writes a manifest.csv into each destination roll folder, and appends the log line. On a production that owns Silverstack, OffShoot, or ShotPut Pro, use that tool with checksum verification and MHL output on, to the same two destinations and the same roll folders. Never copy to one drive now and the second drive later from the first copy: the second copy must also come from the card, or it inherits any error in the first.
4. Read the clearance result, not the progress bar. The card is cleared only when file count and total bytes match the card on both destinations, every file hash matches, the destinations are separate devices, and the script prints CLEARANCE: YES. The script refuses clearance for a single destination and for two folders on one device, because two folders on one drive are not two copies. Any failure keeps the card unverified: swap the reader or cable first, delete the partial roll folder deliberately, note the redo in the log, and copy the whole roll again. Never patch a failed roll file by file.
5. Spot check real clips. Play one clip from the start of the roll, one from the middle, and one from the end, with sound on for rolls carrying production audio. Verification proves the copy matches the card. The spot check is what catches a card that recorded bad clips faithfully.
6. Change the card state and return it. Mark the case green or move the card to the cleared bin, and hand it back to the camera assistant. Formatting happens in the camera that will shoot the card next, not on the computer: Sony and Canon both direct users to format in the camera, and a computer formatted card can be rejected or misbehave in the body. An unmarked card is treated as unverified, always.
7. Offload sound and stills the same way. Sound rolls get roll numbers, two verified copies, manifests, and log lines. A lost sound roll is as final as a lost picture roll.
8. Run the end of day reconciliation before anyone leaves. Count cards shot per camera from the camera reports, count roll folders per camera on destination one, count log lines. All three counts must agree. Read every clearance value: any NO means a card still holds the only copy of something, and it gets found tonight. Confirm the two destination devices travel and sleep in different places, and name who carries each. Detail in references/protocol.md.
9. Close the 3-2-1 gap on schedule. Two verified copies is the on set gate. The production then makes the third copy on a different media type or in cloud storage within the delivery window it agreed, reaching the full 3-2-1 shape: three copies, two media types, one offsite. State the deadline and the owner when the day wraps, not later.

Output Contract

Every offload produces:

• One roll folder per card on each destination, holding the full untouched card structure plus manifest.csv
• An offload log with one line per roll: timestamp, roll, source, destinations, file count, total bytes, hash algorithm, verified file count, and clearance YES or NO
• A card state that matches the log: no card marked cleared without a YES line, no card formatted without being marked cleared first
• An end of day reconciliation result: cards shot, roll folders, and log lines counted and agreed, plus where each destination device sleeps and who carries it
• A named plan for the third copy: destination, owner, and deadline

Operating Rules

• Two verified copies on separate devices before formatting is the whole rule. Speed pressure, a waiting director, and a nearly full card bag are not exceptions. The card is the exception handler: while it stays unformatted, almost every offload mistake is recoverable.
• Copy the entire card, structure included, and rename nothing at offload. Some formats spread one clip across several files, and a partial or renamed copy can break a clip that played fine in the camera.
• One hash algorithm per production, named in the log. Netflix production guidance accepts MD5 or xxHash64be for original camera files and asks for one MHL manifest per roll. When a client asks for ASC MHL by name, use a tool that writes it (Silverstack, OffShoot, ShotPut Pro) instead of the bundled CSV manifest.
• A destination that fills up or a copy that loses power voids the whole roll, not just the unfinished file. Redo the roll whole, log the redo, and never let a split roll read as complete.
• Cards that hash inconsistently across two reads get copied first, before other work, and retired from the shoot. Readers and cables fail more often than cards, so swap those first when a single roll fails.
• Re-verify any roll against its manifest when a drive returns from travel, before archive drives are wiped, or when a clip misbehaves in the edit: python3 scripts/offload.py verify --folder <roll folder> --manifest <roll folder>/manifest.csv. Restore a mismatched file from the other verified destination, then re-verify the whole roll.
• The bundled script never modifies the source and refuses to overwrite an existing destination file. Those refusals are deliberate. Work around them by deleting a bad destination roll folder openly and logging the redo, never by weakening the check.
• One full two camera day is worked end to end in references/worked-example.md, including a midday verification failure and its redo. Bulk detail lives in references/: protocol.md (card states, naming, the clearance gate, failure handling), checksums-and-tools.md (hash choice, ASC MHL, source verification, tool comparison), worked-example.md, and offload-log-template.csv. The script in scripts/ was tested before shipping: same device destinations and single destination copies both refuse clearance, and a one byte change to a copied file fails verification.