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