A creator needs a new crop.

The post is easy to find.

The source is somewhere behind the last export, the last download, and the folder that once held them all together.

That is how a published file becomes a library by accident.

It has a filename.

It has a cloud location.

It may even be the version that reached people.

None of that makes it the source.

A library begins with a harder distinction than most folders bother with.

Ingest turns a file into a record.

Cataloguing turns that record into an asset.

The difference sounds procedural until the day you need the original of something.

At ingest, a system can fingerprint the file so that later it can prove nothing has changed, and refuse an exact duplicate on the way in.

A looser fingerprint does a different job. It flags the near duplicate: the same picture at another size, or a later crop that may well be deliberate.

The system doesn’t need to call those files the same thing.

It needs to know how they relate.

A filename can announce a derivative’s purpose. product-042_web-1200.jpg clearly marks a web output.

It doesn’t make that output a new upstream source.

The master asset ID carries the relationship a filename only hints at.

So keep the source with its record.

And keep its asset ID attached to everything made from it.

A derivative isn’t a lesser asset. It is an asset with a narrower job.

A web export, a print-ready file, a small thumbnail, a square social crop: each is useful precisely because it was made for one destination.

Store each as its own file. Link each one back to the master rather than letting it acquire an independent life.

That link is what makes a later search possible.

The cloud folder can hold all four.

Only the asset ID says why they belong together.

Then hold the line on the master itself.

It is immutable. Not overwritten, not cropped in place, not colour-corrected and re-saved on top of itself.

A retouch or a caption fix makes a new version, and the master stays.

A new size, format, crop, or colour profile makes a derivative.

Those are different kinds of change.

One changes the content. The other changes how unchanged content gets delivered.

Rendition presets keep that distinction practical.

A system can produce the approved formats, dimensions, and colour profiles by itself, rather than making every new request invent a new file.

It can build the whole set at ingest. Or it can wait until someone asks for the thumbnail, then generate it and keep it.

Video works the same way. A high-quality master produces light proxies for browsing and for the web.

The proxy makes the work easy to look at.

The master makes the final output possible.

That difference gets sharper the moment a source has already been compressed.

A published copy can look perfectly acceptable for its first purpose and still be a poor starting point for its second.

Which is not an argument for always keeping the largest file you can.

Past a point, a bigger delivery file buys size rather than picture, and nobody can tell the two apart in a blind comparison.

Preservation isn’t maximalism.

It is keeping one version whose job is to still be there.

So keep the high-quality or lossless source.

Use the output setting the destination actually needs.

And make the next crop from the source, not from the post.

Find it by the asset record and the master asset ID, rather than by whichever filename happened to survive the last export.

Let a status field — draft, approved, superseded — explain a version.

Let a suffix explain a delivery purpose.

The file you published did its work.

A published file is an output. A master is an option you keep.