The phrase "proof of presence" appears on almost every guard tour product page. It is rarely defined, and the gap between what it suggests and what it delivers only becomes visible at the worst moment: a client claims a patrol was not performed, and you open the system to prove otherwise.
What you usually find is a line that reads checkpoint 4, 03:14. That is a scan log. It is not proof, because it answers only one of the questions a dispute raises.
What a dispute actually asks
When a patrol is challenged, the challenge is almost never "was there a scan". It is one of these:
- Was it that person, or did someone else carry the device?
- Was it that time, or was the record written later?
- Was it that place, or was the tag brought to the guard room?
- Did the guard look, or just tag and walk?
- If something was found, what happened next?
A record that cannot answer all five leaves the argument to whoever is more persuasive, which in a client relationship is rarely the contractor.
The six fields that carry the weight
Identity of the person, not the device. A scan tied to a handset proves which handset was there. It becomes proof of who only if a named user is signed in and sessions are not shared between shifts. If your guards pass one tablet along at handover, your identity field is decorative.
Event time, not sync time. This is the single most common defect. When a system stamps records with the moment they reached the server, every patrol done in a dead zone is dated to the end of the shift. The log then asserts something untrue, and once a client catches that once, the rest of your evidence loses credibility with it.
Location with a stated accuracy. A coordinate on its own invites the response that GPS is unreliable indoors. A coordinate carrying its own margin of error is far more defensible, because it declares its limits instead of waiting to be challenged on them.
A physical binding to the point. A passive NFC tag or QR label fixed to the wall ties the record to a specific place. Coordinates alone can be produced from the car park; a tag scan requires being within centimetres of it. Tags with a factory-unique identifier resist cloning in a way that generic writable tags do not.
An observed state, not just a passage. If the only possible outcome of a scan is "scanned", then a guard who walked past a propped fire door produces exactly the same record as one who checked it. Requiring a declared state — and a photo whenever that state is not "nothing to report" — converts a passage into an observation.
A closed chain for anything found. An incident with no recorded escalation and no recorded resolution is an open liability. Who raised it, who received it, when, and what was done: without that chain, discovering the problem can look worse than not discovering it.
The property that ties them together
All six fields lose their value if any of them can be quietly edited afterwards.
If a supervisor can amend a past record in place, then every record in the system is, in principle, amended. The defensible pattern is that a correction is written as a new event referencing the original, with both remaining visible. You lose the tidiness of a clean log and gain a history that a third party can actually rely on.
Ask a vendor directly: can an administrator change the timestamp of a scan from last week, and if so, what does the export show? The answer is diagnostic.
Three claims that sound like proof and are not
"Tamper-proof." Nothing is. What matters is whether tampering is detectable and recorded, not whether it is prevented.
"Real-time GPS tracking." Continuous tracking produces a lot of data and little evidence. A track shows a device moved; it does not show a checkpoint was inspected. It also raises employment-privacy questions that a per-scan location does not.
"Blockchain-verified." A hash chain can make a record set self-verifying, which is genuinely useful. It says nothing about whether the underlying record was accurate when it was written. Garbage that cannot be altered is still garbage.
What this means when you write a specification
Three lines are worth putting in the contract before the first shift, not after the first dispute:
- The evidential export format. A signed PDF for the client-facing record, plus a machine-readable export you keep. Agree which one is authoritative.
- The retention period. Long enough to cover your contractual liability window, which is usually longer than the default retention of the platform.
- Who may correct a record and how the correction appears. If this is undefined, it will be defined by whoever is under pressure at the time.
Where honest limits sit
Proof of presence is strong evidence that a person carrying an identified account was within scanning range of a fixed point at a stated time, and declared a state. That is a lot.
It is not proof that the inspection was competent. No system can produce that. What good tooling does is make incompetence visible over time — a guard whose checks are always "nothing to report" and always fifteen seconds apart is telling you something, and the record is what lets you see it.
How guardtour.app records this
Every scan carries the signed-in user, the time of the event on the device rather than the time it reached the server, a coordinate with its declared accuracy, and the factory-unique identifier of the tag. States other than "nothing to report" require a photo. Corrections are appended as new events that reference the original; nothing is overwritten, and the export shows both. Records captured with no connectivity keep their original timestamp when they reconcile.
Further reading
- /blog/nfc-token-for-guard-tour-software — how NFC checkpoint tokens work and where cloning becomes possible.
- /blog/qr-vs-nfc-vs-bluetooth-beacons-guard-tour-decision-matrix-2026 — choosing checkpoint technology by environment and by evidential strength.
- /blog/hot-cold-aisle-patrol-soc2-evidence — what an auditor asks for when patrol records become control evidence.