Two Thousand Faces Every Morning

A construction site in Shanghai can hold anywhere between three hundred and two thousand workers, arriving from different provinces, rotating between contractors. Chinese regulation requires each of them to be registered by name and checked against government records. In practice this means a supervisor standing at a gate every morning, comparing people to a list, while the queue behind them grows and the day does not start.

Our client’s answer was a pair of augmented reality glasses with face recognition. Look at a worker, get an answer, wave them through. Synograph took the backend, the frontend and the industrial design of the glasses. Yingying Ge led the user research and has published her own account of the study, which is worth reading alongside this one because it is the part most companies skip. The project ran nine months, with a fourteen week iterative design phase, on a team of three: one developer, one cloud and systems engineer, one researcher.

The recognition itself was working in the office within the first weeks. Almost everything that took the remaining nine months was something nobody had written down at the start.

What the job actually is

The loop looks trivial. The supervisor looks at a face, the glasses capture it, a server compares it with the registry, the display returns one of three answers: not in the local records, not approved by the authorities, or cleared.

What makes it difficult is that this is not a data lookup. It is a decision about a person who is standing in front of you, at seven in the morning, in a queue, who will react to your hesitation. The supervisor is not reading a screen. They are managing a crowd while consulting a device. Every ambiguous state, every second of delay, every result they are not sure they can trust gets paid for immediately and socially.

That reframing decided most of what followed. We were not building an identification system with a user interface attached. We were building a tool for someone whose real task is to keep a queue moving.

The site is a hostile input device

Field testing produced three findings within weeks, and none of them was in the specification.

Light. In low light, recognition accuracy dropped by thirty to fifty percent. In bright sunlight the display became unreadable through glare. Supervisors started holding phone flashlights to workers’ faces to finish a check. The root cause was not the recognition model: it was the absence of an ambient light sensor, a fixed display contrast, and no adaptive behaviour of any kind. A camera and a screen that assume office lighting will fail outdoors twice a day, at dawn and at noon, for opposite reasons.

Dust. On an active construction site, recognition degraded by around forty percent. Workers were spending upward of ten extra seconds per check wiping their own faces. The camera module’s IP54 rating, adequate on paper, was not adequate in a place where concrete dust is the normal state of the air.

Crowding. The system recognised one face at a time. Real gate-in is not one face at a time. Verifying a group cost fifty to a hundred percent more time than the same people checked individually, which is the opposite of what anyone expects a machine to do.

The honest lesson here is uncomfortable. We treated light, dust and crowding as hardware defects to be corrected in a later revision. They were not defects. They were the operating environment, and therefore the product. A verification device for a construction site is a dust and glare product that happens to do face recognition.

The twenty to thirty percent you cannot see

The glasses shipped in a single frame size. Between twenty and thirty percent of workers could not wear them properly. Nose bridges too narrow or too wide, fixed temple arms producing headaches over a shift, frames intruding into peripheral vision, and a poor fit degrading recognition accuracy on top of everything else.

A device that fits seven or eight workers out of ten is not a product, it is a demonstration. And the excluded group is not random: fit correlates with regional origin and with age, which means the failure lands on the same people repeatedly. That is an accessibility problem in the plain sense of the word, even though nobody in the room called it one at the time.

Three design directions came out of it. Modular frames in three sizes rather than one. Adjustable nose pads and flexible temple arms, so the tolerance lives in the product rather than in the user. And a rethink of mass.

Weight is the part most people get wrong, including us at first. The question is not how many grams the glasses weigh, it is where those grams sit. Mass at the front of the head works on a long lever against the neck, and a device that feels fine for eight seconds in a showroom is punishing after eight hours at a gate. Moving battery mass rearward improves perceived weight and neck fatigue at the same time, and it buys room for a larger cell, which is the other half of the problem: a device that needs charging before the shift ends is a device that gets left in a drawer.

Autonomy, weight and balance are not three requirements. They are one requirement seen from three angles, and they have to be traded against each other deliberately rather than discovered in sequence.

The network is the interface

Cloud verification failed whenever connectivity was unstable, and on a construction site connectivity is unstable by design. Steel, concrete, cranes, containers, and a radio environment that changes shape every week as the building goes up. Coverage that was fine in month two is not fine in month five, because the obstruction is the thing being built.

The supervisor does not experience this as network instability. They experience it as standing in front of a person, in silence, while nothing happens. Two seconds of that is survivable. Four is not. Past a certain point the glasses come off and the paper list comes back out, and at that moment the project is over regardless of how good the recognition model is.

We treated this as an infrastructure problem rather than a software one, because that is what it was. The answer was dedicated coverage: relays positioned on the site and higher performance 4G and 5G transmitters, sized so the glasses always had a usable link rather than a nominal one. This is unglamorous work, it does not appear in any product demo, and it was one of the two or three things that decided whether the system was adopted.

where the supervisor's wait goes

capture    on the glasses      instant
uplink     relay -> 4G/5G      variable
match      edge, in region     short
display    on the glasses      instant

Only one line in that list moves. Everything else is roughly constant. Optimising the recognition model when the uplink is the variable is a common and expensive way to spend six months.

Moving the computation closer

The glasses have a hard ceiling on what they can display and what they can compute. You cannot put a workstation on someone’s head, and any processing you add costs battery, which costs weight, which costs the neck. So the computation has to go somewhere else, and the only question is how far away.

The further the data travels, the longer the person in the queue waits. We used edge computing on AWS China with a serverless application layer for the verification path, so that the decision is made close to the site rather than across the country.

The serverless choice was not fashion, it was the shape of the workload. This system does two thousand verifications inside roughly one hour and then almost nothing for the rest of the day. Capacity sized for the morning peak sits idle from nine until the following dawn. Paying per request rather than per provisioned server matches the cost to the actual demand, and a daily peak with a flat trough is the textbook case for it.

Worth knowing if you are planning something similar: AWS China is a separate partition from the rest of AWS, operated locally, with its own accounts, credentials and regions. You do not extend an existing global deployment into it. You stand up a second one, and you need a local entity to do so. That is a planning fact, not a detail, and it belongs in the schedule from the first week.

The law arrives first, or it arrives too late

This system captures faces. In China, that places it inside a specific and strict regime rather than a general one.

Three laws matter together. The Cybersecurity Law governs the security of systems hosted in the country and imposes data localisation on operators of critical information infrastructure. The Data Security Law sits alongside it. And the Personal Information Protection Law classifies biometric data as sensitive personal information, which requires separate consent and raises the bar on purpose limitation and on how long anything may be kept. Moving personal information out of the country is not a copy operation either: above certain thresholds it triggers a security assessment by the Cyberspace Administration. Face recognition attracts additional scrutiny on top of all of that, and reasonably so.

The engineering consequence is direct. Data residency is an architectural decision, not a deployment option, and it has to be made before anything is built. Retention has to be a designed number rather than a default, because a default in a database is a decision made by whoever installed it. And the smallest thing that can be kept should be the thing that is kept: a verification outcome is not the same object as a stored face, and the difference matters legally as much as it does technically.

For a decision maker the practical point is this. Legal constraints on this kind of project are not a compliance review at the end. They determine where your servers are, what your data model looks like, and which features are available to you at all. A team that discovers them in month seven rebuilds. We would rather meet a regulator’s requirement in week one, when it costs a conversation.

Why this could not be run from Paris

Several parts of this project were only solvable on location.

Getting a researcher onto an active construction site is a project in itself: authorisations, safety induction, timing that has to match a working gate rather than a convenient calendar. Access to the site is the first real constraint of field research, and it is routinely underestimated in planning.

Then there is the work itself. Interviews happen in the language of the people doing the job. Fit correlates with regional origin, which you notice by watching a queue rather than by reading a specification. The AWS China partition needs a local entity. The regulatory reading needs local counsel, not a translated summary.

Synograph has kept a presence in China since the beginning, and this is the kind of project that explains why. Not because remote work is impossible, most of our work is remote, but because some questions only have answers at the gate, at seven in the morning, in the dust.

What we would ask before starting again

Nine months produced a list of questions we now ask early. They are not rhetorical. Each of them cost us something.

How many of your users does the hardware physically fit? Measure it on real people before ordering. A single size is a decision to exclude a percentage of your workforce, and you should know the number rather than discover it.

What does the system do when the network is gone? Not if. A degraded mode that a supervisor can trust is worth more than an accuracy improvement they will never notice.

What is the shape of the workload in time? A flat daily average hides a peak. The peak decides your architecture and your bill.

Where does the data live, who can compel access to it, and how long is it kept? Answer this before writing the schema.

Who owns the devices once they are deployed? Charging, cleaning, breakage, replacement, and the person who gets called when forty of them are flat on a Monday. Hardware projects have an operational tail that software projects do not, and it starts on day one of use, not at the end of the warranty.

Who has actually been on the site, and for how long? This is the one that predicts the others. Almost everything above was found by observation within the first weeks of field research, and almost everything above would have been cheaper to know before we started building.

The recognition worked. The site did not care. What decided the outcome was light, dust, fit, weight, coverage, distance to the compute, and the law, in roughly that order, and not one of those was in the original brief.