Navex
Face-recognition attendance for school buses, built to work in the worst possible conditions for face recognition and to keep working when the network does not.
Built at Tezeract, where I was Lead Engineer. I architected and developed this product personally: the AI pipeline, the backend and the system design.
Architecture Overview
An on-vehicle capture device running recognition locally against a per-route enrolled set, backed by a Node.js API and MongoDB. Recognition results and GPS position are written to a local queue first and synced opportunistically, so the bus application is authoritative offline and the server reconciles on reconnect. Four clients (parent, school, attendant and super-admin) read projections of the same event stream rather than querying each other.
The Challenges
Problem
A bus door at 7am is close to adversarial for recognition. Students board in a fast queue, backlit by a window with the sun behind them, faces turned away, half of them in winter hoods, on a vehicle that is vibrating. Benchmark accuracy figures for face recognition are measured on nothing resembling this.
Solution
We narrowed the problem until it was tractable. Recognition runs against only the students enrolled on that route rather than a school-wide gallery, turning a large identification problem into a small one where the confusion set is a few dozen faces. Multiple frames are captured per boarding and the decision is made over the sequence, so one bad frame does not decide anything. Most importantly, low-confidence matches are not guessed. They surface to the attendant as a prompt to confirm, which keeps a human in the loop exactly where the system is weakest. An attendance system that silently marks the wrong child present is worse than one that occasionally asks.
Problem
School routes pass through underpasses, industrial areas and rural stretches with no usable signal. A design that treats the network as available and connectivity loss as an error state produces a product that fails every single morning.
Solution
We inverted the assumption. Recognition runs on the device, and boarding events are written to a local queue that is the source of truth until sync succeeds. Events carry device-side timestamps and idempotency keys so a replayed queue after a long outage cannot double-mark a student, and the parent-facing app distinguishes between 'no boarding event' and 'no contact with the bus' rather than collapsing both into silence. The synchronisation logic, not the recognition model, was the larger share of the engineering.
Problem
This is a facial recognition system whose subjects are minors who did not choose to be enrolled in it. Treating that as purely a technical problem would be a failure of the design, and any honest write-up has to state where the boundaries were drawn.
Solution
The design decisions that follow from taking that seriously: recognition runs on the vehicle so face imagery is processed locally rather than streamed to a server, the enrolled representation is a derived embedding tied to a route rather than a retained photo library, and the system's outputs are boarding events, not a movement history or a searchable face database. The deployment is also bounded by the operator: this is a tool for a school that already has a duty of care and already takes attendance, automating a record it was keeping anyway, rather than new surveillance introduced under a safety framing.