Working offline on site, and proving you were there
A tablet on site holds on to what it captures, sends it when it gets signal, and the same database rules apply when it lands.
When there's no signal
The field app holds captured actions — complete a step, clock in or out, raise or close a deficiency — in a queue on the device (IndexedDB), each with its own ID generated on the tablet (a UUID) that also makes sure a retried send is never recorded twice (an idempotency key). When the device has a connection the queue replays in order; a refusal from the database (a reading out of range, a step already satisfied) is mapped to plain English and shown against the item rather than silently dropped. Photographs upload to storage first and the record references the stored path.
Location proof
Where a project turns it on, clock-ins and evidence for restricted equipment carry the device's position, and the server works out the distance to the site's geofence (the boundary drawn around the site) itself — the device never gets to say 'I was there'; it sends coordinates and the database decides. The threshold is set per organization.
- QR codes are doorways
- Each asset and location has a QR code that resolves to its record; scanning is rate-limited and logged as an event.
- Signatures
- A signature step stores a signature certificate — who, when, what was signed — not a picture alone.
- Nothing bypasses the gate
- A queued action replays through the same server action as a live one. There is no offline-only path.
- · src/lib/field-queue-core.ts and test/field-queue.test.mjs
- · db/034 (proximity), db/037 (offline clock)
- · test/location-proof.test.mjs, test/geo-attendance.test.mjs
These are files in our codebase. If you’re a customer under agreement, we’ll walk you through any of them.
