The proof photo carried the upload date, not the day taken
Proof photos that waited in the offline queue were dated by days late, and the rule that a photo must be taken at the board was not running from the main screen.
The photograph your crew takes at a board is the evidence behind an invoice. It says the flex was up, on this day, at this place. If that photograph says it was taken on Thursday when it was taken on Monday, or was taken from nowhere near the board, it is not evidence. It is a file.
Two things were wrong with the proof photos in this system. Photographs that had waited in the phone’s offline queue, because the crew had no signal at the board, were stamped with the day they reached the server, wrong by days. And the rule that a photo must be taken within 200 metres of the board was not being applied on the main path, so any capture from the home screen was allowed at any distance.
What was actually going on
The date fault was plain. The phone recorded when each shot was taken, but the server ignored that and stamped the moment it received the file. A photo taken on Monday in a dead zone and uploaded on Thursday was dated Thursday.
The distance fault was more interesting. The capture screen’s description said that if no position was supplied, the app should look it up. Nothing did. Every capture from the home screen was therefore permitted at any distance. It was one request short of working: the screen was already fetching that site for the campaign line and throwing away the coordinates.
Testing found a worse fault behind it. After a user switched boards, the old position survived, so the check measured against the wrong hoarding and refused honest work.
What we changed
The capture time is now honoured. The time, the GPS position and a place name are burned into the image itself, and the upload waits until that stamp is on. The photo carries its own date and place, which a later viewer can read without trusting any database.
The 200 metre check now blocks a capture when the phone knows where it is, and flags it when it does not. It waits for the location lookup rather than allowing the photo through, because allowing the photo through is the same “absent means allowed” mistake one layer up. Spoofed-location flags, with distance limits set per organisation and per site, appear in the office portal for a reviewer.
The check is deliberately off while developing on a laptop, since there is nobody at a board. To stop anyone reporting it as tested while it was switched off, the capture screen says plainly that the check is off, in the place where a refusal would appear.
What it did not fix
A stamp burned into an image is made by the phone. It makes a mistake obvious and makes honest mistakes rare. It is not proof against someone determined to fake it, and the system flags suspected spoofing for a person to review. It does not claim to prevent it.
Photos captured before the fix keep whatever date they were given, and the log does not record any attempt to correct history.
The pattern, for anyone who bills on proof
Ask what date and place your proof carries, and who put it there. If the answer is “the server, when it arrived”, that is the date the signal came back, not the date of the work.
Then ask what happens when the data needed for a rule is missing. A rule that allows the action when it cannot check has not been switched on.
Where this ends up
Proof that carries its own date and place is how AdBoard treats a photograph behind an invoice, in the system it runs for Gold Sign Media, an outdoor media operator. The crew’s phone stamps it, and the server checks it against the board.