Give every image a durable identity
Use an identifier that remains stable if a folder or filename changes. Include the delivered path, file type, dimensions, and relationship to any original asset. Keep annotation references explicit rather than relying on matching name fragments. A manifest should make it possible to connect the pixels, labels, source group, and review history without manual detective work.
Define the metadata vocabulary
Document each field, its permitted values, and the meaning of an empty value. Unknown location is different from intentionally withheld location; unreviewed is different from rejected. Use separate fields where those distinctions matter. Explain whether attributes came from a source record, automated inspection, or human review so buyers can interpret them with appropriate confidence.
Keep commercial review separate
Record the reference to project-specific source and usage documentation without treating an operational status as a rights guarantee. A file passing technical checks does not establish permission for every training use. Decide which information belongs in the delivery manifest and which belongs in restricted supporting records. This allows technical handoff without overstating what has actually been reviewed.
Validate relationships at delivery
Check that every referenced file exists, every annotation points to a known image, and identifiers remain unique. Inspect counts by class and source group after rejected items are removed. Include a release identifier and change summary so later corrections can be reconciled. The best manifest is modest enough to maintain and complete enough to explain the delivered collection honestly.
Review checklist
- Use durable image identifiers and explicit references.
- Document field types and missing-value meanings.
- Separate technical review from usage documentation.
- Validate paths, counts, and relationships on release.