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