lakehouse/docs/policies/consent/biometric_retention_schedule_v1.md

Biometric Data Retention Schedule — v1

Spec: docs/PHASE_1_6_BIPA_GATES.md §1 Gate 1 (BIPA §15(a)) Status: Engineering scaffold — ⚖ COUNSEL must author the binding text before public publication Version: v1 (initial; supersession requires a new version + new hash)

This is a publicly-available retention schedule for biometric identifiers and biometric information collected by the Lakehouse staffing platform. It is required by 740 ILCS 14/15(a) (the Illinois Biometric Information Privacy Act) before any biometric collection from real candidates begins.

---

1. What this schedule governs

This schedule applies to:

• Biometric identifiers as defined in 740 ILCS 14/10: facial geometry derived from candidate photographs.
• Biometric information as defined in 740 ILCS 14/10: any information derived from a biometric identifier, including but not limited to the gender, race, and age classifications produced by the deepface model when applied to a candidate photograph.

Out of scope (explicitly NOT biometric data under this schedule):

• Synthetic faces from the pre-existing face pool (data/headshots/). These are computer-generated portraits, not derived from any real individual, and are not "biometric identifiers" under 740 ILCS 14/10.
• Candidate names, email addresses, phone numbers, work history, certifications, or any other non-biometric personal information. These are governed by the general PII retention policy referenced in the SubjectManifest substrate (see docs/specs/SUBJECT_MANIFESTS_ON_CATALOGD.md).

---

2. Categories collected

Category	Source	Storage location
Photograph (raw bytes)	Candidate upload via the consent-gated photo endpoint	Quarantined under data/biometric/uploads/<candidate_id>/<ts>.<ext>; encrypted at rest
Facial geometry classifications	deepface inference run against the photograph	subjects.biometric_classifications (JSONB on the identityd subjects row)
Photograph integrity hash	SHA-256 of the original bytes	subjects.biometric_template_hash

We do NOT collect raw biometric template vectors that could be used to re-derive a face from the encoded form. The deepface output is stored as discrete classification labels (e.g. {"age_estimate": 32, "gender": "...", "race": "..."}), not as a re-identifiable embedding.

---

3. Purpose of collection

Photographs and the classifications derived from them are used for:

1. Identity matching during staffing operations. When a worker arrives at a job site, the assigned coordinator may verify identity by comparing the on-file photograph against the person present.
2. Internal record-keeping. Photographs become part of the worker record so coordinators can recognize repeat workers across multiple placements.

Photographs and biometric classifications are NOT used for:

• Demographic targeting in role recommendations (Title VII / IL Human Rights Act compliance).
• Training of any machine-learning model.
• Sharing with third parties, except as required by court order or with the candidate's separate written consent.
• Any purpose beyond those enumerated in §3.1-3.2 above.

---

4. Retention period

Per 740 ILCS 14/15(a), biometric identifiers and biometric information must be permanently destroyed when the initial purpose for collection has been satisfied OR within three (3) years of the individual's last interaction with the private entity, whichever occurs first.

Operational ceiling: Lakehouse retains biometric data for a maximum of eighteen (18) months from the candidate's last placement or last system interaction, whichever is later. This is more restrictive than the BIPA statutory ceiling and provides a safety margin against accidental over-retention.

The 18-month clock is enforced by the daily retention sweep (crates/catalogd/src/bin/retention_sweep.rs), which checks SubjectManifest.consent.biometric.retention_until on every subject and routes overdue subjects to the destruction queue (see Gate 5 runbook).

⚖ COUNSEL — confirm the 18-month operational ceiling is appropriate for the deployment posture, or specify a different number.

---

5. Destruction procedure

Per 740 ILCS 14/15(a), Lakehouse follows the BIPA Destruction Runbook (docs/runbooks/BIPA_DESTRUCTION_RUNBOOK.md) when:

• Retention period under §4 expires
• Candidate withdraws biometric consent under the consent template (Gate 2)
• Candidate exercises a right-to-be-forgotten request
• An identityd POST /v1/identity/subjects/{id}/erase is invoked under legal-tier authentication

Every destruction event is recorded as an append-only audit row in the affected subject's per-subject HMAC-chained audit log (see crates/catalogd/src/subject_audit.rs), providing tamper-evident proof of compliant destruction.

---

6. Versioning

This schedule is version v1. Future revisions:

• Require a new version number (v2, v3, ...).
• Are committed to the repository with a git history showing the revision date.
• Are referenced by SHA-256 hash from consent_versions table rows in identityd, so each subject's consent record points unambiguously at the schedule version that was in force when consent was given.

v1 SHA-256: generated at deployment time by scripts/staffing/hash_consent_v1.sh (to be added when this schedule is finalized by counsel)

---

7. Public availability

⚖ COUNSEL — specify the public URL where this schedule will be published (typically the privacy policy page on the deployment site) and the disclosure language that links candidates to it from the intake UI.

---

8. Authority

This schedule is adopted under the authority of J (operator of record) and reviewed by ⚖ COUNSEL. Effective date: TBD pending counsel sign-off.

Role	Name	Signature	Date
Operator	J	_______________	_____
Outside counsel	_____________	_______________	_____