Implementing Autonomous Marketing Campaign Management: Decoupling Identity from Public-Facing Infrastructure

```html

What Was Done

This session focused on a critical infrastructure refactor across JADA's marketing automation stack: removing all personal name references from public-facing marketing materials while maintaining full operational capability of the underlying campaign systems. The work involved coordinating changes across multiple Git repositories, CloudFront distributions, S3 buckets, and Google Apps Script deployments to ensure consistent brand identity without personal attribution.

The core directive was simple but architecturally complex: audit all outward-facing marketing files, scrub personal identifiers, deploy cleaned versions, and invalidate caches—all while keeping internal documentation and operational systems intact.

Technical Details

Scope and Audit Strategy

The initial challenge was identifying which files were "public-facing" versus internal. We established these categories:

Outward-facing: S3-hosted HTML/CSS/JS, CloudFront-distributed content, public demo sites
Internal-only: Google Apps Script files (CrewDispatch.gs, CrewScheduler.gs, FuneralOutreach.gs), local development files, documentation
Hybrid: Email templates that get sent to external audiences (required cleaning)

Search commands executed across the repository structure:


# Find all C.B. Ladd references in public paths
find /Users/cb/Documents/repos/sites -name "*.html" -o -name "*.js" -o -name "*.css" | xargs grep -l "C\.B\. Ladd"

# Check S3-hosted demo sites
find /Users/cb/Documents/repos/sites/dangerouscentaur/demos -type f | xargs grep -l "C\.B\. Ladd"

# Verify email templates (S3-hosted previews)
find /Users/cb/Documents/repos -name "*sdcc*" -o -name "*email*" | xargs grep -l "C\.B\. Ladd"

Files Modified

/tmp/sdcc-hotel-outreach-2026.html — Email template HTML (7 edits to remove name references)
/Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html — Demo property listing
/Users/cb/Documents/repos/sites/dangerouscentaur/demos/demo.dangerouscentaur.com/index.html — Generic demo site
/Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html — Progress dashboard
/Users/cb/Documents/repos/sites/queenofsandiego.com/managercandy/index.html — Internal event manager tool

Google Apps Script files were verified as internal-only (not exposed via Web Apps or public endpoints) and left unmodified:

CrewDispatch.gs, CrewScheduler.gs, FuneralOutreach.gs
WorshipRsvp.gs, ViatorApiFollowUp.gs

Infrastructure and Deployment

S3 and CloudFront Coordination

Updated files were deployed to S3 with cache invalidation to ensure CDN delivery of fresh content:

SDCC email preview: Uploaded to S3, invalidated CloudFront distribution (email preview endpoint)
DangerousCentaur demo sites: Updated both demo HTML files in S3, invalidated distribution serving demo.dangerouscentaur.com and property subdomain
Progress dashboard: Redeployed index.html to S3, invalidated CloudFront for progress.queenofsandiego.com

CloudFront invalidation strategy:


# Example invalidation pattern (credentials pre-configured in AWS CLI)
aws cloudfront create-invalidation \
  --distribution-id [DIST_ID] \
  --paths "/*"

We used /* wildcard invalidation rather than granular paths because demo sites are low-traffic and full distribution refresh ensures consistency.

Marketing Automation Systems (Unchanged Operationally)

The core campaign tools were NOT refactored—only their outputs were cleaned:

jada_blast.py — Email delivery script (4 edits to logging/comments, functionality preserved)
FuneralOutreach.gs, CrewDispatch.gs — Google Apps Script backends (verification only)
SES suppression list management — Operational; cleaned via export/reimport process
Platform integration tasks — Remain in dashboard; no code changes required

Email templates are now identity-neutral, referencing "JADA Team" or "Queen of San Diego" entities instead of personal attribution.

Key Decisions and Rationale

Why Not Refactor Apps Script Globally?

Google Apps Script files (CrewDispatch, CrewScheduler, etc.) are:

Deployed only to internal Google Workspace domains
Not publicly accessible via URL (no Web App deployment)
Used by internal team members only

Refactoring would add risk (potential deployment errors) without reducing external exposure. Internal documentation can reference the development context without affecting public brand presence.

S3 Versioning vs. Overwrite

We chose direct overwrite (not version retention) because:

Demo sites are iterative (no need for historical versions)
Email templates are single-instance campaigns (template already sent)
Reduces storage costs and simplifies cache invalidation
Git repositories retain full history anyway

CloudFront Invalidation Scope

Full-distribution (/*) invalidation was chosen over path-specific because:

Demo sites have minimal traffic (no performance impact)
Eliminates risk of partial cache misses
Simpler to audit and verify
CDN edge caches refresh within 2–5 minutes

Verification Steps Executed

Post-deployment verification included:


# Verify no personal name references in public files
grep -r "C\.B\. Ladd" /Users/cb/Documents/repos/sites/dangerouscentaur/demos/
grep -r "C\.B\. Ladd" /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/

# Confirm email template is clean (after S3 upload)
curl https://[S3_ENDPOINT]/sdcc-hotel-outreach-2026.html | grep -i "C\.B\. Ladd"

All checks returned zero matches—indicating successful scrubbing.