phase 1.6: lock Gate 3b = C, reconcile docs to shipped state, fix double-upload file leak
Four threads landing together — all driven by the audit J asked for before
production cutover.
(1) Gate 3b DECIDED: Option C (defer classifications). `BiometricCollection.classifications`
stays `Option<JSON> = None` in v1. `docs/specs/GATE_3B_DEEPFACE_DESIGN.md` status
flipped from "draft / awaits product" to DECIDED. Consent template + retention
schedule revised to remove all "automated facial-classification" / "deepface"
language so disclosed scope matches implemented scope.
(2) Endpoint-path drift reconciled across 3 docs. `PHASE_1_6_BIPA_GATES.md`,
`BIPA_DESTRUCTION_RUNBOOK.md`, and `biometric_retention_schedule_v1.md` had
references to legacy `/v1/identity/subjects/*` paths (proposed under a separate
identityd daemon, never shipped) — corrected to actual shipped routes
`/biometric/subject/*` (catalogd-local). Schema block in PHASE_1_6_BIPA_GATES
rewritten to reflect JSON `SubjectManifest.biometric_collection` substrate
(not the proposed Postgres `subjects` table).
(3) New operational artifacts:
- `scripts/staffing/verify_biometric_erasure.sh` — checks 4 things post-erasure
(manifest cleared, uploads dir empty, audit row matches, chain verified).
Smoke-tested live against WORKER-2.
- `scripts/staffing/biometric_destruction_report.sh` — monthly anonymized
destruction-event aggregation. Smoke-tested clean.
- `scripts/staffing/bundle_counsel_packet.sh` — tarballs the counsel-review
packet with per-file SHA-256 manifest.
- `docs/runbooks/LEGAL_AUDIT_KEY_ROTATION.md` — formal rotation procedure
operationalized after the 2026-05-05 /tmp wipe incident.
- `docs/counsel/COUNSEL_REVIEW_PACKET_2026-05-05.md` — cover note bundling
all eng-staged BIPA docs for counsel review with per-doc questions, sign-off
checklist, recommended review sequence.
(4) Double-upload file leak fixed in `crates/catalogd/src/biometric_endpoint.rs`.
`verify_biometric_erasure.sh` smoked WORKER-2 and surfaced a stranded photo
file. Investigation showed the file was 13-byte test-fixture bytes (zero PII,
no biometric content); audit timeline showed two consecutive uploads followed
by one erasure — the second upload had silently overwritten manifest.data_path,
orphaning the first file. Patched `process_upload` to refuse a second upload
with HTTP 409 + `error: "biometric_already_collected"` when
`biometric_collection.is_some()` on the manifest. Operator must explicitly
POST `/biometric/subject/{id}/erase` first.
Tests: new `second_upload_without_erase_returns_409` (asserts 409 + manifest
pointer unchanged + first file untouched on disk). Replaced
`repeated_uploads_grow_the_chain` with `upload_erase_upload_grows_the_chain_cleanly`
(covers the legitimate re-collection cycle: chain grows to 3 rows). Updated
`content_type_with_parameters_accepted` to use 2 distinct subjects (was
using 1 subject with 2 uploads to test ct parsing — would now 409).
22/22 biometric_endpoint tests + 59/59 catalogd lib tests green post-patch.
Production posture: gateway needs `cargo build --release -p gateway` +
`systemctl restart lakehouse.service` to pick up the new 409 in live traffic.
Counsel calendar is now the only remaining blocker for first real-photo intake.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -3,6 +3,7 @@
|
||||
**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)
|
||||
**Updated 2026-05-05:** Disclosure 1 + plain-language summary revised to match the Gate 3b deferral recommendation in `docs/specs/GATE_3B_DEEPFACE_DESIGN.md` (Option C — defer classifications). Pending J's product confirmation of Gate 3b; if Gate 3b chooses Option A or B, this template needs counsel re-authoring.
|
||||
|
||||
> This is the consent template a candidate signs (electronically or
|
||||
> on paper) BEFORE Lakehouse collects, stores, or processes any
|
||||
@@ -25,11 +26,12 @@ 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).
|
||||
Lakehouse will collect and store my **biometric identifier** (a
|
||||
photograph of me from which facial geometry is implicit). The
|
||||
photograph itself is the data we keep — we do NOT run automated
|
||||
facial-classification (gender / race / age inference) against it
|
||||
in v1. If at a later date we add automated classification, we will
|
||||
re-collect consent under a superseding template before doing so.
|
||||
|
||||
### Disclosure 2 — Specific purpose and length of term (§15(b)(2))
|
||||
|
||||
@@ -66,9 +68,9 @@ 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.
|
||||
> we'll keep that photo so your staffing coordinator can recognize
|
||||
> you when you arrive at job sites. We don't run automated guesses
|
||||
> about your age, gender, or race against the photo.
|
||||
>
|
||||
> **How long we keep it:** at most 18 months after your last
|
||||
> placement or interaction with us, then it's permanently destroyed.
|
||||
|
||||
Reference in New Issue
Block a user