lakehouse/docs/policies/consent/biometric_consent_template_v1.md

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) Updated 2026-05-05: Disclosure 1 + plain-language summary revised to match the Gate 3b deferral recommendation in docs/specs/GATE_3B_DEEPFACE_DESIGN.md (Option C — defer classifications). Pending J's product confirmation of Gate 3b; if Gate 3b chooses Option A or B, this template needs counsel re-authoring.

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 and store my biometric identifier (a photograph of me from which facial geometry is implicit). The photograph itself is the data we keep — we do NOT run automated facial-classification (gender / race / age inference) against it in v1. If at a later date we add automated classification, we will re-collect consent under a superseding template before doing so.

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.

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 so your staffing coordinator can recognize you when you arrive at job sites. We don't run automated guesses about your age, gender, or race against the photo.

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@<deployment-domain>), 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:

{
  "candidate_id": "<token>",
  "consent_version_hash": "<sha256 of this file at deployment>",
  "consent_given_at": "<ISO-8601 timestamp>",
  "consent_collection_method": "<electronic_signature|paper|click_acceptance>",
  "consent_collection_evidence_path": "<path to signed artifact, if applicable>"
}

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	_____________	_______________	_____