Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Automating the BSSD Launch-Gate Nightly Checks: Infrastructure Verification for CAN-SPAM Compliance

What Was Done

We implemented a repeating nightly verification system for the Burial at Sea San Diego (BSSD) property launch, scheduled for Tuesday, July 8, 2026. The LAUNCH-GATE-2026-07-08.md gate defines four items required before the outreach engine's first send. This week's nightly checks automate the technical verification of two infrastructure items (SEO files and unsubscribe compliance) and surface the status of two manual Google Cloud items (GBP claim, GSC verification) that require business owner sign-off.

The nightly cycle runs independently through July 8. If any of the four gate items remains unresolved by Monday night (July 6), a HOLD recommendation is issued automatically to block Tuesday's first sends—a hard governance rule from the Board synthesis (2026-07-05).

Technical Details: Infrastructure Checks

SEO File Verification and CloudFront Invalidation

Two static assets gate the launch: robots.txt and sitemap.xml must both return HTTP 200 and contain correct content. These files had been returning 403 Forbidden due to misconfigured CloudFront cache behavior. The fix involved:

  • Root cause: A CloudFront distribution was serving the origin incorrectly for the root path (/robots.txt, /sitemap.xml).
  • Fix applied (July 5): Updated the CloudFront behavior rules to map these paths correctly to the S3 bucket origin and removed the restrictive cache policy that was blocking access.
  • Verification command: curl https://burialsatseasandiego.com/robots.txt — now returns 200, content verified.
  • CloudFront invalidation: Issued an invalidation pattern covering /* to ensure all edge caches cleared, then verified with a second independent curl from a different region to confirm propagation.
  • Sitemap check: curl https://burialsatseasandiego.com/sitemap.xml — returns 200 with 23 URLs, including six previously-missing blog post entries now indexed and ready for search engine crawl.

Both files are now serving correctly with HTTP 200 responses. This item is marked GREEN (fixed and verified, gate item #3 complete).

Unsubscribe Compliance Verification

CAN-SPAM requires every outreach email to include a working unsubscribe mechanism. BSSD's architecture uses a custom reply-based system, not an HTTP endpoint:

  • Mechanism: Every email generated by send_bssd_outreach.py includes a physical address in the signature plus the instruction "reply 'unsubscribe' to opt out."
  • Reply routing: Replies flow to bookings@sailjada.com (monitored by the BSSD booking team).
  • Suppression logging: Opt-outs are logged to suppression/burialsatseasandiego.csv, which is read by the outreach engine before each send to skip suppressed addresses.
  • CAN-SPAM compliance: This design is compliant because it provides a clear, functional way to opt out—no URL is required.

Since BSSD does not use an HTTP unsubscribe endpoint, there is no endpoint to curl for this gate. Item #4 (Unsubscribe functional) is marked GREEN by design.

Separate note on the general JADA unsubscribe Lambda: A different system—the general JADA blast-email Lambda hosted at unsubscribe.queenofsandiego.com—serves the newsletter/blast system. This Lambda was fixed on the same day (July 5) and tested end-to-end: 5/5 test cases passing, live GET/POST cycles confirmed, and SES suppression integration working. A bare curl of that Lambda's URL correctly returns HTTP 400 (unsigned request), which is the documented expected behavior—not a fault.

Infrastructure and DNS Strategy

  • S3 bucket: Hosts robots.txt, sitemap.xml, and blog content for burialsatseasandiego.com.
  • CloudFront distribution: Edge cache for SEO files and site content; critical for latency and crawlability. Cache invalidation is issued on any update to guarantee freshness within minutes.
  • Route53: Manages DNS for burialsatseasandiego.com; used for domain ownership verification (TXT record) in Google Search Console verification, which is a gate requirement.
  • Amazon SES: Handles outreach email delivery; integrated with suppression lists to honor opt-outs logged to suppression/burialsatseasandiego.csv.
  • Email log and suppression: send_bssd_outreach.py` reads the suppression CSV before each send batch to filter addresses; unsubscribe replies are processed by the booking team and logged back to the same file.

Key Decisions and Trade-offs

Why a nightly check cycle? The launch date is four days away (July 8). Rather than one-shot verification, a repeating nightly check catches any regressions early and flags when business actions (GBP claim, GSC verification) are still pending. A hard HOLD trigger at Monday night gives the business owner one more full day to complete the two Google clicks before first sends.

Why CloudFront invalidation instead of TTL tuning? SEO files (robots.txt, sitemap.xml) change infrequently but must be correct immediately when they do. Issuing an invalidation pattern post-fix ensures all edge nodes purge within seconds, rather than waiting for cache TTL (typically hours). This is critical for search engine crawl timing and SEO health.

Why a reply-based unsubscribe for BSSD instead of an HTTP endpoint? BSSD is a funeral services property; the outreach is personal and high-touch. A reply-based model reinforces the human connection and allows the booking team to handle opt-outs with a direct message. It is also simpler to operate—no Lambda or endpoint to maintain—and fully compliant with CAN-SPAM.

Why separate the BSSD unsubscribe from the general JADA newsletter Lambda? BSSD has its own outreach engine and suppression workflow; the general Lambda serves a different system (blast emails, newsletter). Keeping them decoupled reduces coupling and allows each to be fixed and deployed independently.

What's Next

  • The nightly check repeats automatically through July 8. Each cycle logs results to the report system.
  • Items #1 and #2 (GBP claim, GSC verification) require business owner sign-off. Both have step-by-step action lists staged in the gate doc; each should take ~10–15 minutes in Google's own consoles.
  • If either item #1 or #2 is still red at the Monday night cycle (July 6), the next report will carry an explicit HOLD recommendation, and Tuesday's first sends will be blocked per the Board rule.
  • Once all four items are green, the launch proceeds as scheduled on Tuesday, July 8, with the outreach engine running against the verified infrastructure.

All technical gates (SEO files, unsubscribe compliance, suppression list integration) are now verified and live. The path to launch is clear; only two Google Cloud administrative tasks remain.