What makes a field photo verifiable
A photo from the field makes three claims at once: this place, this moment, this scene. Each claim can be tested, and each test has limits. This guide sets out the checks we run, what a phone can and can't prove today, and the questions worth asking any field-data vendor.
1. The place
Every location fix from a phone comes with an accuracy radius. A GPS fix outdoors is usually good to a few tens of metres; a fix from Wi-Fi or cell towers can be far rougher. A fair check measures the distance from the site and gives the worker the benefit of that radius.
That generosity needs a ceiling. Android lets a person share only an "approximate" location, which blurs the fix to a scale of kilometres. Allow for the full radius of a fix that rough and a photo taken in the next suburb lands inside the fence. So a rough or approximate fix should fail on precision alone, with a message that tells the worker to switch on precise location.
Android also reports when a fix came from a mock-location app. Treat that flag as a hard stop.
2. The moment
A capture time on its own proves little, because an old photo can be resubmitted. Two checks close the gap. The first is freshness: the photo must be taken shortly before it is sent. The second is a one-time code, issued when the worker starts the task and bound to the capture, so a photo taken before the task existed can't carry it.
3. A new photo
Hash every image on arrival and compare it with every image already received. A repeat is a hard stop, whoever sends it. This is the cheapest check on the list and it catches one of the oldest tricks: the same picture sent from several accounts.
4. A file that agrees with itself
Camera files often carry their own GPS position and timestamp in EXIF metadata. When those fields exist and contradict the fix the phone reported, something is wrong. When they are missing, say nothing: many apps strip metadata as a privacy measure, and a check that punishes an honest stripped file teaches workers nothing useful.
5. A trail that makes sense
A single fix can be faked. A sequence is harder. If a worker's last two positions imply a speed no vehicle could reach, or the trail jumps in ways real movement never does, flag it for a person to look at.
6. The thing that was asked for
A photo can be taken in the right place and still show the wrong shelf. A vision model can compare the image with the task's instructions and also look for signs of a generated or edited image. Let it reject only when it is confident. A low-confidence result should go to a human reviewer, along with the model's reasons.
What a phone can't prove yet
Two signals sound decisive and deserve care. Device attestation (Google Play Integrity on Android) can show that a request came from a real, unmodified copy of an app on a genuine device. Content credentials (the C2PA standard) can carry a signed record of how an image was made. Both are only as good as the server-side check behind them. A claim the phone sends about itself, with nothing verified on the server, should count for zero.
We record both today and give them no weight in the decision until our server verifies them. Treat a vendor who scores self-reported signals as proof with suspicion.
Questions to ask a field-data vendor
- How rough can a location fix be and still count as being at the site?
- What happens to a photo sent from an approximate or mock location?
- How do you stop a photo taken before the task from being submitted?
- Do you check every image against every earlier one?
- Which of your signals are verified on your servers, and which are reported by the phone?
- Can I see, for each result, which checks passed and why?
How HumanRelay applies this
Each check above is a separate, labelled signal in our evidence engine, with a plain reason attached, so a reviewer can see why a photo was accepted, rejected or sent for review. Developers and teams who want to discuss a pilot can email hello@humanrelay.ai, and the about page explains the rest of the product.