Define the asset family
One original can generate crops, resized copies, background-removed images, and annotation previews. Assign a stable parent relationship so these files remain recognizable as related assets. Decide which versions are model inputs and which are review aids. Otherwise a delivery can inflate its apparent size by counting every derivative as an unrelated photograph with independent visual evidence.
Record meaningful transformations
Describe the operations that change pixels or geometry, including rotation, color treatment, object removal, compositing, and synthetic augmentation. Specify which are acceptable for the intended task. A simple transformation label is more useful than an unexplained edited flag. Where details are unknown, preserve that uncertainty rather than presenting a clean provenance chain that the source cannot substantiate.
Keep annotations attached correctly
Coordinates, masks, and captions may need revision after a crop or edit. State whether each annotation applies to the original or a particular derivative. Validate a rendered sample for every transformation path. Stable identifiers should survive filename changes so corrected annotations can be distributed without requiring buyers to infer which image version the author intended.
Apply relationships during evaluation
Related derivatives can cross a split boundary unless grouping is explicit. Decide how all members of an asset family are assigned and how new derivatives are added later. Request both unique-original and delivered-file counts. Fiund can review a proposed delivery structure with you, while availability and acceptable source documentation remain specific to the project and intended commercial use.
Review checklist
- Assign stable parent and derivative identifiers.
- Describe allowed transformations and unknown history.
- Bind annotations to the exact image version.
- Group asset families consistently during evaluation.