A photo stamp is pixels. That is its whole value: pixels survive forwarding, screenshotting, and being dropped into a text message, where metadata does not. If a technician took a photo at 9:14, a stamp that says 09:14 travels with the picture to everyone who ever sees it, and nobody can quietly strip it out.
So the obvious next move is to do the same with the location — and we don't. Timemark's whole product is a photo caption that carries GPS and a map; CompanyCam's can be set to include the address and coordinates. When two products in the same market do this, "we never do that" needs a better defence than "privacy".
The evidence argument for burning it in is real
A coordinate in a database column can be changed by anyone with database access. A coordinate in the pixels cannot be, not easily. For a disputed claim, that is stronger evidence — and evidence strength is what this product sells. We could not honestly wave that away.
The harm is real too, but narrower than "forwarding"
The original reasoning framed the risk as the customer forwarding the report. That is weak. The insurer processing the claim, the GC running the site and the property manager all already know the address. Repeating it in burned pixels leaks nothing to them.
The harm is the photo being separated from the report. Posted to Facebook as marketing. Sent to a supplier for a warranty question. Dropped into a trade group for advice on a fitting. Then a residential customer's home address is published, by the contractor, attached to a picture of the inside of their house. Commercial sites, no real issue. Domestic, a different story — and domestic is most of plumbing and HVAC.
So it's a default, not a prohibition
Coordinates go in the copy the contractor keeps, and never in the copy that leaves.
Concretely:
| Surface | Burned into the pixels | Why |
|---|---|---|
| Capture, on the device | time only | one set of pixels, both audiences share it |
| Your internal PDF | time, address and coordinates | the contractor's own evidence copy |
| Customer PDF | time only | it is the copy that gets forwarded |
| Share link page | time only | the URL is the authorisation; assume it travels |
| Photo ZIP | time only | it leaves with the report |
The location is always recorded on the report — it appears as text on your copy, alongside the address, and it is what the office searches by. What changes per audience is only whether it is also in the pixels.
Why the capture stamp can't be changed by a setting
This is the part we're most attached to. The function that draws the stamp on the device has no input a latitude or longitude could arrive through. Not a flag defaulting to off — no parameter at all. That makes "burn the location at capture" impossible by construction rather than by discipline, and construction is the only kind of guarantee that survives somebody being in a hurry.
The internal PDF's overlay happens at render time, as a second derivative of the stored photo. The stored photo keeps exactly one stamp: the time.
What we also record, so you know why a coordinate is missing
A missing fix never blocks a photo. But "no GPS" used to look identical whether the technician had denied the permission, had location switched off, or was simply in a basement. All three looked like a bug in our own app. So the record now carries a status — denied, off, or none — for exactly that reason. It's a support diagnostic, not evidence: the phone describing its own state.