lakehouse/docs/PHASE_1_6_BIPA_GATES.md

Phase 1.6 — BIPA Pre-Launch Gates

Status: Draft — 2026-05-03 · Owner: J + outside counsel · Companion to: AUDIT_TRAIL_PRD.md, AUDIT_PHASE_1_5_BIPA_AND_OUTCOMES.md, IDENTITY_SERVICE_DESIGN.md

Why this exists. IDENTITY_SERVICE_DESIGN.md v3 §5 Step 0 names Phase 1.6 as a HARD PREREQUISITE: identityd backfill cannot start until Phase 1.6 ships. This doc specifies what Phase 1.6 contains.

Scope. BIPA (740 ILCS 14) compliance gates that must be in place BEFORE the system accepts a single real candidate photo. Synthetic-data face pool can keep operating; real-photo intake CANNOT begin without these gates.

Authority. This is an engineering scaffold. Sections marked ⚖ COUNSEL need outside counsel to author the actual legally-binding text. Engineering ships the procedural gates; counsel writes the words.

---

1. The five BIPA pre-launch gates

Each gate is a deliverable that must ship before real-photo intake. None is optional. Order shown is the recommended ship sequence.

Gate 1 — Public retention schedule (BIPA §15(a))

Required: A publicly-available, written retention schedule for biometric identifiers and information.

What ships:

• docs/policies/consent/biometric_retention_schedule_v1.md — public file
• Linked from public privacy policy at the deployment URL
• Specifies:
  • Categories of biometric data collected (facial photograph for staff identification at job sites; classifications deferred per Gate 3b — see docs/specs/GATE_3B_DEEPFACE_DESIGN.md)
  • Purpose of collection (identity matching for staffing operations)
  • Maximum retention: BIPA §15(a) caps at "3 years from the individual's last interaction with the private entity, whichever occurs first" — recommend 18-24 months as the operational ceiling (provides safety margin)
  • Destruction procedure: per Gate 5 below
• Versioned (this is v1; future updates supersede with a new version)

⚖ COUNSEL — write the actual schedule. Engineering provides the operational facts; counsel writes the binding language.

Engineering acceptance: the file is committed, the public URL renders it, and identityd's consent_versions table references it by hash.

---

Gate 2 — Informed written consent (BIPA §15(b))

Required: Informed, written consent BEFORE any biometric collection occurs.

What ships:

• docs/policies/consent/biometric_consent_template_v1.md — public consent template
• Versioned, hashed, referenced from identityd's consent_versions table
• Must disclose, per BIPA §15(b)(1)-(3):
  1. That biometric identifiers/information will be collected
  2. The specific purpose for collection (and the length of term — references Gate 1)
  3. Receipt of a written release authorizing collection
• Consent flow at intake:
  • Candidate sees the disclosure on a UI surface (web form / paper / digital signature)
  • Candidate provides explicit affirmative action (signature, click-acceptance with timestamp, etc.)
  • Identityd records biometric_consent_status='given' with consent_version reference + consent_given_at timestamp
  • Without identityd recording 'given', no biometric data flows through deepface.

⚖ COUNSEL — write the consent template. Recommended content (engineering view):

• Clear language (not just legal boilerplate)
• Specific to facial-classification (not generic biometrics)
• Includes withdrawal procedure
• Includes data-subject rights enumeration

Engineering acceptance: consent gate is enforced in code at the photo-upload endpoint; identityd refuses biometric writes when biometric_consent_status != 'given'; pre-existing synthetic-face pool is exempt (no consent needed because no real subject).

---

Gate 3 — Photo-upload endpoint with consent enforcement

Required: Code-level enforcement that real-photo intake checks consent before processing.

What ships:

An endpoint at POST /biometric/subject/{candidate_id}/photo (catalogd-local — the original v1 spec named this /v1/identity/subjects/{candidate_id}/photo under a separate identityd daemon; that daemon was collapsed into catalogd per the architecture pivot. See IDENTITY_SERVICE_DESIGN.md deprecation header.) with the following behavior:

1. Caller authenticates with service-tier token
2. Endpoint queries identityd for subjects.biometric_consent_status
3. If status ≠ 'given' → HTTP 403 with reason "BIPA consent required before biometric processing"
4. If status = 'given': a. Photo bytes accepted, stored to a quarantined path under data/biometric/uploads/{candidate_id}/{ts}.{ext} (NOT data/headshots/) b. deepface tagging runs against the photo c. Classifications (gender, race, age) — DEFERRED to Gate 3b (docs/specs/GATE_3B_DEEPFACE_DESIGN.md). BiometricCollection.classifications remains None in v1. d. Original photo bytes encrypted under DEK + retained per Gate 1 schedule e. pii_access_log row written with purpose_token='biometric_collection'
5. Response: {candidate_id, retention_until, consent_version}

Schema (as shipped — catalogd SubjectManifest.biometric_collection):

The original spec proposed JSONB columns on a Postgres subjects table under identityd. The shipped implementation collapses this into a per-subject JSON manifest at data/_catalog/subjects/<id>.json, with the BiometricCollection struct holding data_path, template_hash, collected_at, and classifications: Option<JSON>. See crates/catalogd/src/subject_manifest.rs for the canonical type.

// crates/catalogd/src/subject_manifest.rs (paraphrased)
pub struct BiometricCollection {
    pub data_path: String,                // quarantined path
    pub template_hash: String,            // SHA-256 of original bytes (integrity, NOT re-derivation)
    pub collected_at: DateTime<Utc>,
    pub classifications: Option<Value>,   // None until Gate 3b ships (deferred — see GATE_3B_DEEPFACE_DESIGN.md)
}

Engineering acceptance:

• Endpoint refuses uploads when consent missing (verified by integration test)
• deepface output never lands in the synthetic-face manifest (data/headshots/manifest.jsonl)
• Real-photo classifications are isolated to identityd subjects table — never flow to JSONL sinks
• The /headshots/:key route in mcp-server REMAINS synthetic-only — does NOT serve real candidate photos to LLMs without an explicit allowance (proposed: real photos served only to authenticated staffer UI, never to model context)

---

Gate 4 — Deprecate name → ethnicity inference

Required: The hard-coded NAMES_HISPANIC / SURNAMES_* lookup tables in mcp-server/search.html:3375-3432 (per Phase 1.5 §1B walk) get removed.

What ships:

• A code commit that removes:
  • FEMALE_NAMES, MALE_NAMES constants
  • NAMES_HISPANIC, NAMES_BLACK, NAMES_SOUTH_ASIAN, NAMES_EAST_ASIAN, NAMES_MIDDLE_EASTERN constants
  • SURNAMES_HISPANIC, SURNAMES_SOUTH_ASIAN, SURNAMES_EAST_ASIAN, SURNAMES_MIDDLE_EASTERN, SURNAMES_BLACK constants
  • The genderFor() and guessEthnicityFromFirstName() functions
  • All call sites that consumed these (face-pool bucket selection)
• Replacement strategy:
  • For SYNTHETIC face pool routing: deterministic hash of candidate_id selects a face bucket, no demographic inference
  • For REAL candidate photos: the candidate's actual photo IS the representation; no inference needed

Why this is BIPA + Title VII risk separately: name-based ethnicity classification is BOTH a discriminatory feature engineering practice (Title VII) AND, when combined with photo-based attribute extraction, a "biometric information derived from a biometric identifier" pattern (BIPA broad reading). Removing the lookup tables forecloses both arguments.

Engineering acceptance:

• Lookup tables removed from search.html
• Unit test asserts no protected-attribute inference functions exist in search.html or any mcp-server module
• Face-pool routing for synthetic faces uses candidate_id hash exclusively
• Phase 1.5 §1B finding closed

---

Gate 5 — Documented destruction procedure

Required: A written procedure for biometric data destruction at retention expiry OR consent withdrawal OR right-to-be-forgotten request.

What ships:

• docs/runbooks/BIPA_DESTRUCTION_RUNBOOK.md — operator-facing
• Specifies:
  • Triggers: retention expiry (per Gate 1), withdrawal, RTBF request, candidate request
  • Procedure: catalogd-local POST /biometric/subject/{id}/erase (legal-tier auth) — formerly proposed under identityd; now serves from catalogd directly
  • Erasure scope: BiometricCollection set to None on the subject manifest (drops data_path, template_hash, classifications together), quarantined photo files at data/biometric/uploads/<id>/* securely unlinked, audit row appended BEFORE photo unlink so the chain proves intent even if file delete fails
  • Backup window: per IDENTITY_SERVICE_DESIGN v3-B12, residual exists in DB backups for 30 days max; subject is informed
  • Witnessed: every erasure event written to pii_access_log with purpose_token='biometric_erasure' and the legal-tier JWT signature (proves authorized destruction)
  • Reporting: monthly internal report of erasures + retention-expiry sweeps; available to counsel on request

⚖ COUNSEL — review the runbook for legal sufficiency. Engineering writes the procedure; counsel attests that the procedure satisfies BIPA §15(a) destruction requirements.

Engineering acceptance:

• Runbook committed
• POST /biometric/subject/{id}/erase endpoint includes biometric-specific erasure path (shipped 848a458 — 21 unit tests, two scopes: biometric_only / full)
• Daily sweep job destroys biometric data past biometric_retention_until (separate from general retention sweep — biometric has stricter clock)
• Erasure events are logged with cryptographic attestation

---

2. Cryptographic attestation: no biometric data exists pre-identityd

Per IDENTITY_SERVICE_DESIGN v3-B11. Plaintiffs may argue that the EXISTENCE of biometric schema fields constitutes constructive notice of intent to collect biometric data — therefore consent should have preceded the schema. The defense: prove that no biometric data was actually collected from real candidates before identityd + the consent gate.

What ships:

• A one-shot script scripts/staffing/attest_pre_identityd_biometric_state.sh that:
  • Queries data/datasets/workers_500k.parquet schema and confirms NO column named photo, biometric_*, face_*, image_* exists
  • Greps data/_kb/*.jsonl and data/_pathway_memory/state.json for any base64-encoded image bytes (deepface output, photo blobs)
  • Verifies data/headshots/manifest.jsonl rows ≤ synthetic face pool size
  • Hashes the schema + summary; commits the hash to S3 Object Lock (per identity service v3 anchor pattern)
• Attestation document docs/BIPA_PRE_IDENTITYD_ATTESTATION_2026-05-XX.md signed by J + outside counsel

This is a one-time defense artifact. It establishes the baseline: "as of this date, no biometric data was collected from real candidates."

---

3. Employee training acknowledgment (general BIPA hygiene)

Required: People with access to biometric data acknowledge BIPA-handling training.

What ships:

• docs/policies/BIPA_HANDLING_TRAINING_v1.md — training material covering:
  • What constitutes biometric identifiers / information
  • The consent + retention procedures
  • Destruction obligations
  • Reporting suspected exposure
• Acknowledgment record per individual (initially: J + counsel + named operators)
• Annual refresh

⚖ COUNSEL — write training content. Engineering doesn't author legal-compliance training.

---

4. Phase 1.6 exit criteria (gates Phase 2 backfill)

All 5 gates must be DONE before identityd backfill begins. Status as of 2026-05-03 — scaffolds vs. counsel sign-off vs. shipped code:

#	Gate	Engineering	Counsel	Status
1	Public retention schedule	scaffolded at docs/policies/consent/biometric_retention_schedule_v1.md	pending	eng-staged
2	Consent template	scaffolded at docs/policies/consent/biometric_consent_template_v1.md	pending	eng-staged
3	Photo-upload endpoint with consent enforcement	DONE — crates/catalogd/src/biometric_endpoint.rs mounted at /biometric/subject/{id}/photo, 11 unit tests, live-verified end-to-end. Gate 3b DECIDED 2026-05-05: Option C (defer classifications). BiometricCollection.classifications stays Option<JSON> = None in v1; consent + retention docs revised to match. See docs/specs/GATE_3B_DEEPFACE_DESIGN.md §6 + change log.	reviewed under Gate 2 (matching consent text)	DONE — 3a shipped, 3b deferred per design doc
4	Name → ethnicity inference removed	DONE — mcp-server/search.html:3372 removal note + mcp-server/phase_1_6_gate_4.test.ts absence test (3/3 green)	none required	DONE
5	Destruction runbook	scaffolded at docs/runbooks/BIPA_DESTRUCTION_RUNBOOK.md; erasure endpoint + verify/report scripts marked TODO	pending	eng-staged

PLUS:

#	Item	Engineering	Counsel	Status
6	Cryptographic attestation pre-identityd	DONE — scripts/staffing/attest_pre_identityd_biometric_state.sh + docs/attestations/BIPA_PRE_IDENTITYD_ATTESTATION_2026-05-03.md (3/3 evidence checks pass; signature lines pending)	pending signature	eng-DONE, signature-pending
7	Employee training material	scaffold deferred — Gate 5 runbook §7 acknowledgment may serve as substrate	pending	deferred

Blocking set for Phase 2 backfill: items 1, 2, 3, 4, 5, 6 must all be DONE. Item 7 (employee training) is reduced from blocking to "deferred" because the Gate 5 destruction runbook §7 already requires operator acknowledgment before legal-tier credentials are issued — that acknowledgment is procedurally equivalent to the training-record requirement when the operator population is small (J + 1-2 named operators). If the operator population grows beyond that, item 7 re-promotes to blocking and a separate training program must be authored.

⚖ COUNSEL — confirm whether item 7 deferral is acceptable for the expected operator population size, or restore it to the blocking set.

Calendar bottleneck: Items 1, 2, 5, 6 (and #7) await counsel review of the engineering scaffolds. Gate 3 substrate is fully shipped; Gate 3b deepface classification was DECIDED on 2026-05-05 as Option C (defer) — BiometricCollection.classifications stays None in v1, consent + retention docs revised to match this narrower scope. If a future product requirement surfaces a real need for classifications, the substrate is forward-compatible (Option<JSON>) and either Option A (~1 day) or Option B (~5 days) of the design doc can be picked up then under a v2 consent template.

---

5. Effort estimate

Gate	Engineering effort	Legal effort
Gate 1 (retention schedule)	0.5 day	counsel-dependent (typically 1-2 weeks for review)
Gate 2 (consent template)	0.5 day	counsel-dependent (typically 2-4 weeks for review and consent UX design)
Gate 3 (photo-upload endpoint)	1-2 days	review of endpoint behavior
Gate 4 (deprecate name-ethnicity inference)	0.5 day	none (engineering-only fix)
Gate 5 (destruction runbook)	1 day	counsel sign-off
§2 cryptographic attestation	0.5 day	counsel + J signature
§3 employee training	0.25 day (admin)	counsel-authored content
Total engineering	~4-5 days	—
Total counsel	—	~3-6 weeks calendar (review cycles)

The calendar bottleneck is counsel, not engineering. Engineering can stage all 5 gates ready-to-ship in a week. Counsel sign-off + consent UX rollout is the longer pole.

---

6. Open questions for J + counsel

1. Photo-upload UX: is there an existing intake form / staffer console where photo upload would happen? Or is this new UI work?
2. Consent collection mechanism: electronic signature service (DocuSign, Adobe Sign), in-app click-acceptance, paper form? Each has different evidentiary weight in litigation.
3. Operator list with biometric access: who, today, would be on the named-operators list for §3 training?
4. Counsel for sign-off: named outside counsel — same or different from the dual-control legal-token party in identity service?
5. Public privacy policy URL: does one exist? If yes, where; if no, that's a separate Gate-1.5 deliverable.

---

6.5. Post-signature deployment runbook

When counsel returns the countersigned consent template + retention schedule, the engineering side of "flip from permissive to strict mode" is one command:

# 1. Counsel commits their signature to §7 of the consent template
#    markdown (or J commits the signed PDF + updates §7 with counsel's
#    name + date). The markdown is the BINDING TEXT — the PDF is just
#    a rendering of it.

# 2. Hash the canonical signed text + seed the gateway allowlist.
./scripts/staffing/seed_consent_version.sh \
    docs/policies/consent/biometric_consent_template_v1.md \
    --label "v1 signed YYYY-MM-DD by [counsel name]"

# The script:
#   - computes SHA-256 of the markdown (binding text)
#   - atomically writes /etc/lakehouse/consent_versions.json with
#     the new hash + per-seed audit metadata (timestamp, label,
#     source path)
#   - restarts lakehouse.service so the gateway re-reads the
#     allowlist
#   - probes /biometric/health for clean restart

# 3. Verify strict mode is rejecting unknown hashes:
TOKEN=$(cat /etc/lakehouse/legal_audit.token)
curl -sS -X POST http://localhost:3100/biometric/subject/WORKER-1/consent \
    -H "X-Lakehouse-Legal-Token: $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"consent_version_hash":"deadbeefdeadbeef000000000000000000000000000000000000000000000000","consent_collection_method":"electronic_signature","operator_of_record":"strict_mode_probe"}'
# Expect: HTTP 400 + {"error":"consent_version_unknown", ...}

After this, the gateway is in counsel-tier strict mode:

• Any consent grant POST whose consent_version_hash doesn't match a known signed template is refused at intake
• Operator typos (mistyped hash) become loud failures, not silent bad records
• Future template revisions (v2, v3, ...) require counsel re-sign AND a new seed_consent_version.sh run before being accepted — the v1 hash stays in the allowlist for already-collected subjects' audit-trail compatibility

Pre-counsel demo seed

For deployments that want to exercise strict mode BEFORE counsel signs, the same script works against the eng-staged template:

./scripts/staffing/seed_consent_version.sh \
    docs/policies/consent/biometric_consent_template_v1.md \
    --label "eng-staged demo seed (NOT counsel-signed)"

The hash entry should be replaced (rotate the demo hash out, add the counsel-signed hash) when counsel completes review. The allowlist's _meta.seeded_at[] array preserves the seed history.

---

7. What this PRD is NOT

• Not legal advice. The ⚖ COUNSEL markers exist because the binding text needs lawyers, not engineers.
• Not a substitute for a DPIA / PIA. Phase 1.6 satisfies BIPA-specific gates; a Data Protection Impact Assessment is broader and may be required separately.
• Not a SOC2 Type II deliverable. SOC2 is a parallel work stream.
• Not the only gate before production. The full 9-phase audit-trail program continues; Phase 1.6 specifically unblocks Phase 2 (identity service implementation).

---

Change log

• 2026-05-05 — Reconciled with shipped state: endpoint paths corrected from the legacy identityd v1 spec (/v1/identity/subjects/*) to the catalogd-local routes that actually shipped (/biometric/subject/*). Schema block rewritten to reflect the JSON SubjectManifest.biometric_collection substrate that replaced the proposed Postgres columns. Gate 3b deepface deferral marked in-line where Disclosure 1 / Gate 3 step 5c / Gate 5 erasure scope previously assumed classifications were collected. No legal text changed; this was doc/code drift cleanup.
• 2026-05-03 — Initial draft. Authored after IDENTITY_SERVICE_DESIGN v3 §5 Step 0 named Phase 1.6 as a hard prerequisite to backfill.