Delivery is not the end of the asset.

The after-delivery question is usually answered as storage

Ask what to do with visual work after delivery, and the published answers converge on retention. Keep the files for two years, or five, or forever. Keep them on a second drive. Keep the selects, delete the rejects. The advice is reasonable, and it answers only one question: where the files will physically be.

That is a storage answer to a structure question. Whether the files exist is rarely the problem. Whether anyone can still read what was decided about them is.

A backup makes the difference visible. A good backup can restore every file from a project years later, byte for byte. It cannot restore which of those files the client approved, which version went to print, or what the licensing allowed. The files were protected. The answers were never stored anywhere a backup could reach.

What the work carries while the project runs

During an active project, an image is surrounded by information. Feedback refers to it. A selection includes it or does not. An approval names it. The delivered version is a specific file, chosen over the alternatives for reasons that were visible at the time.

While the project runs, this context is maintained because the work depends on it. Everyone involved knows which version is current and what the client confirmed. The project is not just producing images. It is producing decisions about images.

Delivery is the moment that maintenance stops. The files move into a folder, a drive, an archive. The decisions stay behind – in the tools, threads, and memory of a project that is now closed.

Delivered work comes back

The after-delivery period would not matter if delivered work stayed delivered. It rarely does. A client asks for a file again a year later, or asks which version they are licensed to use. A later campaign wants to reuse an image from an earlier one. A follow-up shoot has to match what was delivered before. A new team member needs to know what was approved long before they arrived.

Each of these return visits needs more than the pixels. It needs the decisions: which file was final, what it was approved for, what was sent and when. If that record ended at delivery, every return visit becomes reconstruction – searching old threads, comparing files, asking whoever might remember.

Usage questions raise the cost further. An image delivered for one campaign resurfaces in another context, and someone has to establish whether that use was ever agreed. When the answer lives in a closed project's correspondence, the safe response is to ask the client again or to not use the image at all. Both cost something the original project had already paid for: a clear answer.

Access after delivery is improvised

The same break shows up in access. During the project, sharing is deliberate: the right people see the right work at the right stage. After delivery, access becomes improvised. A link shared once is forgotten and stays open. A request for files is answered by re-sending them, creating one more copy in one more place. The person who archived the project becomes the only route to it.

Delivered is not the same as accessible. A file that exists on a drive but cannot be retrieved with its context is preserved, not available.

Delivery is a stage, not an ending

The distinction worth drawing is this: delivery closes a project, and it does not have to close the record. The standard is continuity – what was decided during the project stays readable after it, and access stays defined instead of improvised.

This is a structural choice, not an archiving habit. It depends on where the work lived during the project. When review, approval, and delivery happen in the same system, the record they produce persists in that system. When they happen across separate tools, the record fragments at the moment the project closes, and no retention policy reassembles it.

moodcase is built on that continuity. Decisions are recorded on the work, delivery runs through defined links and access, and the record remains after the project ends. The platform supports project-based work and continued asset handling in one system, so closing a project does not mean losing what it established.