The story
Context
Two requests kept coming up in church operations: checking people in faster at a crowded entrance, and helping members find photographs of themselves from church events.
Both are computer-vision problems. Both involve people’s faces. We treated that as the design brief, not a footnote.
The problem
Face recognition in a community setting fails in ways that hurt trust:
- People being enrolled without understanding what it means.
- A confident-looking wrong match recorded as fact.
- Printed photos or replayed videos fooling the camera.
- Face images accumulating on servers “just in case”.
- Models trained on data that may not be licensed for commercial use.
Constraints
- Recognition must run on ordinary Android phones held by volunteer ushers — and keep working when the network drops.
- Operators are volunteers, not security staff.
- The church, not SomaMe, owns its members’ data and its event photographs.
The solution
Face Attendance (FAM) is opt-in. A member reads a consent notice, passes a live check and takes three guided photos; the face template is built on their own phone.
At the entrance, recognition runs on the operator’s phone after an active liveness challenge. Confidence decides what happens next. Medium confidence goes to the operator to choose; low confidence falls back to manual attendance. For high-confidence matches that are stable, show exactly one face and pass liveness, the pilot includes a configurable path for automatic recording — with a short Undo — that a church can only use when both the app and the server enable it.
Photo Discovery is a separate consent. Churches connect a private folder; photos are processed in the cloud while originals stay in the church’s storage; a reviewer confirms every match before a member sees it in Your Images, and a member can tap “Not me”.
Architecture
Public-level view:
- On-device detection and embedding; a church-local recognition index cached privately on the operator’s device and cleared on sign-out.
- Every face mark goes through the same attendance permission check as a manual mark and is recorded with its source.
- The audit trail accepts only simple decision fields, so images and face data cannot enter it.
- A server-side contract switch returns every device to operator confirmation without an app release.
- Photo processing runs in a private cloud worker callable only by the platform itself.
Design decisions
- Two consents, not one: agreeing to face check-in does not opt anyone into photo matching.
- No automatic photo publishing — there is no switch for it.
- Pilots start in shadow mode: people confirm every mark while the system records what it would have done.
- We screened candidate models’ licences and excluded any released for non-commercial use only.
- We do not publish lab benchmark figures as product accuracy.
Implementation
In September 2026 we benchmarked candidate on-device models, shipped operator-confirmed FAM with a shadow pilot mode, added liveness checks, then added a configurable path for automatic recording of high-confidence matches behind app and server switches. Photo Discovery shipped in the same period.
In SomaMe Labs, Asori Edge prototypes the same consent model on a church’s own IP cameras, running entirely on-premise and defaulting to shadow mode.
Outcome
FAM is a pilot feature: opt-in, with any automatic recording controlled per church from the server. Photo Discovery is released and opt-in. Asori Edge is a prototype that has not yet been certified on physical cameras.
We are deliberately not claiming accuracy figures until real-world pilot results exist.
What we learned
The most important feature of a face-recognition system is the path around it: consent, undo, manual fallback and an off switch.
Designing for volunteers — clear bands, one decision at a time — matters more than squeezing out another point of model accuracy.