Make attendance work offline, with evidence for every review.

Design for the place where check-in actually happens

An employee may need to check in where connectivity is unreliable. An attendance system therefore has to manage both capture and reconciliation: what was recorded on the device, what the server can validate later, and what happens if the checks disagree.

I built Absenku across a Flutter employee app, Go API, SvelteKit admin console, and Python face-verification service. The work combines model integration with the application rules and operational screens needed to turn a capture into an attendance record.

Choose models for different operating conditions

The phone uses MobileFaceNet for local face matching and a MiniFASNet-based model for anti-spoof signals. The online server uses ArcFace through InsightFace. Device and server embeddings belong to different model spaces; they are stored and compared within their own models, with separate threshold context.

My contribution is the integration, decision pipeline, and workflow around these pretrained models. I did not train the underlying recognition models. Optional server anti-spoof scoring also depends on installed weights and deployment configuration; it is not evidence of a validated production fraud-prevention system.

Reconcile offline work without losing its history

Offline captures enter a local queue and sync when connectivity returns. Each record carries a client-generated identifier so retries do not create duplicate attendance rows. Server checks include capture age, location policy, and face evidence.

The pipeline distinguishes a failed check from a record that needs a person to review it. When the device accepted an offline capture but the server face check disagrees, the record can move to the review queue. Reviewers can see the reason and evidence instead of receiving an unexplained reversal of the employee’s original result.

Make exceptions explicit

Office geofences, employee and division permissions, remote-work exceptions, and verification thresholds are managed through the admin console. A location waiver applies to the location rule and is recorded as such; it does not silently waive every verification check.

This is relevant to clients building field-work or attendance products with intermittent connectivity and review requirements. Absenku has no production users yet, and model thresholds still need representative field calibration. The gallery demonstrates the operational UI with illustrative records and scores, not biometric accuracy.