Presentation attack detection, whose model this actually is, and a threshold we have never evaluated

This is the clearest "built but not claimable" item in our stack, and we would rather label it that way than let running code imply a finished capability.

What a presentation attack is

Any attempt to fool a biometric check by presenting something that is not a live, genuine characteristic of the real person: a printed photograph, a video replayed on a screen, a realistic mask, or a synthetic face or voice. The defence is called presentation attack detection, or PAD.

The field grades attacks by sophistication because the defence that works differs by tier:

• Print and screen replay can often be caught by analysing texture and reflection in an ordinary camera image.
• Masks and well-made synthetic faces generally need more than one camera can give: depth sensing, infrared, or temporal analysis across many frames.

The standard is ISO/IEC 30107, maintained by ISO/IEC JTC 1/SC 37, the international biometrics committee. It defines the taxonomy and how to test against it, and accredited laboratories grade systems against both tiers, so a buyer does not have to take a vendor's word for it. NIST/iBeta is that pathway, and we have not been through it.

Whose model this is, which is not ours

Our PAD model is MiniFASNetV2, an openly published architecture from Minivision AI's Silent-Face-Anti-Spoofing project. We run it as an ONNX model behind an inference endpoint, and our image cropping and preprocessing follow the upstream project's pipeline exactly, because departing from it would invalidate the model's own training assumptions.

The engineering credit for the model belongs to that project, not to Solidus. We did not design it, train it, or improve on it. Naming the upstream is the same discipline we apply to every other term in our lexicon, almost nothing here is ours, and the security-critical components are the last place to start blurring that.

The threshold, and the sentence we would rather you read here than infer later

The gate compares the model's score against a configurable threshold. Ours is the upstream default.

It is unevaluated. The model has never been tested by us against a single real printed photograph or screen replay.

That is not a hedge. It means the operating point separating "live" from "not live" in our pipeline was inherited from an open-source project's default value and has never been calibrated against the attacks it exists to stop.

Which is why no Solidus copy says "anti-spoof" and none will until an adversarial evaluation has actually been run. The endpoint exists and returns a score. Running an endpoint is not a claim about what it catches.

What our sensor situation structurally permits

We work from an ordinary device camera. No depth sensor, no infrared, no specialised hardware.

That places the second attack tier, masks, high-quality synthetic faces, structurally beyond what our inputs can reliably distinguish, regardless of the model. A vendor with depth or infrared capture has information we do not have.

We are stating the limit of the sensor, not just the limit of the software, because the software limit could in principle be fixed with a better model and this one cannot.

Why there is no number here

No detection rate, no attack-presentation classification figure, no benchmark result. We have none that would mean anything: no accredited-laboratory result exists, and any internal figure would be self-graded, at an uncalibrated threshold, against data we chose.

If a Solidus page ever shows a PAD or anti-spoof figure, it is wrong.