lakehouse/docs/counsel/COUNSEL_HANDOFF_EMAIL_2026-05-05.md

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:

   ./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:

   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.