Dbusiness
Digital asset delivery
The handoff of a finished creative file, a master, a photo set, a cut, to the party who will use it, with a check that they received the bytes you intended.
It is a file transfer with a package and an acceptance test. It is not the editing session that produced the file, and it is not a shared work folder.
The package is the part amateurs skip. A delivery names the files, the codec or format, the byte size, and a checksum. A 48 GB camera master and a 200 MB review proxy are different deliveries even when they depict the same scene. Sending the proxy and calling it the master is a labeling error, not a transfer error. The link, the portal, or the disk is only the channel.
A studio finishes `spot-final-prores.mov`, 22.4 GB, SHA-256 published in the same mail as a six-hour link. The client downloads 22.4 GB. Their hash matches. Delivery succeeded. A second client downloads 22.1 GB, the player opens a truncated file, and they approve the wrong duration. Without the hash, that approval stands. With the hash, the studio resends before the note goes out. Zipping four thousand stills changes the test: one archive hash covers the set, and a failed unzip means the whole set is suspect. Per-file hashes cost more to compute and tell you which frame set broke.
Asset delivery is not digital rights management. A delivered file can be copied. Expiry of the link does not expiry the download. If the contract needs a usage limit, that is a legal term on a copy the client already has. The transfer term ends when the checksum matches.
Related
Sources
- RFC 9110, HTTP Semantics
GET of a finished representation, which a delivery link triggers
- BEP 3, The BitTorrent Protocol Specification
Piece hashes as a model for checking a large delivered asset