Upload Guidelines
Use this page as the uploader-facing contract for file requirements, metadata quality, and the split between public notes and private screening comments.
File requirements
These checks are enforced by the upload flow before the file reaches screening.
Aircraft uploads
Aircraft photos and aviation subjects where aircraft identity matters.
Required
- Airport
- Photo date
- Primary category
- Registration or aircraft model
Airport uploads
Airport overviews, terminals, towers, spotting locations and airfield context.
Required
- Airport
- Photo date
- Airport view / primary category
Metadata and airport selection
Auto-fill helps, but the uploader remains responsible for accuracy.
- Use Auto-fill first when you know the registration and/or airport code.
- Check every auto-filled field manually before submitting.
- Use the real airport catalogue when possible.
- Manual code fallback and special locations exist for edge cases, not as the default path.
- Exact dates are expected for digital photos whenever possible.
Notes and visibility
Public information and private screening context are intentionally split.
Photo note
Public. Shown with the photo. Use it for short editorial context.
Comment to screener
Private. Visible only to the screening team while relevant. Not the place to ask for editing advice.
Common rejection triggers
Passing upload validation does not guarantee acceptance during screening.
Appeals
Appeals exist for incorrect decisions, not for editing support.
Use an appeal only when you believe the rejection was incorrect. Do not use appeals to ask how to edit a file or how to make it acceptable.
The current business rule is intentionally strict: a photo gets one meaningful appeal path. If an appeal is accepted, the photo returns to screening. If it is rejected again after that, it does not enter a new appeal loop.
For a deeper explanation of what usually causes a rejection, read the quality and rejection guide.