Client file delivery

The send step is the link, the portal drop, or the SFTP push. Delivery is done when their side has a complete file, not when your mail client says the message went.

RFC 9110 makes the gap obvious for links. You store the object. They GET it. A presigned URL, as S3 documents it, lets them GET without an account until the signature expires. If they never open it, you delivered a URL. Teams that mark the ticket closed at send time discover this on the day of the review, when the client asks for the file you "sent" yesterday.

At 11:00 a producer uploads a 3 GB cut and emails a link that expires at 19:00. The ticket moves to delivered. At 18:40 the client starts the download on a slow up-adjacent cafe link and dies at expiry with 2 GB local. The producer has a green ticket and the client has no cut. A delivery rule that waits for a completed download event, or for an SFTP size check on their server, would still be open. Push delivery is the other shape: you STOR the file to their host and compare remote size. That can finish without them acting. Pull delivery cannot.

Client file delivery is the outbound twin of customer file upload. Do not use one form for both. Outbound fails when the link window is shorter than the download. Inbound fails when the request slot rejects the size. Digital asset delivery adds the format and checksum expectations on top of this direction. A generic "file sent" status hides which of those checks ran.