reference
Seth's Phase 1 Deliverable Checklist
Seth's operational working checklist for May 2026 — organized week-by-week with ADR drafts, GCP scaffolding, schema design, RLS prototype, hiring pipeline, and cross-functional coordination tasks required to unlock Phase 2 on June 1.
Drafted: May 5, 2026
Owner: Seth Shoultes
Period: May 1 – May 31, 2026 (4 weeks)
Companion to: Phased Plan Rev 2, ADR Template, Friction-Points One-Pager
Format: Working document. Update inline. Check items off as completed. Surface blockers in #memberintel-leads.
How to use this document
This is a working operational checklist, not a planning document. It captures everything Phase 1 commits Seth to deliver, in roughly the order they should happen, with dates and dependencies. Update it inline as items complete, change scope, or surface blockers. Bring it to the bi-weekly Cindy + Santiago sync. Bring it to the weekly status with Blair.
The structure has three layers:
- Week-by-week milestones at the top — the flow of the month.
- Deliverables grouped by category in the middle — the actual artifacts.
- The Phase 1 milestone gate at the bottom — the criteria for kicking off Phase 2 on June 1.
If something on this list isn’t going to happen by May 31, surface it to Blair and Cindy by mid-May. The whole point of milestone gates is that slipping the schedule is acceptable; pulling Phase 2 into work that isn’t ready is not.
Week-by-week shape
Week 1 (May 4 – May 10)
- ADR drafting starts (parallel — multiple ADRs in flight).
- GCP organization, folder structure, four projects scaffolded via Terraform.
- KMS keyring with the four named keys created.
- Workload Identity Federation configured for GitHub Actions to GCP.
- Privacy counsel introductory call held; substantive review scheduled for late May.
- Senior AI Engineer interviews ramping; Danielle’s process running.
- Conversation with Paul Carter about MP-side endpoint approach.
Week 2 (May 11 – May 17)
- ADRs 0001–0005 (GCP, Cloud SQL, isolation, vector store, CI/CD) drafted, in PR review with Blair for material ones.
- Schema design document drafted to first-pass review.
- RLS isolation prototype implemented and validated (the small standalone exercise — two synthetic tenants, FORCE policy, dual-role pattern).
- Stripe integration approach (customer-OAuth-only) confirmed with Ally Roger.
- MP API endpoint approach committed with Paul Carter; their Phase 2 work scoped.
Week 3 (May 18 – May 24)
- ADRs 0006–0009 (observability, secrets, Stripe integration, model abstraction layer) drafted, in PR review.
- Schema design reviewed and approved by Blair.
- ADR 0010 (project structure) and ADR 0011 (cross-pollination security boundary) drafted.
- Privacy counsel substantive architecture review held. Counsel leaves with materials to draft initial ToS / Privacy Policy positions.
- Senior AI Engineer offer extended (target close mid-June).
- Cross-functional engineering kickoffs with Paul Carter, Thomas, Ally Roger, Mahmoud completed.
Week 4 (May 25 – May 31)
- All ADRs accepted (status moved from Proposed to Accepted in the repo).
- Schema design committed as the source-of-truth document.
- Phase 1 milestone gate reviewed jointly with Cindy and Blair.
- Phase 2 sprint plan drafted with Santiago for kickoff June 1.
- Senior AI Engineer onboarding plan finalized with Danielle (Slack, repo access, GCP IAM, ramp-up materials).
- The “things that worried me but didn’t fire an alert” check-in with Cindy — anything from Phase 1 that needs to surface before Phase 2 begins.
Deliverables by category
Architecture Decision Records
The phased plan commits to ~9–11 ADRs by end of Phase 1. Every material ADR (marked) needs Blair’s explicit approval per the decision-rights matrix.
| # | Title | Material? | Target draft date | Status |
|---|---|---|---|---|
| 0001 | Cloud provider: GCP | Yes | May 8 | ☐ |
| 0002 | Database: Cloud SQL Postgres with CMEK | Yes | May 8 | ☐ |
| 0003 | Per-tenant isolation: shared-schema with RLS | Yes | May 12 | ☐ |
| 0004 | Vector store: pgvector | Yes | May 12 | ☐ |
| 0005 | CI/CD: GitHub Actions with WIF | No | May 15 | ☐ |
| 0006 | Observability: Cloud Logging + OTel + BigQuery | Yes | May 19 | ☐ |
| 0007 | Secrets management: Secret Manager + KMS + path-prefixed naming | Yes | May 19 | ☐ |
| 0008 | Stripe integration: customer-OAuth-only in V1 | Yes | May 22 | ☐ |
| 0009 | Model provider abstraction layer | No | May 22 | ☐ |
| 0010 | GCP project structure: project-per-environment + shared tooling | Yes | May 26 | ☐ |
| 0011 | Cross-pollination security boundary: three-roles model | Yes (counsel reviews) | May 26 | ☐ |
Each ADR follows the template from the ADR template document. Material ADRs are merged with Blair’s explicit approval recorded in the PR. ADR 0011 specifically gets counsel’s eyes before merging (counsel is reviewing in late May; ADR 0011 PR opens before that review and merges after, with counsel comments incorporated).
Schema design
The canonical data schema lands as a markdown document by end of Phase 1. Reviewed by Blair, ready to translate into Phase 2 migrations.
- ☐ ER diagram covering all V1 tables (members, transactions, subscriptions, content protection rules, per-customer brain entries, global brain entries, audit log, sync state, entitlements, trial state, stripe_events_processed)
- ☐ Column-level annotations: types, nullability, default values, indexes
- ☐ Platform-agnostic fields (
source_platform,source_id) on canonical tables — V2.1 readiness - ☐ Per-customer brain entries versioned from day one (every update is a versioned write; prior versions retained)
- ☐ Audit log structure (immutable, BigQuery-backed, separate dataset with restricted IAM)
- ☐ Entitlement table with V1.5 trial-state extension fields present in V1 (additive in V1.5)
- ☐ RLS policy template for every customer-data table
- ☐ Foreign-key relationships explicitly diagrammed
- ☐ Dual-role pattern documented (migration role can bypass RLS; app role cannot)
- ☐ Schema review held with Blair; approved before week 4 ends
Foundation infrastructure
The GCP scaffolding that Phase 2 builds on. By end of Phase 1, no application code exists — but the Terraform that creates the platform does.
- ☐ Google Cloud Organization with
productionandnon-productionfolders - ☐ Four projects:
memberintel-prod,memberintel-staging,memberintel-dev,memberintel-shared - ☐ Per-environment VPCs with private IP ranges, no public IPs on data services
- ☐ Cloud NAT configured with static egress IP (for Anthropic / Stripe allowlisting)
- ☐ KMS keyring per environment with named keys:
app-data-key,secrets-key,backups-key,audit-key - ☐ Workload Identity Federation configured for GitHub Actions deploys
- ☐ Artifact Registry in
memberintel-sharedfor Docker images promoted across environments - ☐ GCS buckets for Terraform state (versioning enabled, separate per environment, locked-down IAM)
- ☐ Organization Policies on
productionfolder: no public IPs, no service account key creation, required labels - ☐ Cloud Logging sinks configured to BigQuery (audit dataset locked-down, analytics dataset normal)
- ☐ Secret Manager naming convention documented and enforced
- ☐ Basic Cloud Monitoring dashboards scaffolded (will be populated in Phase 2 as services come up)
RLS isolation prototype
A standalone prototype that validates the per-tenant isolation pattern before Phase 2 commits to it at scale. One day of work; pays back if any architectural surprise emerges.
- ☐ Two synthetic tenants in a staging Postgres instance
- ☐ Customer-data table with
tenant_idandFORCE ROW LEVEL SECURITYapplied - ☐ App role (cannot bypass RLS) and migration role (can) created
- ☐ Middleware-style helper that sets
app.current_tenant_idper session - ☐ Integration test demonstrating: tenant A authenticated cannot read, update, or delete tenant B’s data
- ☐ Negative test: query without
app.current_tenant_idset returns zero rows (no implicit data leak) - ☐ Performance check: RLS overhead measured, documented in ADR 0003
- ☐ Findings written into ADR 0003 before it moves to Accepted
Vendor decisions and integrations
External relationships that need to be locked in May so Phase 2 isn’t blocked.
- ☐ Anthropic API keys provisioned for prod, staging, dev environments
- ☐ Anthropic workspace structure decided (one workspace? per-environment workspaces?)
- ☐ Stripe account confirmed (Caseproof’s existing relationship); customer-OAuth-only V1 approach signed off with Ally
- ☐ Atlassian Statuspage or Better Stack Status selected; account provisioned
- ☐ Cloud SQL CMEK enabled; backup schedule configured
- ☐ Memorystore (Redis) provisioning approach decided; instance sizing for Phase 2 launch
- ☐ Cloud Tasks queue structure decided (one queue per pipeline type — MP sync, Stripe sync, site analysis, cross-pollination)
MP-side coordination with Paul Carter
The MP API endpoint approach (Option A from the sync architecture conversation) is a Phase 1 dependency. If Paul Carter’s team can’t commit to building the endpoints in Phase 2, sync slips.
- ☐ Initial conversation with Paul Carter early Week 1 — present the dedicated
/wp-json/memberintel/v1/syncendpoint approach - ☐ Endpoint design document drafted jointly with Paul Carter’s team — what data, what shape, versioning approach,
since=parameter for incremental sync - ☐ MP plugin development scoped on Paul Carter’s side; engineer assigned; Phase 2 timeline confirmed
- ☐ Authentication approach (per-license signing keys) jointly designed
- ☐ Endpoint versioning protocol agreed — MemberIntel and the MP plugin loosely versioned together
- ☐ Cross-team dependency added to Santiago’s tracking with explicit owners
- ☐ Resolved as SPEC Open Q7 by end of May
Engineering hiring (Senior AI Engineer)
The most consequential decision of Q2 per Seth’s JD. Mid-June close target.
- ☐ Job description finalized (with Cindy / Danielle review)
- ☐ Sourcing channels active — internal referrals, recruiter, network outreach
- ☐ First-round technical screen designed: weights cloud infra comfort, not just AI engineering
- ☐ Second-round interview structure with Seth (architecture conversation) + Danielle (cultural / operational fit) + Mahmoud (senior engineering judgment)
- ☐ 3+ qualified candidates in late-stage interviews by end of Phase 1
- ☐ Final-round preparation for top candidate(s) — system design exercise that touches multi-tenancy, AI-shaped systems, cost discipline
- ☐ Reference checks process defined
- ☐ Onboarding plan drafted (Danielle leads logistics; Seth leads technical ramp)
Privacy counsel architecture review
The substantive review per the friction-points one-pager. Half-day working session in late May. Cindy organizes; Seth carries most of the content load.
- ☐ Counsel engaged by June 1 (Cindy’s deliverable; Seth supports)
- ☐ Introductory call held in week 1 — orient counsel to MemberIntel scope
- ☐ Architecture review pre-read package prepared and sent 5 business days before the meeting:
- SPEC v1 §10 (Compliance & Privacy)
- SPEC v1 §6.3 (Cross-pollination)
- ADRs 0003 (isolation), 0007 (secrets), 0011 (cross-pollination boundary) — drafted by send time
- Schema design document
- Audit log structure overview
- ☐ Half-day working session held late May (target: May 22 or May 27)
- ☐ Action items captured; follow-ups assigned
- ☐ Counsel’s preliminary architectural sign-off (or list of concerns to address) documented before May 31
Phase 2 launch readiness
By end of Phase 1, Phase 2 has to be ready to actually start on June 1. That means:
- ☐ Phase 2 sprint plan drafted with Santiago (4-week scope, milestone gates)
- ☐ Senior AI Engineer onboarding plan finalized — first week of Phase 2 covers ramp; productive contributions expected by week 2
- ☐ Ronald’s MemberIntel work prioritized; prior work cleared
- ☐ Application code repo initialized in
memberintel-sharedArtifact Registry - ☐ CI/CD pipeline scaffolded — at minimum: PR check that runs the integration test harness against a fresh Postgres container
- ☐ Local development environment documented for new hires (Docker compose with Postgres + Redis, mock Stripe, mock Anthropic-via-cassette)
- ☐ Kickoff document for Phase 2 written — what’s getting built in week 1, week 2, week 3, week 4
Documentation hygiene
The documentation that the team will actually use during Phase 2. Not bureaucracy — leverage.
- ☐ ADR README in
docs/adr/indexes all 9–11 ADRs with status, title, summary - ☐ Schema design document committed to
docs/schema/ - ☐ Decision-rights matrix signed and committed to
docs/governance/ - ☐ This Phase 1 checklist updated through the month and committed as a permanent record
- ☐ Phase 2 onboarding doc for the Senior AI Engineer drafted (system overview, repo tour, getting-started checklist)
Cross-functional touchpoints (Seth-driven)
The phased plan calls for kickoff meetings with multiple cross-functional partners. These are Seth’s responsibility for the technical content; Cindy organizes the meetings.
| Partner | What’s discussed | Target date |
|---|---|---|
| Paul Carter | MP-side endpoint approach, versioning, Phase 2 commitment | Week 1 |
| Thomas Levy | Data layer engineering consultation; Mahmoud as ad hoc backstop arrangement | Week 2 |
| Ally Roger | Stripe customer-OAuth approach, billing integration scope, dunning | Week 2 |
| Mahmoud Saeed | Senior engineering / code review backstop role; ad hoc availability | Week 2 |
| Danielle Lea-Jones | Senior AI Engineer interview process and onboarding logistics | Continuous through Phase 1 |
| Russ Williams | Brief — design coordination needs in Phase 3 (no detail required Phase 1) | Late Phase 1 |
| Outside privacy counsel | Architecture review (substantive) | Late Phase 1 |
Recurring activities through Phase 1
- Weekly status to Blair (5–10 bullets, written, Friday afternoon)
- Bi-weekly Cindy + Santiago sync (30 minutes, Tuesday recurring slot)
- Weekly check-in with Danielle on Senior AI Engineer search progress
- Daily check on
#memberintel-leadsfor blockers from Cindy or cross-functional partners
Phase 1 milestone gate criteria (the reason this exists)
By May 31, all of the following must be true to kick off Phase 2 on June 1. If any are false, slip the schedule.
- ☐ ADRs 0001–0009 committed (Accepted status, Blair-approved for material ones)
- ☐ ADRs 0010, 0011 in late draft / approval (acceptable to slip these into early Phase 2 if necessary)
- ☐ Schema design reviewed and approved by Blair
- ☐ At least 2 PRDs (Cindy’s deliverable) drafted and approved by Blair — primary check is “is there scope for Phase 2 to build against?”
- ☐ Privacy counsel engaged; architecture review held; preliminary sign-off captured
- ☐ Decision-rights matrix signed by Blair, Cindy, Seth
- ☐ Senior AI Engineer hire pipeline has 3+ qualified candidates in late-stage interviews
- ☐ MP API endpoint approach confirmed with Paul Carter; Phase 2 work scoped on their side
- ☐ GCP projects, KMS keyring, WIF, basic Terraform scaffolding deployed
- ☐ RLS isolation prototype validated and findings in ADR 0003
- ☐ Brain content lead hire decision made (per friction-points one-pager — Blair’s call); if approved, candidate identified
- ☐ Phase 2 sprint plan drafted with Santiago
If any are false: surface to Blair by Wednesday, May 27. Joint decision by Friday, May 29 on whether to slip Phase 2 start by 1–2 weeks. Slipping is acceptable; pretending Phase 2 can start on bad foundations is not.
Things that should worry me but might not fire an alert
A space for Seth to log concerns through Phase 1 that don’t have a structured surface yet. Update inline. Bring to the bi-weekly sync with Cindy and the weekly with Blair.
- (Add as the month unfolds)
Document version
Living document — Seth updates inline through May. Final version (with all checkboxes resolved) committed to docs/governance/phase-1-completion.md as a permanent record. The Phase 2 equivalent of this document is drafted in week 4 of Phase 1.