Most product posts describe what a company built. This one describes what we deliberately did not build, because in a privacy product, the absences are the feature.
01 · NO BIOMETRICSNo biometrics
We do not extract, store, or match facial geometry, gait, or any other biometric identifier. This is not a disabled feature. The model that runs on the sensor produces a count of people in a zone; it has no head for identity. There is no embedding vector, no template, no gallery to match against.
Why structural and not optional: a biometric capability that exists but is "turned off" is a capability that can be turned on. We chose not to have the capability.
02 · NO DEMOGRAPHICSNo demographics
We do not infer age, gender, ethnicity, or any demographic attribute. Demographic inference from vision is both ethically fraught and technically unreliable, and it is irrelevant to the operational questions occupancy analytics is built to answer: how full is this zone, when does it peak, where do queues form.
A council does not need to know who is in the square. It needs to know how many, and whether that number is approaching a safety threshold.
03 · NO RAW VIDEO LEAVING THE DEVICENo raw video leaving the device
The raw frame is processed in the sensor's memory and is never written to disk or transmitted. There is no cloud video archive because there is no upload path. This is the absence that makes the other two durable: even if every downstream guarantee failed, there is no footage to mine.
04 · WHY LIST THE ABSENCESWhy list the absences
Because a customer's legal review is, in practice, a search for the things that could go wrong. The fastest way through that review is to be able to say, precisely and verifiably: that class of risk does not exist in this system, and here is the architecture that makes it impossible rather than merely disallowed.
No biometrics. No demographics. No exceptions. The exceptions are where privacy products fail, so we did not build any.