Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Removing Personal Identity from Public Marketing Infrastructure: A Multi-System Approach

This post documents the technical implementation of a critical business requirement: eliminating personal name references from all customer-facing marketing assets across JADA's distributed infrastructure. The directive came from a straightforward business reality—public marketing shouldn't carry the baggage of individual identity. Instead, we branded around organizational identity (JADA, Queen of San Diego, the team concept) and technical infrastructure patterns that allowed us to execute this change comprehensively across email templates, web properties, and automation tools.

The Problem: Scattered Personal References

A routine audit of email campaign content (task card t-f4b3c880) revealed personal name references embedded across multiple systems:

  • Email templates in S3-backed CloudFront distributions
  • HTML demo sites in the dangerouscentaur domain structure
  • Google Apps Script files driving crew dispatch and event management
  • Python automation tools for blast campaigns
  • Internal progress dashboards exposed to external visibility

The challenge wasn't technical complexity—it was surface area. These references were distributed across heterogeneous systems with different deployment patterns, caching layers, and access controls. A naive find-and-replace would miss some instances while creating deployment inconsistencies.

Technical Approach: Layered Remediation

Phase 1: Email Infrastructure (S3 + CloudFront)

The SDCC hotel outreach campaign emails live in S3 and are delivered through CloudFront distributions. We:

  1. Downloaded the live email template HTML from S3 using standard AWS CLI tooling
  2. Performed targeted text replacement: personal name → "the JADA team" / "Queen of San Diego event team"
  3. Re-uploaded the sanitized HTML to the same S3 key
  4. Invalidated the CloudFront distribution cache to force edge re-fetch

The invalidation command pattern:

aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/email-templates/*"

Why this approach: CloudFront caching is aggressive (TTL often 86400+ seconds). Without invalidation, users would see stale content for hours. The invalidation propagates across all 200+ edge locations within seconds.

Phase 2: Static Web Properties (dangerouscentaur Sites)

Three separate demo sites in the dangerouscentaur structure contained personal references:

  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/demo.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html

Process:

  1. Scanned each HTML file for name patterns using grep with case-insensitive matching
  2. Hand-verified matches to avoid false positives (e.g., legitimate internal documentation)
  3. Edited files locally, replacing context-appropriate references
  4. Uploaded sanitized versions to their respective S3 buckets
  5. Invalidated CloudFront distribution caches

Key decision: We maintained internal proof-of-work documentation (internal-only wikis, README files) unchanged. The rule was simple—if a file is part of the deployment artifact served to customers, it gets sanitized. Internal repositories can retain full context.

Phase 3: Google Apps Script Automation

Apps Script files drive critical operational workflows:

  • FuneralOutreach.gs – manages funeral service event outreach
  • CrewDispatch.gs – coordinates crew scheduling
  • ViatorApiFollowUp.gs – Viator API integration for tour follow-ups
  • CrewScheduler.gs – crew availability and assignment

These files were modified in place (no deployment required—Apps Script auto-syncs) with name references replaced by role descriptions ("dispatch coordinator", "event team", etc.). The changes are effective immediately for new script executions.

Why Apps Script needed careful handling: These scripts generate emails and internal communications. References here affected both internal and external messages. We preserved functional references (email sender identification in logs) but removed personal branding.

Phase 4: Python Automation and Blast Tools

The primary blast tool /Users/cb/Documents/repos/tools/jada_blast.py went through multiple iterations during this session:

  • Email template references were updated to point to sanitized versions
  • Comments and internal documentation were revised
  • The script itself is not customer-facing, but it generates customer-facing output, so this was a necessary layer

Companion tools like send_hotel_outreach.py (newly created for SDCC campaign) were built with the naming conventions pre-applied.

Infrastructure and Deployment Specifics

S3 Buckets and CloudFront Distributions

The hotel outreach email preview lives at a specific S3 key path. Direct uploads to that key trigger CloudFront invalidations. The workflow uses standard AWS SDK patterns—no custom infrastructure required.

CloudFront distribution invalidations create a task that completes within 1-2 minutes. During this window, some edge locations may serve stale content, but the eventual consistency is guaranteed.

LaunchAgents for Scheduled Campaigns

New plist files were created to orchestrate scheduled outreach campaigns:

  • /Users/cb/Library/LaunchAgents/com.jada.hotel-outreach-initial.plist
  • /Users/cb/Library/LaunchAgents/com.jada.hotel-outreach-followup1.plist
  • /Users/cb/Library/LaunchAgents/com.jada.hotel-outreach-followup2.plist
  • /Users/cb/Library/LaunchAgents/com.jada.hotel-outreach-breakup.plist

These files reference the sanitized email templates and execute send_hotel_outreach.py on schedules. The plist format is macOS-specific, which aligns with JADA's current deployment architecture.

Verification and Edge Cases

A comprehensive sweep identified edge cases:

  • SES Suppression Lists: Bounce/complaint records already anonymized in AWS SES; no action needed
  • Email Headers: SMTP sender fields in automated emails were reviewed; operational identity maintained without personal branding
  • Internal vs. External: Documentation and internal-use files were explicitly excluded from sanitization
  • Comments in Code: Code comments containing references were updated for consistency and maintainability

Key Architectural Decisions

Why not use templating variables for all names? Some infrastructure doesn't support runtime templating (static HTML delivered via Cloud