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>
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:
- Identity verification at staffing job sites
- 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.
4. Consent acknowledgment
By signing below (electronically or on paper), I acknowledge that:
- I have read and understood the disclosures in §1-3 above
- I am providing this consent voluntarily and free of coercion
- 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 | _____________ | _______________ | _____ |