```html

Building HELM: An Interactive Operations Map for Real-Time System Visibility

Over the course of a development session, we built and deployed HELM—a comprehensive, self-contained interactive operations visualization tool for Queen of San Diego's booking and operations infrastructure. HELM provides drill-down visibility into how customer journeys flow through acquisition channels, monetization platforms, and operational dispatch systems, with live health diagnostics.

What Was Built

HELM is a single-page HTML application deployed to helm.queenofsandiego.com that visualizes the entire business system as an interconnected graph. The visualization includes:

• Acquisition nodes: Email campaigns, organic web search, referral partner codes
• Monetization nodes: Viator, Boatsetter, GetMyBoat, and greyed-out future platforms
• Dashboard nodes: Every operational dashboard (progress, expense tracking, crew dispatch) as interactive drill-down points
• Operations nodes: Email dispatch, crew calling, payment reconciliation workflows
• Health indicators: Real-time node status (green = healthy, red = issues) based on live probes to backend systems

The tool uses a force-directed physics engine (vis-network library) for automatic layout, allowing engineers to explore system dependencies without memorizing topology. Users can click nodes to drill down into specific operational workflows, view associated Google Apps Script function signatures, and understand data flow.

Technical Architecture

Front-End Stack

HELM is self-contained in a single HTML file located at:

/Users/cb/Documents/repos/sites/helm/index.html

This approach was chosen deliberately—no build process, no external dependencies beyond a CDN-hosted vis-network library. The file contains:

• Embedded CSS: Dark navy and gold design system matching Queen of San Diego branding, with custom styling for node states (healthy, degraded, unknown) and interactive elements
• Embedded JavaScript: vis-network initialization, force-directed graph logic, drill-down panel rendering, and health probe scheduling
• Node and edge definitions: Hard-coded NODE_DATA object containing all system components and their relationships, extracted from the broader system architecture
• Health diagnostics: Polling logic that calls backend endpoints to determine node status

The vis-network library was selected because it provides physics-based layout (nodes repel/attract via spring forces), interactive panning/zooming, and built-in clustering—essential for a system with 40+ nodes. CDN delivery via https://cdn.jsdelivr.net/npm/vis-network/dist/ eliminates build complexity.

Password Protection

HELM requires authentication before display. A password hash is computed via SHA-256 and verified client-side before rendering the graph. This protects sensitive operational visibility from casual access while remaining stateless (no backend session required).

Infrastructure: S3, CloudFront, and Route53

HELM was deployed using a standard, repeatable pattern:

S3 Bucket Creation

A new S3 bucket was created specifically for HELM:

s3://helm.queenofsandiego.com

Bucket configuration:

• Block all public access enabled (default)
• Versioning disabled (single index.html, no rollback needed)
• No lifecycle policies (static content, permanent retention)

CloudFront Distribution

A CloudFront distribution was created with an Origin Access Control (OAC) to restrict S3 access exclusively through CloudFront:

• Origin: helm.queenofsandiego.com.s3.amazonaws.com
• Distribution domain: CloudFront-generated domain (e.g., d12345abcdef.cloudfront.net)
• Cache behavior: TTL 300 seconds (5 minutes) for rapid iteration; can be extended for production stability
• Viewer protocol policy: Redirect HTTP to HTTPS
• OAC name: helm-queenofsandiego-oac (ensures only CloudFront can read S3)

S3 Bucket Policy

The S3 bucket policy was updated to restrict access to the specific CloudFront OAC principal:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::helm.queenofsandiego.com/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

Route53 DNS

An ALIAS record was created in the queenofsandiego.com hosted zone:

• Record name: helm.queenofsandiego.com
• Type: ALIAS (AWS-specific, not CNAME)
• Target: CloudFront distribution domain
• Evaluate target health: Enabled

ALIAS records were chosen over CNAME because they allow zone apex aliasing and integrate seamlessly with CloudFront.

Deployment and Iteration Process

The development cycle was rapid, with multiple iterations to refine node relationships and fix integration issues:

1. Initial write: HELM HTML file created with stub NODE_DATA and vis-network boilerplate
2. Iterative refinement: 18+ edits to index.html, progressively adding nodes (gas_crewdispatch, gas_expensetracker, etc.), fixing edge references, and styling
3. Syntax validation: JavaScript syntax checked before each deployment to catch errors early
4. S3 upload: aws s3 cp /Users/cb/Documents/repos/sites/helm/index.html s3://helm.queenofsandiego.com/index.html
5. CloudFront invalidation: Cache invalidation issued after each S3 update to ensure browsers fetch fresh content
6. Smoke testing: https://helm.queenofsandiego.com tested after deployment to verify rendering and health probes

This pattern was applied twice—once for HELM and again for the operational dashboard at ops.queenofsandiego.com—proving the infrastructure pattern's reusability.

Key Design Decisions

• Self-contained HTML: No build pipeline, no bundling. A single file can be edited, deployed, and cached independently. Reduces operational complexity.
• Client-side physics: vis-network's force-directed layout allows the graph to auto-arrange itself. As nodes are added or removed, relationships