Photos, geotagging and the photo policy

Every photo you add to a survey goes through the same pipeline, whatever step you’re on: it’s timestamped, geotagged where possible, and fingerprinted before it’s saved — nothing about that is optional.

What it is

When you add a photo, the app resolves its true capture time (from the image’s own EXIF data if present, otherwise honestly recorded as the moment it was attached), visibly burns that timestamp into the image itself, then computes a fingerprint hash of the finished file. That hash is what anchors the photo to your record — it isn’t a cosmetic badge, it’s part of what gets checked later.

Location works the same way: a photo’s own EXIF GPS data is used first. Only when you take a picture live with the camera (never a gallery pick) and the image has no EXIF location does the app fall back to the device’s own GPS. Either way, a photo is never blocked, delayed or dropped for lack of a location — a missing geotag is recorded as honestly absent.

Separately, opening or finalising a job requires its own GPS fix confirming you’re at the property — this “GPS gate” is a different check from a photo’s own geotag, and it’s a hard requirement on any production build; there’s no way past a failed fix other than getting one.

Before you start

Where your organisation has switched on Require photos for hazards, you can’t seal a survey while any room or external finding recording a real hazard (anything other than “no visible” for that hazard) has no photo attached.

How to do it

Add a photo from any step that offers it — camera or gallery.
Check the burned-in timestamp on the thumbnail; if it looks wrong, it’s honestly reflecting what the file itself carried, not a bug.
Where a location was resolved, it shows against the photo automatically — there’s nothing to set manually.
If you try to finish a survey with a hazard finding that has no photo and your organisation requires one, you’ll see exactly which findings need a photo before you can seal — go back to each and add one, then finish again.

How it integrates

The same photo pipeline is used everywhere a photo is captured in this app — room and external findings, access attempts, and works-order after-photos — so a photo’s evidential weight is identical whichever screen it came from. The photo-policy check is re-verified server-side when you finalise, so it can never be bypassed by a client-side quirk. See The evidence register for how a photo’s fingerprint feeds into the record’s overall hash chain and how that chain is later verified.

Common problems

A photo shows as pending. It’s captured and fingerprinted on the device but hasn’t uploaded yet — it uploads automatically once you have a connection; nothing is lost.
The GPS fix won’t acquire. Check location permission is granted and you have a clear view of the sky if you’re indoors near a window; there’s a retry option, but no way to proceed without a fix on a production build.
I’m blocked from finishing because of the photo policy. Add at least one photo to every hazard finding listed in the message — this is working as designed, not a bug.