lakehouse/docs/policies/consent/biometric_consent_template_v1.md
root 4708717f6b 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>
2026-05-03 04:38:49 -05:00

6.2 KiB

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.

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.


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