# Counsel Handoff — Copy-Paste Email Draft **Date assembled:** 2026-05-05 **Operator of record:** J **Prepared for:** outbound transmission to outside counsel **Tarball:** `reports/counsel/counsel_packet_2026-05-05.tar.gz` **Tarball SHA-256:** see `reports/counsel/counsel_packet_2026-05-05.manifest.txt` > This is a copy-paste-ready email draft. Subject line + body below. > Attach the tarball + manifest before sending. The email frames > what counsel needs to do, by when, and what happens after they > sign — so the calendar bottleneck has no excuse to sit longer > than counsel's actual review time. --- ## Subject line ``` Lakehouse staffing platform — Phase 1.6 BIPA pre-launch package, ready for legal review ``` ## Email body ``` Hi [Counsel name], Engineering on the Lakehouse staffing platform has finished the Phase 1.6 BIPA (740 ILCS 14) pre-launch substrate. Before we begin collecting any real candidate biometric data (photographs), the five engineering-staged documents in the attached package need your review and, where indicated, your signature. What's attached: 1. counsel_packet_2026-05-05.tar.gz — bundled review package 2. counsel_packet_2026-05-05.manifest.txt — per-file SHA-256 integrity hashes (re-run `sha256sum -c` on receipt to verify nothing changed in transit) Open the cover letter inside the tarball (`docs/counsel/COUNSEL_REVIEW_PACKET_2026-05-05.md`) first — it walks through the substrate, the specific items needing your sign-off, and recommended review sequence. Headline asks (in priority order): A. Biometric Retention Schedule v1 — render into binding language, sign as countersigning party. Sets the public retention schedule required by BIPA §15(a). B. Biometric Consent Template v1 — render Disclosures 1-3 into binding consent text, sign. This is the form a candidate signs before any photo is collected. Required by BIPA §15(b)(1)-(3). C. BIPA Destruction Runbook — review for legal sufficiency, attest. Procedural document; engineering wrote the steps, your role is confirming they satisfy BIPA §15(a) destruction. D. Pre-IdentityD Attestation (2026-05-03) — countersign as the legal party. Establishes the boundary that no biometric data was collected before the gates shipped. One-time defense artifact. Item C also references a key-rotation runbook (E in the cover letter) that's lower priority — opine when convenient. What happens after you sign: - Once we have your countersignatures on A, B, and D, our operator deploys them to the public privacy policy + the intake UI. Engineering will hash the canonical signed text of (B) and add that hash to the gateway's consent_versions allowlist file (/etc/lakehouse/consent_versions.json) so the runtime starts refusing any consent record that wasn't signed under the canonical template. (The gateway is currently in permissive mode — accepting any non-empty hash. Strict mode flips on with your signature.) - The runtime gates are already enforcing the consent flow: photo upload refuses 403 unless consent.biometric.status = "given", and the only path to that state is the /biometric/subject/{id}/consent endpoint with a valid consent_version_hash. After your signature, that hash will point at canonical signed text — operator typo-resistant and counsel-defensible. Calendar: - We'd like to begin real-photo intake within [N] weeks. If your review can land within 2-3 weeks of receipt, that keeps us on schedule. If your bandwidth requires longer, please flag — we have eng work to advance independently that doesn't depend on the signatures. Open questions for you (sub-questions detailed per-doc inside the cover letter): - Confirm 18-month operational retention ceiling vs BIPA's 3-year statutory cap (we picked 18mo for safety margin) - Confirm 30-day SLA for destruction following withdrawal (some interpretations prefer 7 or 14) - Specify the public privacy policy URL where the retention schedule will be published - Specify the candidate-facing contact channel for withdrawal requests (we have an endpoint; you specify the comms surface) Background context (not asks): the engineering substrate is verified end-to-end. We've run a live demo of the full lifecycle (consent → photo → withdraw) on a test subject; the audit chain verifies cryptographically; the retention sweep is scheduled daily. No real candidate photos have been collected. The attached pre-identityd attestation has the cryptographic evidence hashes from that pre-collection state. Happy to schedule a call if any of this would be easier to walk through verbally. Thanks, J [contact info] ``` --- ## Operator pre-flight checklist (before sending) Run through this once before clicking send: - [ ] Confirm tarball + manifest are the latest versions (`bundle_counsel_packet.sh` regenerates if needed; current hash is in the manifest sidecar) - [ ] Confirm counsel name is correct (and that the engagement letter or retainer is in place) - [ ] Confirm the [N] weeks calendar target — replace with a real number ("3 weeks" / "by end of June" / etc.) - [ ] Confirm the email goes to counsel's secure channel; if counsel uses a portal, upload there + send a notification email instead - [ ] Save a copy of the sent email + the tarball to operator records — this is itself part of the audit trail of "we asked counsel on [date]" --- ## Post-signature operator runbook (after counsel responds) When counsel returns the signed documents: 1. **Verify integrity.** Run `sha256sum -c manifest.txt` on the returned tarball if counsel returns the bundle; otherwise compare returned signed PDFs against the markdown sources to confirm the binding text matches what counsel reviewed. 2. **Capture the canonical signed text.** Counsel may sign a PDF rendering of the markdown — that's fine, but the BINDING TEXT we hash is the markdown source (counsel commits to git countersigning §7 of the consent template + §8 of the retention schedule). 3. **Compute + seed the consent_version_hash.** Run: ```bash ./scripts/staffing/seed_consent_version.sh \ docs/policies/consent/biometric_consent_template_v1.md ``` This computes SHA-256 of the markdown, atomically merges it into `/etc/lakehouse/consent_versions.json` (creating the file if absent), and offers to restart the gateway. 4. **Verify strict mode is live.** Probe with a known-bad hash: ```bash 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":"deadbeef","consent_collection_method":"electronic_signature","operator_of_record":"smoke"}' | jq ``` Expect HTTP 400 with `error: "consent_version_unknown"`. 5. **Update STATE_OF_PLAY.md** to record the signature event + the hash entry in the allowlist. Counsel-tier deployment is now live. 6. **Sign and anchor the §2 attestation.** Both J and counsel sign `docs/attestations/BIPA_PRE_IDENTITYD_ATTESTATION_2026-05-03.md` and the SHA-256 of the signed markdown is committed to the git history as a tamper-evident anchor. After step 5, the production cutover blocker is closed.