Enforcement, not reporting.
Geofenced attendance, live face verification and mandatory safety checks are enforced in the mobile app itself, at the moment of the punch, not reviewed after the fact in a report.
gates
in every punch
question sets
punch-in and punch-out differ
platform uptime
SLA commitment
Every punch is a five-gate sequence.
Punch in and punch out both follow the same mandatory order. Each gate blocks the next until it clears.
Gate 1
Geofence check
An admin draws a circular boundary around a job address and sets the radius. The worker's app shows live distance from center against the allowed radius before it lets them proceed.
Gate 2
Job confirmation
The worker confirms the assigned job, or selects the correct one if more than one is scheduled at that location that day.
Gate 3
Photo capture
A live photo is required to continue. The punch button stays disabled until one is taken, not just prompted for.
Gate 4
Face confidence
The photo returns a numeric confidence score, not a pass or fail. Low confidence prompts a retake before the worker can continue.
Gate 5
Safety Q&A
A short set of hazard questions is reviewed and confirmed. Punch-in and punch-out use different question sets, not the same quiz repeated.
Punch in reviews shift-start hazard questions, specific to the job being started.
Punch out reviews a distinct checkout question set, not the same quiz repeated.
Each gate closes a specific way a punch gets faked.
A single login or a manual timesheet closes none of these. Five separate, mandatory checks close five separate failure modes, and none of them substitutes for another.
Gate 1, Geofence check
Closes: A punch logged from off-site, before the worker has actually arrived.
Gate 2, Job confirmation
Closes: Hours attributed to the wrong job, client, or cost center.
Gate 3, Photo capture
Closes: A punch submitted with no worker actually present to capture.
Gate 4, Face confidence
Closes: Buddy punching, one worker clocking in on behalf of another.
Gate 5, Safety Q&A
Closes: A shift started unbriefed, or an incident that goes unreported at close.
Configured per site, not a fixed default.
An admin searches a job address on a map and sets a circular boundary radius for that site specifically. There is no single platform-wide geofence size: a warehouse perimeter and a single storefront are configured differently, by the people who know the site.
The worker's app shows live distance from the boundary center against the allowed radius, in real time, before the punch is accepted.
A confidence score, reviewed by the worker.
Face verification returns a numeric confidence score at the moment of capture. Low confidence prompts a retake in the app itself, not a rejected timesheet reviewed days later.
Identity checks run against the worker's own onboarding profile, set once during onboarding and referenced at every punch after.
A live capture, checked for signs it was faked.
The face check runs liveness detection and an anti-spoofing model against the capture, with an optional identity match against the profile photo set at onboarding. The model itself is hosted internally rather than routed to a third-party vendor at every punch.
The camera requires a fresh capture at every punch. A photo from a previous shift, or a picture of a picture, is what the liveness check exists to catch.
A worker can retry, on the spot.
The photo capture step is a hard gate before it is a check: the punch action itself stays disabled until a photo is taken, not just requested. If a capture comes back low confidence, the worker retakes, removes, or cancels it from the same screen, and tries again before the punch continues.
This runs on the worker's own device, in the field, rather than as a rejected timesheet line an office reviews after the shift is already over.
A hard block, not a flag someone reviews later.
When a gate fails, the punch action is not offered, or stays disabled, on the worker's own device, at that moment. Assigned work has to be marked complete before punch-out becomes available. Generic HR and HCM suites report on attendance after the fact; enforcement is built into the mobile app flow itself.
A blocked punch is a blocked punch, decided on-site, not a variance flagged in a report an admin gets to days later.
Deviation triggers an alert, not just a note.
Route adherence is monitored for workers moving between sites, and a deviation raises an alert rather than sitting unnoticed in a log. What happens next, who gets notified and how it escalates, is configurable per client rather than one fixed workflow forced on every deployment.
Escalation rules are a client-level setting, matched to how that client actually wants a deviation handled.
Partial offline mode, on the same device.
Job sites are not always where signal is strongest. The app supports a partial offline mode: shift activity is cached on the device and synced once a connection is available again, instead of being lost in a dead zone.
Logged activity catches up automatically once the device reconnects, rather than requiring a worker or admin to re-enter it by hand.
Punching in and out still needs a live connection.
Geofence and face checks are validated in real time, so login and logout specifically require live connectivity even though other in-shift activity can proceed offline. That trade-off is deliberate: the gates that establish where a worker is and who they are cannot be taken on faith and reconciled later.
A worker can be off the grid mid-shift; they cannot punch in or out off the grid.
Onboarding
Activation
Field Execution
Monitoring
Completion
Exit
Verification runs continuously through Field Execution and Monitoring, the two stages where a worker is actively on shift.
Verified identity.
Enforced attendance.
We will map Hirebase to your compliance framework,
your ERP and your region.
© 2026 Hirebase. All rights reserved.