docs: reflect client-side Facenet512 embedding in prose (Phase-1C truth sweep)#23
Merged
Merged
Conversation
…th sweep) Align the remaining architecture prose with the SP-G client-side-embedding truth already landed in the diagram pages (PR #22) and CLIENT_SIDE_ML_PLAN v3.0. - BIOMETRIC_ENGINE_ARCHITECTURE: EmbeddingComputer is Facenet512 ONNX (was labelled MobileFaceNet / geometry-512 fallback). The client-side path (flag app.auth.client-side-embedding, default OFF) computes the authoritative Facenet512 embedding in the browser and uploads only the 512-d vector; raw image never leaves the device; server keeps the image->Facenet512 fallback and owns match + liveness verdict + decision. - ADR 0004: add a 2026-06-11 amendment. Encoder (Facenet512, 512-d, cosine) unchanged; the new client-side path computes that SAME embedding in-browser and is authoritative when the flag is ON. Corrects the old 'client embedding is a different model/shape, never compared against face_embeddings' (true of the old geometry-512 pre-filter, NOT the new client Facenet512). - PLATFORM_CAPABILITY_MATRIX (Face Recognition): document both the legacy image-upload path and the client-side-embedding path (data minimization: only the 512-d vector uploaded); anti-spoofing names the active Biometric Puzzle (randomized, server re-scored). Server remains authoritative for the match + liveness verdict + accept/reject in every case. Honest framing throughout: data minimization (derived non-invertible 512-d embedding over TLS, Fernet at rest), NOT 'biometric data never leaves the device'.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase-1C content sweep — docs-book PROSE
Companion to SP-G PR #22 (which landed the client-side-embedding + puzzle-as-layer diagram pages and
CLIENT_SIDE_ML_PLANv3.0). This sweep updates the remaining architecture prose so the narrative matches.Changes
02-architecture/BIOMETRIC_ENGINE_ARCHITECTURE.md—EmbeddingComputeris nowFacenet512 ONNX(wasMobileFaceNet/ 'geometry-512 landmark fallback'). The client-side path (flagapp.auth.client-side-embedding, default OFF) computes the authoritative Facenet512 embedding in the browser and uploads only the 512-d vector; the server keeps the image→Facenet512 fallback and owns match + liveness verdict + decision.adr/0004-facenet512-server-authoritative.md— amendment note (2026-06-11). The encoder choice (Facenet512, 512-d, cosine) is unchanged; the new client-side path computes that same embedding in-browser and is authoritative when the flag is ON. Corrects the old 'client embedding is a different model/shape, never compared againstface_embeddings' — true of the old geometry-512 pre-filter (ADR 0003), not the new client Facenet512.09-auth-flows/01-PLATFORM_CAPABILITY_MATRIX.md(Face Recognition) — documents both the legacy image-upload path and the client-side-embedding path (data minimization: only the 512-d vector uploaded, raw image never leaves the device); anti-spoofing names the active Biometric Puzzle (randomized, server re-scored).Honesty
Data-minimization framing throughout (derived, non-invertible 512-d embedding over TLS, Fernet at rest) — not 'biometric data never leaves the device'. No certification overclaim, no real-customer language, puzzle kept as the active anti-spoof mechanism under FACE (not promoted to a standalone factor — SP-B not yet shipped; honours the canonical 10-methods rule). Diagram pages unchanged (already correct via #22).