Skip to content

Counsel Queue

A single, consolidated list of every question that needs qualified legal/privacy counsel. We do not pause engineering for these. We build on the documented working assumption in each item; counsel later ratifies or corrects the whole pile in one pass. This file is the lawyer hand-off pack, not an execution blocker list.

How to read each item: Q = the question for counsel; Working assumption = what we are building to in the meantime (so counsel confirms/adjusts rather than starts from blank); Ties = the control/doc it governs.

Status of this queue: open — accumulating. Last updated 2026-07-04 (C20 refresh + C29 added, dataroom PR-12).

Nothing here blocks engineering. If an item's working assumption turns out wrong, it becomes a change request against the named control, not a redo.

Operating rule: whenever director or executor work finds a counsel-sensitive point, add or update an item here, state the working assumption in the PR spec/notes or readiness doc, and keep going. Pause only if the operator explicitly asks, real-user launch is imminent, a legal/policy document is being published externally, or the work would make an irreversible compliance commitment.

  • C1 — Lawful basis per purpose. Q: Confirm the lawful basis for each processing purpose (auth, matching, messaging, safety, analytics, ML training, marketing). Working assumption: contract for auth/matching/messaging; consent for proximity matching, analytics (T1), and ML training (T2); legitimate interest for safety. Ties: PRIV-02, RoPA, readiness/data-inventory-and-retention.md, policies/privacy-and-retention-policy.md.

  • C2 — Consent validity & granularity. Q: Is a separate, explicitly-revocable opt-in for (a) analytics and (b) ML training valid and sufficient? Can they be presented at onboarding without being "bundled"? Working assumption: three independent toggles — analytics, ML training, marketing — each revocable, versioned to the notice. T1/T2 events do not emit without the matching grant. Ties: PRIV-10, ML-05, readiness/ml-event-taxonomy.md, policies/ai-ml-data-governance-policy.md.

  • C3 — LinkedIn API / platform terms. Q: Is our planned LinkedIn identity + matching + profile-caching use within LinkedIn's API terms? Working assumption: store only OIDC sub, email, name, picture; refresh on login; no connections/graph scraping. Ties: READINESS Q5, subprocessors register, policies/vendor-and-subprocessor-policy.md.

B. Data Subject Rights, Retention & Deletion

  • C4 — Retention durations. Q: Confirm/set retention periods per data class. Working assumption (placeholders, env-configurable, no code change needed to adjust): sessions 30d post-expiry; presences 7d; non-matched candidates 30d; conversations/messages 90d; reports 180d post-resolution; blocks + LinkedIn PII for life of account. Ties: PRIV-03, retention-schedule register, policies/privacy-and-retention-policy.md.

  • C5 — Data subject rights process. Q: Confirm the DSAR process and statutory clocks (access, rectification, erasure, portability, restriction, objection-to-profiling). Working assumption: 1-month response (extendable to 3); identity verification before fulfilment. Ties: PRIV-05, dsar-log register.

  • C6 — Deleted user's sent messages. Q: On erasure, may we tombstone (replace body, keep thread) messages the deleted user sent to a still-active match, rather than hard-delete? Working assumption: tombstone. Ties: PRIV-04, readiness/data-inventory-and-retention.md.

  • C7 — Reports filed against a deleted user. Q: May we retain a report's substance (pseudonymised) after the reported user is erased, for safety/abuse-history purposes? Working assumption: retain pseudonymised for the report retention window. Ties: SAF-02, PRIV-04.

  • C25 — Boarding-pass processing, minimization, lawful basis & retention. Q: Confirm the lawful basis and minimization/retention posture for requiring a verified boarding pass to create presence (PD-012). Boarding passes are sensitive travel data, and airport/route/time combinations can be re-identifying and can imply Art 9 special-category context. Specifically: (a) is barcode decoding of a user-provided pass to derive minimal trip fields defensible under the chosen lawful basis; (b) is "raw image/PDF/barcode is transient and never retained, only minimal normalized trip fields persist" sufficient minimization; (c) any constraints on processing IATA BCBP fields (PNR, name, ticket number) even transiently in memory? Working assumption (engineering proceeds pre-real-user on this): require a boarding pass, decode the barcode in-process, persist only the existing minimal derived flight_presences fields, retain no raw image/PDF/barcode payload, and treat the strict no-raw-retention + banned-field rejection already in code as the minimization baseline. No manual flight entry. OCR is only a label fallback, not the verification source. Infra PR-21 (52cd2c8) implements the backend half of this assumption for authenticated product /presence: require boarding_pass_barcode + document_verified, reject manual/self-reported/ unverified writes, and persist no raw pass artifacts. Mobile PR-15 (a078460) implements the UI/state half: manual presence creation is removed, product surfaces are locked behind active verified-presence checks. Mobile PR-16 (305b387) implements camera barcode scan with on-device BCBP parsing, sanitized confirmation, and document-verified presence creation; raw barcode strings remain transient only and are not stored, logged, shown, or submitted. Mobile PR-17 (c478b26) implements Photos/Files image import with local scanFromURLAsync, shared sanitized confirmation/submission, cache-copy cleanup, and no raw image/barcode storage, logs, navigation params, or API fields. PDFs/non-images are unsupported and fail closed; no server upload, PDF renderer, OCR, share extension, or Wallet pass-library access exists. Mobile PR-18 (075b035) physically verifies the iPhone scan/import/gate/unlock flow using sanitized evidence and a safe synthetic boarding-pass barcode, fixes a camera-preview hard gate, and records no real pass payload, passenger detail, build link, device id, token, or account identifier in Tier 1. Ties: PRIV-06 (minimization), PRIV-02/C1 (lawful basis), C13 (Art 9), RoPA, retention-schedule, product/product-decisions.md PD-012, technical/data-architecture.md.

  • C26 — PDL/ZoomInfo enrichment. Q: Confirm the lawful basis and minimization posture for processing third-party data-broker enrichment data for professional matching. Working assumption: deferred — Partile is not processing broker enrichment data until vendors are contracted and an implementation PR explicitly enables the flow. If later enabled, legitimate interest is the provisional basis, eased by internal-signal-only use, no display to users, no redistribution, and minimization to matching need. Ties: PRIV-13, RoPA, subprocessors, retention-schedule.

  • C28 — Persistent connection records. Q: Confirm retention duration and erasure treatment for professional contacts that outlive the trip window. Working assumption: accepted connection records may persist beyond the trip as durable professional contacts, but hard-delete on account erasure; independent retention duration remains pending counsel. Infra PR-29 (1fbcf6e) makes this concrete through GET /connections, backed by accepted connection_requests and verified as self-scoped, block-aware, and minimized by connections_smoke.py. Ties: PRIV-14, retention-schedule, RoPA.

C. ML / Anonymization (high priority — load-bearing)

  • C8 — Anonymization standard (the gating question). Q: What standard must a training-set snapshot meet to count as anonymous (outside GDPR) rather than pseudonymous — especially for travel-history / movement-trace features, which are highly re-identifying? Is aggregation / k-anonymity / feature-engineering at the training-set boundary sufficient? Working assumption: training sets are built as anonymized snapshots — UUID stripped, quasi-identifiers (airport/gate/time sequences) aggregated or feature-engineered so re-identification is not reasonably possible. Raw trajectories are never treated as anonymized by dropping the UUID alone. Ties: ML-07, ML-04, readiness/ml-event-taxonomy.md, policies/ai-ml-data-governance-policy.md. Blocks nothing now; build the anonymization-boundary PR on this working assumption and leave counsel to ratify or correct it later. Infra PR-20 (9e828db) implements the technical boundary on that assumption: T2-only, whitelisted, k-anonymous aggregate snapshots with low-k suppression and no direct actor/object identifiers.

  • C9 — Model non-deletion on erasure (operator decision; confirm defensibility). Q: Confirm that models trained on properly-anonymized snapshots are out of erasure scope and need not be deleted or retrained when a user is erased — provided erasure propagates fully to the upstream pseudonymized event store. Operator decision (2026-06-07): we do not delete or retrain models on erasure; erasure propagates only to the pseudonymized event store; models train only on anonymized snapshots. Counsel to confirm this holds (incl. that the model itself does not expose individuals via memorization / membership inference). Infra PR-20 provides the technical snapshot boundary; no real model has been trained. Ties: ML-07, decision log.

  • C10 — Event tier mapping. Q: Confirm the T0/T1/T2 classification — in particular that match lifecycle events and connection events are correctly tiered: PR-24 currently emits connection.requested as T1 and connection.accepted / connection.declined as T2, and safety/abuse events (block/report) are excluded from ML entirely. Working assumption: as written in the taxonomy. Ties: ML-01, ML-03.

  • C11 — Automated decision-making (Art 22). Q: Does algorithmic match proposal at an airport constitute a decision with "legal or similarly significant effect" requiring Art 22 safeguards? Working assumption: keep a human/consent element (user approves each match), so no fully-automated significant decision. Ties: ML-10.

  • C12 — Bias/fairness obligations. Q: What fairness review/documentation is required for the matching model before public launch? Working assumption: bias/fairness review + model cards by M5. Ties: ML-08, ML-09.

  • C27 — AI/LLM processing of profiles. Q: Confirm transparency obligations for automated processing of profiles for match rationale and the optional AI interview, confirm the flow is not an Art 22 solely automated decision with legal or similarly significant effect, and confirm training-data boundaries for any LLM/provider processing. Working assumption: the provider is Anthropic Claude API. Two backend integrations are now implemented but live only when ANTHROPIC_API_KEY is set: infra PR-27 (e43b60c) cached match rationale via Claude Haiku 4.5, and infra PR-28 (d2db03f) advisory profile interview via Claude Sonnet 4.6 structured output. They are assistive product features with human choice at every meaningful step; they require clear transparency, no-training/provider controls, minimization (rationale sends display name/headline/intent tags only; interview sends bounded role/content turns only; never email, raw identifiers, raw boarding-pass data, broker enrichment, or secrets), and bounded response/cache controls before real-user launch. The interview suggestion is not automatically written to the profile, and the features are not treated as solely automated significant decisions. Ties: GOV-06, ML taxonomy.

D. Special Category Data (Art 9)

  • C13 — Art 9 leakage & constraint scope. Q: Confirm our day-one constraint — no inference or optimization on special-category attributes — adequately addresses Art 9 risk from LinkedIn headlines and airport/route data (which can imply religion, politics, health, sexual orientation). Any positive obligations beyond "don't infer it"? Working assumption: exclude special-category inference from the feature space; do not derive or store protected attributes. Ties: ML-02, policies/ai-ml-data-governance-policy.md.

E. International / Residency

  • C14 — Jurisdictions in scope. Q: Which jurisdictions for first live airport and first multi-country launch? Working assumption: UK/EU first (drives UK GDPR posture). Ties: READINESS Q1.

  • C15 — Transfers & data residency. Q: Do we need EU/UK data residency, and what transfer mechanism (SCCs/IDTA) before multi-country launch? Working assumption: decide before M4; single-region to start. Ties: PRIV-11, READINESS Q4.

F. Trust, Safety, Minors, Law Enforcement

  • C16 — Minimum age & enforcement. Q: What minimum age, and how enforced (Art 8 / age-appropriate design)? Working assumption: 18+ given stranger-matching + physical proximity; enforcement TBD. Ties: PRIV-12, READINESS Q3.

  • C17 — Physical-safety guidance. Q: What in-app safety guidance/disclaimers are advisable before users move to in-person contact, and any liability implications? Working assumption: pre-first-contact safety copy. Ties: SAF-07.

  • C18 — Law-enforcement / emergency requests. Q: Process and legal thresholds for handling LE/emergency data requests. Working assumption: documented process by M5. Ties: READINESS T&S workstream, procedures/incident-response-playbook.md.

G. Security / Breach

  • C19 — Breach notification. Q: Confirm breach-notification obligations and the 72-hour ICO clock / Art 34 individual-notification triggers for our data classes. Working assumption: 72h to ICO where risk to individuals; without-undue-delay to individuals where high risk. Ties: SEC-13, incident-log register, policies/incident-response-policy.md.

H. Vendor / Commercial / Documentation

  • C20 — Subprocessor DPAs. Q: DPA terms required for Google Cloud production hosting, Cloudflare production edge/data-room Access, LinkedIn, Anthropic, Apple, Sentry, the flight-data providers (AirLabs primary; AeroDataBox fallback; AeroAPI trial pending — and whether vendors receiving only flight-number+date queries with no user identifier fall under Art 28 at all), and future push/analytics vendors. Z.ai (GLM executor) is a PRC-based vendor: today it processes only source code/specs (no personal data), but any future personal-data exposure in executor context requires an Art 44-49 / UK IDTA transfer analysis FIRST. Working assumption: no DPA is signed anywhere yet (all register rows OPEN as of 2026-07-04); no personal data flows to any vendor beyond the minimized, key-gated Anthropic prompts until counsel closes this item. Ties: GOV-02, subprocessors register, vendor-spend register, policies/vendor-and-subprocessor-policy.md.

  • C21 — DPIA. Q: Scope/sign-off of the DPIA for matching, profiling, messaging, and physical proximity (high-risk processing → Art 35 likely mandatory). Ties: PRIV-09.

  • C22 — Privacy notice, ToS/EULA, App Store privacy labels. Q: Draft/approve the privacy notice v1, terms, and App Store data-safety labels aligned to the data inventory. Ties: PRIV-07, READINESS Legal workstream.

  • C23 — Airport/venue permissions. Q: Any permissions/legal analysis needed to operate matching within airport premises. Ties: READINESS Legal workstream.

  • C24 — Insurance / liability. Q: Liability exposure and insurance for a stranger-matching service with a physical-meeting dimension. Ties: READINESS Legal workstream.

  • C29 — Trip-history persistence (movement profile). Q: The stateful-boarding-pass roadmap implies retaining past flights/ presences beyond the trip window — a movement profile. Lawful basis, retention duration, minimization (which fields survive the window), and DSAR/erasure treatment must be settled before any trip-history feature becomes user-facing. The US + Europe launch scope (2026-07-04) makes this an EU GDPR question as well as UK. Working assumption: NOT built and NOT persisted today; RoPA activity 13 is a stub marked OPEN; no engineering work may persist trip history beyond the existing presence-retention class until this item is answered. Ties: RoPA activity 13, registers/retention-schedule.md, PRIV-03, PRIV-16/PRIV-17 (sourcing-map data-governance controls).