Privacy Counsel Architecture Review Agenda

Drafted: May 5, 2026
Date of meeting: Late May 2026 (target: May 22 or May 27 — confirm with counsel by May 12)
Duration: 4 hours (half-day working session)
Location: Video conference (Zoom or equivalent), with screen sharing
Organizer: Cindy Thoennessen (Product Lead)
Content lead: Seth Shoultes (Lead Architect)
Attendees: Cindy, Seth, outside privacy counsel, Blair (last hour, decisions and sign-off)
Companion to: Phased Plan Rev 2, Friction-Points One-Pager, ADR Template

---

What this meeting is

A 4-hour working session where outside privacy counsel reviews MemberIntel’s architectural decisions on per-tenant isolation, audit logging, secrets management, cross-pollination, and data lifecycle. The goal is for counsel to leave the session with enough understanding to:

1. Draft initial ToS / Privacy Policy / DPA positions in June, grounded in the actual architecture rather than assumptions.
2. Confirm whether the architecture supports a defensible privacy posture for GDPR + CCPA at GA, or surface concerns that Phase 2 must address.
3. Identify any architectural decisions that would benefit from being deliberately revisited based on legal considerations.

This is the substantive review the friction-points one-pager flagged. Engaging counsel only at “ToS drafting” time means Phase 2 is built on architecture counsel hasn’t seen — which produces rework and timeline risk. This meeting front-loads counsel’s input.

The meeting is not a presentation. It’s a working session. Counsel asks questions; Seth shows actual schemas, code structures, IAM policies. Where counsel surfaces a concern, the team either resolves it in-meeting or captures it as a follow-up with a specific owner and deadline.

---

Pre-read package

Sent to counsel 5 business days before the meeting. Counsel reads in advance; the meeting is for discussion, not orientation.

The pre-read package contains:

1. MemberIntel SPEC v1, in full. Counsel needs the product context, not just the privacy sections.
2. SPEC §10 (Compliance & Privacy) and §6.3 (Cross-pollination) highlighted as primary focus.
3. Phased Plan Rev 2, particularly §10 (Compliance) and the cross-functional matrix.
4. ADRs 0003 (Per-tenant isolation), 0007 (Secrets management), 0011 (Cross-pollination security boundary), drafted by send time.
5. Schema design document, particularly the per-customer brain entry structure, the audit log structure, the entitlement table, and the foreign-key relationships that govern data deletion order.
6. A one-page “what we want from this meeting” cover note signed by Cindy and Seth, listing the 3–4 specific decisions or sign-offs the team is seeking.

The cover note matters. Without it, the meeting drifts into general discussion. With it, counsel knows what we’re asking them to weigh in on, and the agenda items track to those asks.

---

Sample cover note (for the package)

To: [Counsel name]
From: Cindy Thoennessen, Seth Shoultes
Date: [Send date]
Re: MemberIntel architecture review — what we're asking from you

This 4-hour session is the substantive architectural review for MemberIntel,
the AI advisor product launching mid-October 2026. We're attaching the SPEC,
the phased plan, three ADRs, and the schema design.

Specifically, we're asking you to weigh in on four decisions:

1. Is shared-schema-with-Row-Level-Security a defensible per-tenant
   isolation posture for the customer base (existing MP operators, scaling
   to 50K free users + 5K Pro), under GDPR and CCPA?

2. Is the cross-pollination boundary (three-roles model + k-anonymity
   floor + content-lead human review) sufficient to enable anonymized
   global brain content from per-customer brain entries with appropriate
   ToS coverage?

3. Are there architectural decisions in the pre-read that you'd want us
   to reconsider before Phase 2 build kicks off June 1?

4. Are the data lifecycle decisions (audit log retention, customer-side
   deletion, cross-pollination consent versioning, refresh-token rotation)
   sufficient as-designed?

If your initial read surfaces concerns, please flag them when you respond
with availability. We'd rather know before the meeting so the agenda can
respond.

Looking forward,
Cindy and Seth

---

The agenda (4 hours)

0. Welcome and orientation (15 min)

Cindy opens, Seth introduces the working format. Confirm everyone has read the pre-read. If counsel has flagged concerns from the pre-read, those re-shape the agenda before continuing.

The meeting facilitator (Cindy) keeps time. Each section has a budget; if discussion runs long, the meeting either trims later sections or surfaces follow-ups for Cindy to schedule outside this session.

1. Per-tenant isolation review (45 min)

Lead: Seth. Reference: ADR 0003.

The core architectural decision counsel needs to understand and defend. Walk-through:

• The shared-schema-with-RLS model in mechanical terms — what RLS does, what FORCE means, how the dual-role pattern works.
• Why this model rather than schema-per-tenant or database-per-tenant. The alternatives section of ADR 0003 is the structure.
• How tenant context is set on every request (middleware, no application code allowed to bypass).
• How the integration test suite verifies isolation on every PR — counsel sees the actual test patterns.
• Where the boundary intentionally crosses (cross-pollination) and how that’s separated structurally.
• Limitations counsel should know about: logical isolation rather than physical, performance noise neighbor risk, customer perception (“are we sharing a database?”).

Decision points:

• Is this posture defensible in GDPR + CCPA contexts as-designed?
• Does the customer-facing language need to characterize this differently than “isolated”? (E.g., “logically isolated by database row-level enforcement, physically shared infrastructure.”)
• Are there enterprise contract terms that would require a different posture (e.g., dedicated database for a specific customer)? If so, when should we plan for that capability?

Output: Counsel’s preliminary view on whether ADR 0003 is sign-offable as-is, with-modifications, or needs reconsideration.

2. Audit logging and data access governance (30 min)

Lead: Seth. Reference: Schema design document, ADR 0006 (Observability).

The audit dataset is what makes the privacy guarantees enforceable in practice — without it, claims about data access are unverifiable.

• The audit BigQuery dataset structure: separate dataset, restricted IAM (write-only from application service accounts, read-only for Cindy and counsel on request, no delete permissions for anyone).
• What gets logged: every tier change, brain edit, cross-pollination promotion, agent action (V1.5+), data export, account deletion, consent flow event, IAM grants/revocations.
• What does NOT get logged: customer data values themselves (only the fact of an event), prompt text, response text. The customer-data-never-in-logs rule.
• Retention: organization-policy-enforced, not just IAM convention.
• Secret access auditing: every Secret Manager read flows to the audit dataset. This is what supports “your Stripe credentials were accessed only by our automated sync worker, on this schedule.”

Decision points:

• Is the audit log scope sufficient to support a regulatory inquiry? (E.g., “show every access to customer X’s data in the last 90 days” — answerable in minutes.)
• Are there events that should be logged but aren’t on the current list?
• Is “life of account” retention defensible under GDPR Article 5 (storage limitation) when paired with the deletion mechanism?

Output: Confirmed audit scope; any additions counsel requires for sign-off.

3. Secrets management and credential lifecycle (30 min)

Lead: Seth. Reference: ADR 0007.

Particularly important because per-customer OAuth tokens (Stripe refresh tokens) give access to customer payment data. Counsel will scrutinize this most carefully.

• The five categories of secrets and why they’re treated differently (system credentials, per-customer OAuth, per-customer signing keys, application signing keys, KMS root keys).
• The KMS hierarchy (separate keys for app-data, secrets, backups, audit) and rotation cadence.
• Per-customer Stripe refresh token lifecycle: connect → encrypt → store in Secret Manager → use → disconnect → destroy → audit log entry.
• The “no human reads production secrets” rule, and the break-glass procedure when an exception is genuinely needed.
• Workload Identity Federation for CI/CD — no service account keys anywhere.

Decision points:

• Is the per-customer OAuth handling defensible? Specifically: refresh-token destruction on customer disconnect, key rotation cadence, audit logging of access.
• Is the break-glass procedure (multi-person approval, audited, rare) acceptable as the only path for human access to production secrets?
• Are 90-day rotation cadences for system credentials and per-customer signing keys appropriate? Does counsel want shorter for any category?

Output: Confirmed secrets posture; any rotation cadence adjustments; break-glass procedure documented and approved.

Break (15 min)

4. Cross-pollination security boundary (45 min)

Lead: Seth. Reference: ADR 0011, SPEC §6.3.

The most architecturally unusual part of MemberIntel and the area where counsel’s input shapes the most. Goes deeper than the prior sections.

• The mechanical flow: per-customer brain entries → eligible-tenant filter → k-anonymity floor → Claude-driven candidate drafting → staging table → content-lead review queue → approve/reject → global brain.
• The three-roles model (cross_pollination_role, candidates_role, content_lead_role) and what each can and cannot access.
• The k-anonymity floor at N=5 customers exhibiting a pattern. How the source-attribution metadata enforces this.
• The content lead’s role as a privacy-review function, not just editorial. What training and tooling supports the re-identification risk judgment.
• Per-customer consent versioning: what the consent flow looks like, what happens when a customer toggles opt-out, what happens to entries already promoted (they don’t retroactively pull — and this needs to be in ToS).
• The asymmetry: k-anonymity at the source plus abstracted Claude drafting plus content-lead review plus automated anonymization checks. Layers, not single points of failure.
• Where the boundary explicitly crosses tenant context, and why this is the only place in the system where it does.
• The audit trail: every cross-pollination run logs eligible tenants, candidates drafted, candidates approved/rejected, the prompt version used, the model version, the reviewer.
• The kill-switch infrastructure for the cross-pollination job specifically.

Decision points (this is the most important section):

• Is the boundary structurally adequate for the privacy commitment in SPEC §6.3?
• Is k-anonymity N=5 the right floor? Counsel may push for higher.
• Is the content-lead role training and review process sufficient — or does counsel want documented training, periodic re-review, or an external audit?
• What ToS language supports this mechanism? Counsel drafts; the architectural review confirms what’s technically true.
• Is the consent versioning sufficient under GDPR purpose-limitation principles?
• Is the V1.5 question (whether agent action data is eligible for cross-pollination) the kind of decision that should require a fresh consent collection, or does the existing consent cover it?

Output: Counsel’s preliminary view on whether ADR 0011 is sign-offable; specific drafting requirements for ToS that the architecture supports.

5. Data lifecycle: deletion, export, retention (30 min)

Lead: Seth. Reference: SPEC §10, ADR 0003 (deletion under shared-schema-RLS), schema design.

The mechanical question of how customer data flows through MemberIntel’s lifecycle — from initial sync through ongoing accumulation through deletion.

• Customer-side deletion pathway: triggered from Settings, deletion job runs, all per-customer secrets destroyed, all per-customer rows deleted, audit log entry written. End-to-end synthetic test demonstrating this works.
• Customer-side data export: CSV/JSON, what’s included, what’s excluded (audit log fact: included; audit log content: not directly included but available on request through a separate gated pathway).
• Audit log handling at deletion time: the fact-of-events log is retained per regulatory requirement; data values referenced in the log are wiped via the deletion job.
• Retention timelines: customer data through life of account; per-customer brain through life of account; audit log per regulatory minimum; backups per separate retention schedule with separate KMS key.
• Cross-pollinated entries: don’t retroactively pull on deletion (as noted above); ToS language must make this clear.

Decision points:

• Is the deletion pathway sufficient under GDPR Article 17 (right to erasure)?
• Is the export pathway sufficient under GDPR Article 20 (data portability)?
• What retention schedule does counsel require for the audit log specifically?
• Is the ToS coverage of cross-pollinated-data-doesn’t-retroactively-pull adequate, or does counsel want stronger language or a different mechanism?

Output: Confirmed lifecycle posture; specific retention numbers; ToS drafting requirements.

6. Open questions and follow-ups (30 min)

Lead: Cindy.

Aggregates the follow-ups surfaced in sections 1–5. Each follow-up gets:

• A specific owner (counsel for legal-drafting items; Seth for technical follow-ups; Cindy for product / process)
• A specific deadline (most should land in early-to-mid June so Phase 2 isn’t blocked)
• A specific definition of “done”

Specific topics to surface here even if not raised in the structured sections:

• ToS / Privacy Policy / DPA drafting timeline. Counsel’s working timeline against the GA target of mid-October.
• The DPA template — does counsel have a template, or are we drafting from scratch?
• GDPR-specific requirements: Article 30 record-keeping, lawful basis documentation, DPIA (Data Protection Impact Assessment) — does the cross-pollination architecture trigger a DPIA requirement?
• CCPA-specific requirements: do-not-sell mechanism (we don’t sell, but the disclosure is required), consumer request handling.
• International data flows: customers in EU, customers in UK, customers in California. The data residency posture (Cloud SQL is regional; KMS is regional).
• Subprocessor list: Anthropic, Stripe, GCP, any others. Counsel needs this for the DPA.
• Customer-side data deletion runbook: counsel reviews the actual procedure, not just the architecture.
• The consent flow at signup — counsel reviews the actual UI design once Cindy has it (probably Phase 3, but flag now).

7. Decisions and sign-off (Blair joins) (45 min)

Lead: Blair, with Cindy and Seth presenting.

Blair joins for the final hour. The team summarizes:

• What was reviewed
• What counsel signed off on
• What follow-ups are open and when they land
• Any architectural decisions that need to be reconsidered before Phase 2

Blair’s role is to make the explicit decisions on:

• Approving any architectural changes counsel is requesting
• Approving the legal workstream timeline
• Approving any budget implications (e.g., if counsel recommends a DPIA, that’s a real cost)
• Confirming Phase 2 can proceed as planned, or signaling that something needs to slip

If counsel raises something material that the team didn’t anticipate, this is the hour where Blair decides the response.

Outputs:

• Documented sign-offs (or list of remaining concerns) per architectural decision area
• Action register of follow-ups with owners and deadlines
• Confirmation that the legal workstream timeline supports GA mid-October
• Any decisions captured in writing for the record

---

What success looks like for this meeting

Three concrete outputs:

1. Counsel’s preliminary architectural sign-off, in writing, captured before May 31. Either (a) approval of the architecture as-designed for ToS / Privacy Policy / DPA drafting, or (b) a specific list of concerns that Phase 2 must address, with priority levels.

2. An action register of follow-ups, with owners and deadlines. Most should land in June so Phase 2 isn’t blocked. Items in the register include the specific ToS language requirements counsel is drafting against, any architectural adjustments the team is making, and any product / process decisions Cindy is owning.

3. A clear path forward for the legal workstream. Counsel knows what they’re drafting toward, when, and what evidence they need from the team. Cindy has a working schedule for ToS / Privacy Policy / DPA drafts that lands them in legal review by Phase 3 and final by Phase 4.

---

What failure looks like

• The meeting becomes a presentation rather than a working session. Counsel asks questions; the team doesn’t have answers; follow-ups balloon. Mitigation: pre-read package thorough; Seth prepared with actual schemas and code structures, not slide decks.

• Counsel raises something material that requires re-architecting. (E.g., “shared-schema-with-RLS isn’t defensible for our customer mix.”) Mitigation: ADR 0003 explicitly argues against the alternatives; if counsel disagrees, that disagreement happens here, not at GA.

• The meeting runs over time and section 6 (follow-ups) gets compressed. Mitigation: Cindy facilitates strictly; section 6 doesn’t get cut even if section 4 runs long.

• Blair joins for section 7 without context for the discussion that preceded. Mitigation: Cindy and Seth give Blair a 5-minute pre-brief in the break before section 7. Blair has the cover note from the pre-read, but real-time context matters.

---

Logistics

• Cindy schedules 5 business days before the target date to send pre-read.
• Cindy confirms counsel’s availability for the 4-hour block by May 12.
• Cindy confirms Blair’s availability for the final hour by May 12.
• Seth blocks May 18–22 for ADR 0003, 0007, 0011 drafting so they’re send-ready by the pre-read deadline.
• Cindy writes the cover note jointly with Seth, sends with pre-read.
• Cindy facilitates time-keeping during the meeting.
• Seth presents architectural content.
• Cindy or designated note-taker captures decisions and follow-ups in real time. The action register is committed to the repo within 24 hours of meeting end.

---

Document version

Draft v1 — to be reviewed by Cindy before the meeting is scheduled. The cover note in the pre-read package is signed jointly by Cindy and Seth. The agenda may evolve based on counsel’s pre-read response.