A privacy policy is a readme. The actual posture is in the architecture: on-device inference, per-institution isolation, and consent that's deletable in one tap.
Every biometric product ships with a privacy policy. Very few ship with privacy *architectures*. The difference matters, and here is how we think about it.
Inference happens on the device
The raw face image never leaves the phone during enrolment. The model runs locally, produces an embedding, and discards the image in the same call stack. The thing that reaches our servers is a vector of numbers that cannot be inverted back into the image it came from.
This is not a technical choice we made because it was cheaper. It was actively harder. But it turns a regulatory minefield into a boring engineering problem.
The database knows about institutions, not about networks
Every row of face data is tagged with the institution it belongs to. The database enforces (not the application) that a read from inside institution A cannot return a row from institution B. A student at one school cannot be matched at another school. This is not a feature we plan to add, it is a constraint on the system.
Consent is a boolean the user controls
Enrolment is impossible without an explicit consent record. Deletion is one tap. Deletion is immediate on the device and propagates within 30 days across every system of record, except for the minimum transaction metadata required by law.
None of this is marketing
We don't sell behavioural data. We don't retrain models on user embeddings. We don't build cross-institution graphs. These are decisions we make with design reviews and code, not with a policy page.
A policy page is a promise. An architecture is a constraint. The second one is worth more.