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

174 lines
6.2 KiB
Markdown

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