phase 1.6 BIPA gates — engineering wave (4 of 7 staged)

Per docs/PHASE_1_6_BIPA_GATES.md. Status table now reflects:

  DONE (engineering-only, no counsel dependency):
  - Gate 4: name→ethnicity inference removed from mcp-server.
    Removal note in search.html:3372 + new Bun absence test
    (mcp-server/phase_1_6_gate_4.test.ts) with 3 assertions:
    walker actually scans files, regex catches synthetic positives,
    no offending DEFINITION patterns in any .html/.ts/.js source.
    3/3 pass.

  ENG-DONE, signature pending:
  - §2 attestation: scripts/staffing/attest_pre_identityd_biometric_state.sh
    runs three checks against the live state:
      1. workers_500k.parquet schema has no biometric/photo/face/image col
      2. data/_kb/*.jsonl + pathway state contain no base64 image magic
         bytes (JPEG /9j/, PNG iVBOR), no data:image/* MIME prefixes,
         no field-name patterns ("photo", "biometric", "deepface_*")
      3. data/headshots/manifest.jsonl is entirely synthetic-tagged
    3/3 evidence checks pass on the live data dir. Generates a
    signed-by-operator+counsel attestation document committed at
    docs/attestations/BIPA_PRE_IDENTITYD_ATTESTATION_2026-05-03.md
    with SHA-256 of the evidence summary so post-signature tampering
    is detectable.

  ENG-STAGED, awaiting counsel review:
  - Gate 1 retention schedule scaffold at
    docs/policies/consent/biometric_retention_schedule_v1.md (BIPA
    §15(a)). Engineering facts (categories, 18-month operational
    ceiling vs 3-year statutory cap, destruction procedure pointer
    to Gate 5 runbook) plus ⚖ COUNSEL markers for the binding text.
  - Gate 2 consent template scaffold at
    docs/policies/consent/biometric_consent_template_v1.md (BIPA
    §15(b)(1)-(3)). Required disclosures + plain-language summary +
    withdrawal procedure + the structured fields the consent UI must
    post to identityd.
  - Gate 5 destruction runbook at docs/runbooks/BIPA_DESTRUCTION_RUNBOOK.md.
    Triggers, pre-destruction checks (incl. chain-verified gate via
    /audit/subject/{id}), procedure (legal-tier endpoint), automatic
    audit row append (subject_audit.v1 with kind=biometric_erasure),
    backup-window disclosure, monthly reporting cadence, audit-trail
    attestation procedure cross-referencing the cross-runtime parity
    probe.

  BLOCKED on engineering design:
  - Gate 3 photo-upload endpoint. Requires identityd photo intake
    design + deepface integration scope. Deferred to its own session.

  DEFERRED:
  - §3 employee training material. Gate 5 runbook §7 may serve as
    substrate; counsel decides whether a separate program is needed.

Calendar bottleneck is now counsel review. Engineering can stage no
further deliverables until either (a) Gate 3's design conversation
happens or (b) counsel completes review of items 1/2/5/6.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/policies/consent/biometric_consent_template_v1.md

@@ -0,0 +1,173 @@
+# 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@<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:
+
+```json
+{
+  "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 | _____________ | _______________ | _____ |

docs/policies/consent/biometric_retention_schedule_v1.md

@@ -0,0 +1,150 @@
+# 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 | _____________ | _______________ | _____ |