```html

Executive Reporting Infrastructure: Multi-Perspective Analysis System via AWS SES and Lambda

What Was Done

We built and deployed a comprehensive executive reporting system that generates five specialized C-suite reports, each analyzing the Queen of San Diego portfolio from a distinct operational lens: CEO (strategic assets and KPIs), CTO (technical debt and infrastructure), Accounting (revenue tracking and chart of accounts), CMO (marketing channels and campaign readiness), and CFO (burn rate and capital deployment). This system runs on AWS Lambda with SES for email delivery, storing analysis snapshots for audit trails.

Technical Architecture

Report Generation Pipeline

The system consists of two Python scripts in `/Users/cb/Documents/repos/tools/`:

  • send_exec_reports.py — Primary orchestrator that imports five report generator functions
  • send_exec_reports_2.py — Secondary variant for iterative testing and report refinement

Each report is a standalone generator function that:

  • Reads from project handoff markdown files stored in `/Users/cb/Documents/repos/agent_handoffs/projects/`
  • Parses asset inventory and operational state across all four entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur)
  • Applies role-specific analysis logic (CEO focuses on shortfalls and KPIs; CTO audits security and infrastructure costs; Accounting builds chart of accounts)
  • Formats output as email body text with structured sections and bullet points
  • Returns formatted string to the SES sending function

Email Delivery via AWS SES

Reports are dispatched through AWS SES (Simple Email Service) from a verified sender address hardcoded as `admin@queenofsandiego.com`. The calling pattern:

import boto3

ses_client = boto3.client('ses', region_name='us-west-2')

response = ses_client.send_email(
    Source='admin@queenofsandiego.com',
    Destination={
        'ToAddresses': ['primary-recipient@example.com'],
        'BccAddresses': ['admin@queenofsandiego.com']
    },
    Message={
        'Subject': {'Data': report_subject},
        'Body': {'Text': {'Data': report_body}}
    }
)

This approach ensures:

  • All five reports land in a single inbox thread (same recipient)
  • Admin address receives a blind copy for compliance and archival
  • No HTML rendering required, reducing email client compatibility issues
  • Full audit trail via CloudWatch Logs (Lambda execution logs capture SES response IDs)

Data Sources

Each report reads from markdown handoff files that contain:

  • Project status snapshots (ship captain crew tool, Expert Yacht Delivery, etc.)
  • Infrastructure inventory (S3 buckets: `queenofsandiego.com`, CloudFront distributions, Route53 zones)
  • Current KPI and revenue state (charter bookings, pipeline opportunities, email blast capacity)
  • Team composition and risk factors (Sergio equity, Carole transition, open captain slots)

Example handoff structure read by CEO report:

cat /Users/cb/Documents/repos/agent_handoffs/projects/shipcaptaincrew.md

This file is version-controlled and updated after each development session, ensuring reports always reflect current operational state.

Infrastructure and Deployment

AWS SES Configuration

SES is configured in `us-west-2` with:

  • Verified sender domain: `admin@queenofsandiego.com` (verified via domain DKIM records in Route53)
  • Sending limit: 200 emails per 24 hours (sufficient for monthly reporting cadence)
  • No receipt rules configured for this send path (reports are outbound only)

Lambda Integration Points

The reporting system is designed to be invoked from Lambda handlers, specifically from `/Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py`, which manages all backend API endpoints for the ship captain crew booking tool. When a report trigger endpoint is called, Lambda:

  • Imports the report generator functions from the tools directory
  • Calls each generator in sequence, collecting all five report strings
  • Invokes SES client for each report with appropriate subject lines
  • Logs report IDs and delivery confirmations to CloudWatch
  • Returns HTTP 200 with delivery summary to the caller

File Storage for Audit Trail

Generated reports are optionally persisted to S3 bucket `queenofsandiego.com` under prefix `reports/exec/` with timestamp-based keys:

s3://queenofsandiego.com/reports/exec/2025-01-15T14-32-00Z_ceo_report.txt
s3://queenofsandiego.com/reports/exec/2025-01-15T14-32-00Z_cto_report.txt

This enables historical comparison and regulatory retention without storing in email clients.

Key Design Decisions

1. Plain-Text Email Over HTML

Reports are sent as plain text rather than HTML. Rationale: C-suite recipients often parse emails on mobile with aggressive rendering restrictions; plain text guarantees readability across all clients and reduces email size. Structured formatting (headers, bullet lists) is applied using ASCII conventions (colons, dashes, indentation).

2. Role-Specific Analysis Rather Than Generic Reporting

Each report is written from first principles by its generator function, not from a shared template. This ensures:

  • CEO report surface business-critical gaps (empty pipeline, billing models) that a technical report would bury
  • CTO report drills into stack-specific security issues (hardcoded Stripe keys in repos.env, unauthenticated GAS endpoints) that CFO doesn't need to own
  • Accounting report builds a complete chart of accounts mapping (revenue categories, expense buckets, cost centers) necessary for bookkeeping closure
  • CMO report sequences OTA deployment (Sailo → GetMyBoat → Viator) with financial upside modeling
  • CFO report focuses on monthly burn rate (~$7–9K/mo), capital deployment tiers, and break-even metrics

3. Sourcing from Handoff Files, Not Live Queries

Reports read from markdown snapshots rather than querying DynamoDB, S3 inventory, or CloudWatch in real-time. This design:

  • Decouples reporting from operational system availability
  • Ensures reproducible analysis (same input file = same report)
  • Reduces AWS API costs (no DynamoDB scans, no CloudWatch Logs Insights queries)
  • Allows reports to be generated offline if needed (no AWS credentials required for analysis logic)

4. BCC Admin on All Sends

Every report is BCC'd