How do you prove a client received their photos?

The practical answer is an access log: a dated record that the gallery was opened, by whom, and what was downloaded. It is stronger than an email receipt, weaker than a written acknowledgement from the client, and for almost every dispute it is enough.

What each kind of evidence is worth

"I sent it" - the email in your sent folder. Proves you sent something. Says nothing about whether it arrived, and spam filtering means it genuinely often does not.

Email open tracking. Weak and getting weaker. Image-proxy services and privacy features load tracking pixels on the recipient's behalf, so an "opened" flag may mean nothing at all, and a missing one may mean the client read it carefully with images off.

A gallery access log. Substantially better, because it records an action the client took rather than one you took: the link was opened, at this time, from this session, and these files were downloaded. Downloads are the strongest signal in the set - a downloaded file is hard to argue was never received.

A written acknowledgement from the client. The strongest, and almost nobody asks for one, because requiring a client to confirm receipt in writing reads as distrust at the exact moment you want the opposite.

Where logs get weak

A log is only worth what its integrity is worth. A row in a database that anyone with access can edit proves very little in a dispute, because the other side's obvious question is whether it was written when it says it was.

Two properties raise it:

• Append-only with chained hashes. Each entry includes a hash of the one before it, so changing an old row breaks every row after it. That makes tampering *detectable* - which is not the same as impossible, and anyone describing it as impossible is overselling.
• An external time anchor. A hash sent to an independent timestamp authority, which returns a token countersigned with its own key, pins the record's state to a moment a third party attests to. That is what stops the whole chain being rebuilt after the fact.

What to do in practice

• Deliver through something that logs access, rather than a transfer link that does not.
• Keep the delivery message - the log and the message together are much stronger than either alone.
• Note the download, not just the view. It is the fact that carries.
• Write the delivery terms into the contract, including what counts as delivered. Most disputes are about the definition, not the facts.

How Encore does it

Every view, favourite and download is written to a per-studio, append-only chain in which each event carries the hash of the one before it, so an altered or removed row is detectable rather than silent. The chain head is periodically sent to an RFC 3161 timestamp authority, which returns a token it signs - so a third party attests to the state of the record at that moment.

Encore describes this as tamper-evident, not as signed and not as tamper-proof: the events themselves are hash-chained, and the only signature involved is the timestamp authority's own. The trail exports, so it is usable somewhere Encore is not.