Logging entry and exit without a turnstile: the record verifies who and where

Logging entry and exit without a turnstile puts both checks inside the record: a scanned code names the worker, and phone location names the site. The decision turns on whether verification belongs to a site or to a person, because a fixed gate records nothing when nobody passes it. In the construction workforce system hours come from a matched pair, so an entry missing its exit stays visible as incomplete.

Why a turnstile never goes up on a temporary site

A turnstile is a verification device, and it binds verification to one place. The gate is where identity gets tested, so the record originates in the gate rather than in the person walking through it. In a permanent facility that binding costs nothing, because the gate lasts as long as the building around it. A construction site is different in kind: it is set up in order to finish. Any device bolted to it has a service life capped by the site’s own, and the money spent on it has to earn out inside the calendar of one project.

The second problem has nothing to do with the price of hardware. Construction crews are not attached to a single site; the same worker can be somewhere else by Wednesday. A device that counts passes through one point counts nothing on a day when the person never passes that point. The verifier stands still and the person being verified moves. A record that fails to appear is not a fault in the equipment — it is the arrangement producing exactly what it was built to produce.

The same pattern shows up in an unrelated corner of our portfolio. In the exam scoring system that reads marks straight off the image of the form, with no reader hardware involved, the optical reader sat in one central location, so branches had to carry their exam sheets to it. A fixed device summons whatever moves towards itself. Once reading became an operation on the image of the sheet, the carrying step disappeared and each branch scored its own exam where it was held.

Neither case is a complaint about the equipment doing its job badly. A turnstile counts passes accurately. An optical reader reads marks accurately. What costs money is the logistics that accumulates around a device that cannot move: one arrangement carries paper to a machine, the other ties an entire workforce to one doorway. The engineering question is therefore not how to buy a better device. It is whether this step has to sit on a device at all.

In a single-building factory, in a fixed office, or anywhere the workforce enters through one door every morning, a turnstile is a sound investment. The device runs for as long as the facility does, staff pass the same point daily, and a fixed check matches a fixed reality. Nothing here argues against the hardware. It argues against attaching fixed hardware to a site with an end date.

Why a paper timesheet collapses when somebody disputes it

The trouble with a paper timesheet is not that it is slow. Even filled in the same day, the line written on the sheet has nothing independent tying it to the event it describes. Whoever wrote the line also vouches for it. The record rests on the word of the person keeping it, and on nothing else.

That deficiency stays invisible in daily operation and presents its bill during a dispute. Progress pay is calculated on top of a sheet nobody can verify. When a subcontractor challenges the month-end figure, or a worker says a day they worked is missing, the only thing anyone can put on the table is the same sheet. Both sides look at it and it vindicates neither of them, so the disagreement gets settled by negotiation rather than by evidence.

With several subcontractors working the same site, the uncertainty compounds. Which person worked on which day, on whose behalf, at which location — that answer is scattered across several sheets kept by several people. What joins the fragments back together is human memory, applied weeks after the fact and under pressure from whoever is asking.

A record verified by QR and location inverts the situation. Every entry carries two independent checks from the instant it is captured: who scanned, and which site they were standing on. When a figure is challenged, what gets produced is not a list assembled at month end but the individual record made at the time. The conversation stops being about what people remember and becomes a conversation about the record.

Being digital does not, by itself, produce evidence. A mobile form typed in by hand is still a declaration; putting it on a screen does not make it verified. What creates evidentiary weight is that the checking happens at the moment of capture, tied to the event rather than added afterwards. The difference between paper and phone begins at that point.

What the QR code proves, and what the location proves

In the construction workforce system where a QR scan verifies the person, location verifies the site, and pay derives from those record pairs, every entry answers two questions at once. The code establishes who scanned it. The location service establishes which site they were on. Both facts sit together inside one record, and the evidentiary value of that record rests on their being together.

Split them and the record goes half blind. A code on its own answers who, but says nothing about where it was scanned. A location on its own answers where, but says nothing about whose phone was standing there. What an attendance record has to establish is the compound of the two: this person, on this site, at this hour. A record standing on one leg of the check is half an argument when somebody contests it.

The most visible consequence of this design is that the site name is never picked by hand at any step. Which site a worker is on is not ticked off a list; it is written from the location check. Any field a person selects is a field a person can select wrongly, and the month-end job of hunting down records filed against the wrong site starts there. Remove the step and the class of error belonging to it goes with it.

Both instruments doing the verification already travel in the worker’s pocket. The camera reads the code, the location service names the site. We built the layer that moves QR scanning and the location check onto the worker’s phone with React Native (Expo); the record goes to Laravel and is held in MySQL. Nothing is installed at the gate for verification purposes. This is the technical answer to the fixed-point problem from the first section: the verifier now travels with the person being verified.

The only physical object left on the site is the printed code itself. Unlike a device, it has nothing to break and nothing to service; when it wears out, another one is printed. When the project ends, that sheet leaves with the site and a fresh one is produced for the next one. No installation line item is created, because there is nothing to install.

The chain cannot always be formed. Where workers do not carry their own phones, or where a business does not allow phones onto the site at all, there is no surface to carry the verification. In those conditions this model does not apply. Software cannot close that gap, because what is missing is not the record but the thing that would carry the check.

Hours come out of a matched pair, not out of a field

There is no field in the system labelled “hours worked”. Duration is a value computed from a matched entry and exit record. That is a decision about the shape of the data, not a reporting preference laid over it afterwards.

To see the difference, picture the declared alternative. A declared value can be edited, rounded, or revised later, and when it is revised it contradicts nothing, because there is no source for it to contradict. In the derived arrangement no such field exists anywhere. Anyone who wants to change the result has to reach the source records, and those records carry two checks each. Changes remain possible; what they stop being is invisible.

The second consequence surfaces in incomplete records. An entry whose exit was never scanned stays on the list as an incomplete record until the exit arrives. It does not quietly resolve into a default shift length, and nothing closes it automatically at midnight. The gap presents itself as open work that somebody has to close, not as an error state that somebody has to acknowledge.

Set against paper, this is the real difference. On a paper timesheet there is no such thing as a forgotten line: nobody perceives the absence of a line that was never written. The sheet looks complete with the gap inside it, and the gap surfaces only when a person remembers that particular day and objects. Where hours are derived, missing data stays on the list as an auditable condition.

A third consequence loops back to the dispute described earlier. If duration were a declared field, an objection would land on the field itself: why this number, who entered it, which day does it belong to? When duration is a computed result, the argument moves one step upstream onto the source records, where the questions are concrete and answerable. Which entry, scanned by whom, captured on which site, matched against which exit.

Operationally, the exceptions are handled where they belong. A forgotten exit is treated as an exception and completed at the record level by whoever is accountable for it. The correction is written onto the record that produces the result, never onto the result itself. The basis of the calculation therefore stays in one place under every circumstance: the verified entry and exit records.

How records stay apart when crews move between sites

Records belonging to the same worker on different sites stay apart. Because entries are kept broken down by person and by site, the hours of somebody who changes site midweek do not run together. That separation is not the product of any sorting done later.

The reason sits in the decision from the previous section. Site data is written into each record from the location check at the moment of capture, so a record arrives already carrying the site it belongs to. Splitting the month’s records site by site never becomes a task, because the split is already present in the structure of every record.

Had the site not been written onto the record, entries would accumulate in a single pool and their site would be assigned afterwards. Retrospective assignment leans on memory again: where was this person that week? In that arrangement the accuracy of the separation is capped by the recollection of whoever performs it, which is precisely the weakness the system set out to remove.

A second axis of separation runs inside a single site. Several subcontractors work side by side on one project and their crews come through the same entrance. Because the record is attached to a person rather than to a gate, entries created on the same site on the same day still separate by subcontractor. On paper, this was the case that failed most often — the same individual’s records across sites and subcontractors ran together, and the question of who worked on whose behalf had to be re-answered every month.

Totalling follows the same breakdown. Hours for one worker across different sites are added up separately, and the totals never flow into a common pool. Because progress pay separates per site, one site’s cost is not inflated by another site’s records. What was a problem in the paper arrangement — the mobility of the workforce — turns into ordinary data carried by the record.

Progress pay is a derived result, not a second table

No second table for progress pay was ever opened. The amount owed at the end of the month comes out of the verified entry and exit records themselves, and there is no calculation sheet standing beside those records, fed by hand.

The absence removes a maintenance item along with it. In any arrangement holding two tables, one question becomes unavoidable: which of them is right? The source records are fed from the field while the calculation sheet is kept by hand, so the two drift apart at their own pace, and reconciling them lands on somebody’s desk at the close of every month. Where the second table was never created, that question never arrives, because there is nothing to compare the records against.

The same pattern has a second face in one of our own products. In AlgoKlima, where a unit’s history is not a separate table but a result derived from its service records, warranty, maintenance and fault records accumulate underneath the record of the unit itself. There is no separately kept history list; the history is simply the set of records attached to that unit. The everyday consequence is concrete: when a unit changes hands, its history stays with it, and nobody goes looking for a file to transfer.

One rule runs through both cases. If a fact can be computed from records that already exist, giving it a home of its own means storing it a second time, and a second copy always carries the possibility of drifting from the first. Derivation removes that possibility, because the value is produced from its sources every time it is read.

Deriving a value does not mean pretending exceptions never happen. A forgotten exit, a day when a phone stopped working, a shift where the check could not be performed — all of these occur. Every one of them is settled at the level of the source record: the incomplete entry gets completed, and the correction is written onto the record. The derived result is never edited by hand. Editing it would recreate exactly the condition the design avoids, with two versions of the truth in circulation: what the records say, and what somebody typed.

A turnstile PDKS and a phone-based record, side by side

The two approaches are not competitors. One answers the permanent facility; the other answers the site whose working life is shorter than the device’s. The table below sets them against the same axes.

Reading down the table, the decisive line is the second one. Every other row can be argued about in terms of cost and effort. The mobility row determines whether a record comes into existence at all, and no amount of quality in the mounted device compensates for a worker who never walks through that particular gate.

The third row is subtler. A turnstile does not ask anyone to pick a site either — the site is implied by wherever the device was installed, and the record inherits it from the device’s identity. In the phone-based arrangement the site comes from the location at the moment of entry. Neither one hands the choice to a person. The difference is whether verification is bound to a place or to a person. Verification bound to a place ends when the place does; verification bound to a person continues wherever that person goes next.

What decides between them is therefore not the industry but the lifespan of the site. Where an operation will occupy the same address for years, a fixed device means fewer moving parts and the investment spreads across the life of the facility. Where the work is measured in months, closes when it is finished and sends its crews to the next address, the same device gets installed in order to be taken down before it has earned out.

The value of a field record does not end at the moment of capture, either. Entry and exit records feed the timesheet in the office, and the timesheet feeds what gets paid. When we design the setup that turns field entry and exit records into office timesheets and pay, the question we ask is always the same: is this fact entered once, or re-entered at every layer that touches it? Where verification is embedded in the record itself, the answer is the first one, and the rest of the chain runs on that same record.