# Biometric Information Consent — v1 **Spec:** docs/PHASE_1_6_BIPA_GATES.md §1 Gate 2 (BIPA §15(b)(1)-(3)) **Status:** Engineering scaffold — ⚖ COUNSEL must author the binding text before deployment **Version:** v1 (initial; supersession requires a new version + new hash) > This is the consent template a candidate signs (electronically or > on paper) BEFORE Lakehouse collects, stores, or processes any > biometric identifier or biometric information from that candidate. > > Without an executed consent under this template (or a counsel- > approved successor), the system MUST NOT accept a photograph from > the candidate. Enforcement lives at the photo-upload endpoint > (Gate 3) and at the SubjectManifest writer, which refuses biometric > writes when `consent.biometric.status != "given"`. --- ## Required disclosures (BIPA §15(b)(1)-(3)) The disclosures below are MANDATORY content per 740 ILCS 14/15(b). ⚖ COUNSEL — render this content into binding language appropriate for the candidate-facing UI. Engineering provides the structural content; counsel provides the legally-sufficient wording. ### Disclosure 1 — Notice of collection (§15(b)(1)) Lakehouse will collect, store, and use my **biometric identifier** (facial geometry derived from a photograph of me) and **biometric information** (gender, race, and age classifications derived from that photograph by an automated facial-classification model called deepface). ### Disclosure 2 — Specific purpose and length of term (§15(b)(2)) The biometric data will be used for: 1. Identity verification at staffing job sites 2. Internal record-keeping so coordinators can recognize me across placements The biometric data will be retained for a maximum of **18 months** from my most recent interaction with the staffing platform, after which it will be permanently destroyed per the [Biometric Retention Schedule v1](biometric_retention_schedule_v1.md). I may withdraw this consent at any time by contacting the operator (see §3 below). Withdrawal triggers permanent destruction of my biometric data. ### Disclosure 3 — Written release (§15(b)(3)) I provide a written release authorizing Lakehouse to collect, store, and use my biometric identifier and biometric information for the purposes stated above and for the term stated above. --- ## 1. Plain-language summary (non-binding) ⚖ COUNSEL — the section above is the binding legal disclosure. The summary below is provided for candidate comprehension and is NOT a substitute for the binding disclosure. Both should appear together in the consent UI; counsel determines whether this summary is appropriate to include or whether a different plain-language section is preferred. > **What you're agreeing to:** if you upload a photo of yourself, > we'll keep that photo and a few descriptive labels about the photo > (estimated age, perceived gender, perceived race) to help your > staffing coordinator recognize you when you arrive at job sites. > > **How long we keep it:** at most 18 months after your last > placement or interaction with us, then it's permanently destroyed. > > **What we DON'T do with it:** we don't sell it, we don't share it > with anyone outside the staffing operation unless legally compelled, > and we don't use it to decide what jobs to recommend to you. > > **How to take it back:** contact us (§3 below) at any time to > withdraw your consent. We will permanently destroy your biometric > data within 30 days of receiving your request. --- ## 2. Withdrawal procedure I may withdraw biometric consent at any time. Withdrawal: - Is free of charge - Does not affect my ability to remain on the staffing platform (only my biometric data is removed) - Triggers permanent destruction of all biometric data within 30 days, per the destruction runbook - Is recorded as an append-only audit row in my per-subject audit log, providing me with tamper-evident proof of withdrawal if I subsequently exercise my BIPA right of action ⚖ COUNSEL — confirm 30 days is the right destruction SLA. Some deployments use 7 or 14 days. The runbook (Gate 5) currently references this template's number, so changing it here updates both. --- ## 3. Contact for withdrawal / questions ⚖ COUNSEL — supply the candidate-facing contact channel for biometric-consent withdrawal. Examples: a dedicated email (`biometric-consent@`), a postal address, a named operator. The contact must be functional from day one of deployment. --- ## 4. Consent acknowledgment By signing below (electronically or on paper), I acknowledge that: 1. I have read and understood the disclosures in §1-3 above 2. I am providing this consent voluntarily and free of coercion 3. I have received a copy of this consent template (or have been provided a means to retrieve a copy at any time) | Field | Value | |---|---| | Candidate name | _______________________________ | | Date | __________ | | Signature | _______________________________ | | Consent template version | v1 (SHA-256: _generated at deployment time_) | --- ## 5. Operational integration The structured fields the consent UI must capture and post to identityd: ```json { "candidate_id": "", "consent_version_hash": "", "consent_given_at": "", "consent_collection_method": "", "consent_collection_evidence_path": "" } ``` These fields write to `SubjectManifest.consent.biometric.status='given'` and the corresponding `SubjectAuditRow` (see `crates/catalogd/src/subject_audit.rs`). --- ## 6. Versioning This consent template is version v1. Per Gate 1's versioning rules, any change to the binding disclosure language requires a new version, and existing subjects retain their original consent_version reference unless they re-consent under the new version. ⚖ COUNSEL — confirm whether existing consent under v1 carries forward when the schedule is updated, or whether re-consent is required. This affects the deployment workflow. --- ## 7. Authority | Role | Name | Signature | Date | |---|---|---|---| | Operator | J | _______________ | _____ | | Outside counsel | _____________ | _______________ | _____ |