Define the rejection task
A negative example is meaningful only relative to a target decision. An empty shelf, a neighboring product, and an unrelated scene challenge different behavior. List what should be rejected and why. Include visually plausible confusions instead of relying entirely on obvious unrelated pictures that may add little information about the boundary you care about.
Avoid accidental missing labels
An image described as negative may contain a tiny, occluded, or reflected target. State the inspection rule and whether uncertainty leads to exclusion, relabeling, or a review flag. For detection projects, distinguish images with no target objects from images with targets that were not annotated. Those categories should never become interchangeable through incomplete documentation.
Control shortcuts in the collection
If every positive image is a studio shot and every negative is outdoors, background can become an unintended cue. Ask for overlap in presentation conditions where appropriate. Record which attributes differ deliberately and which differ merely because of source availability. A pilot should show both easy rejection examples and cases close to the actual decision boundary.
Preserve a reviewable explanation
Include the negative category or exclusion reason in the manifest rather than only a binary flag. That allows later analysis of which rejection cases remain weak. Revisit the negative set when target classes change. A previously excluded category can become a valid positive under a revised task, so keep original source identifiers and taxonomy versions attached.
Review checklist
- Name the behavior each negative group tests.
- Inspect for hidden or tiny positive instances.
- Match presentation conditions where appropriate.
- Keep rejection reasons and taxonomy versions.