Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Executing a Real-Time Charter Operations Workflow: DDB Consistency, Document Delivery, and Crew Coordination on July 4

This post covers the technical execution of a single charter operation — a 7 PM–10 PM July 4 charter organized by Dylan Osborne — through JADA's ops workflow. It touches data consistency patterns, infrastructure decisions for document delivery, and the integration points between local tooling and cloud services.

What Was Done

The charter was already in the system (having passed calendar ingestion → DDB record creation in earlier workflow stages). The session focused on three parallel goals:

  • Operations Status: Locate the July 4 charter record in DynamoDB, verify crew assignment, and check the current payment and contact state.
  • Document Delivery: Deploy the trip sheet and waiver PDF to the public print URL pattern, then deliver both documents and a manifest request to Daniela (the crew member responsible for printing and boarding documents).
  • Organizer Communication: Draft and queue an SMS to Dylan Osborne with the remaining balance due, the overdue Coast Guard manifest request, and the waiver e-signature link.

Technical Details: Data Location and Consistency

The charter record lives in the jada-crew-dispatch DynamoDB table in us-east-1. Initial attempts to query this table using the default AWS CLI session failed with expired credentials; the working credential profile was queenofsandiego, configured in ~/.aws/credentials.

Querying the DDB record:

aws dynamodb get-item \
  --table-name jada-crew-dispatch \
  --key '{"charter_date": {"S": "2026-07-04"}, "time_slot": {"S": "19:00"}}' \
  --profile queenofsandiego \
  --region us-east-1

The response revealed two critical discrepancies that needed correction before proceeding:

  • Contact mismatch: The DDB contact field was linked to an incorrect name ("Sally Hagar") with a stale phone number, when the actual organizer is Dylan Osborne (+1 714-380-0508).
  • Payment status misclassification: The payment_status field was set to paid_in_full, but the actual ledger shows a $500 Boatsetter deposit (received 2026-06-11) with $3,250 outstanding. The status should be deposit_received.

Synchronizing contacts.csv: The source of truth for organizer and crew contact details is /Users/cb/icloud-jada-ops/passengers/contacts.csv. Each row is keyed by phone number and cross-referenced in DDB; updating one requires updating both. The Dylan row was corrected:

  • Phone: +1 714-380-0508
  • Name: Dylan Osborne
  • Charter date: 2026-07-04

DDB correction: The payment_status attribute was updated via update-item with both the status and a human-readable description string: "$500 deposit via Boatsetter · $3,250 balance due at boarding." This dual-field pattern (enum + description) allows both machine sorting and human legibility in dashboards and crew comms.

Infrastructure: Document Deployment

The trip sheet and waiver PDFs need to be accessible to Daniela as printable URLs (not email attachments). JADA's document distribution uses S3 + CloudFront:

  • S3 bucket: Charter documents are staged in a private S3 bucket and synced to a public distribution directory.
  • CloudFront distribution: The public print URL pattern is https://queenofsandiego.com/print/[charter-slug]/[document-name].pdf.
  • Route53: The queenofsandiego.com domain is configured to point to this CloudFront distribution.

Deployment process:

aws s3 cp /path/to/trip-sheet-2026-07-04-dylan.pdf \
  s3://[bucket-name]/public/print/dylan-jul4/trip-sheet.pdf \
  --profile queenofsandiego

aws s3 cp /path/to/waiver-2026-07-04.pdf \
  s3://[bucket-name]/public/print/dylan-jul4/waiver.pdf \
  --profile queenofsandiego

Both URLs were then verified as publicly accessible before being sent to Daniela.

Why S3 + CloudFront instead of email attachments? Email attachments create compliance friction (some email systems flag PDFs), are larger payloads, and create redundant copies in mailboxes. URLs allow Daniela to fetch and print only when needed, and we retain a single source of truth in S3 for audit and re-issue if the document needs to be updated.

Key Decisions

1. DDB as authoritative source for crew/contact data: Although contacts.csv is human-readable and version-controlled in git, DDB is the single source of truth for charter state. The CSV is kept in sync via a one-way sync process: read from DDB, write corrections to both DDB and CSV. This prevents split-brain scenarios where a crew member or ops tool reads stale CSV data while DDB has been updated.

2. Never auto-send SMS: The SMS drafts to Dylan and Daniela were written to /Users/cb/icloud-jada-ops/drafts/DRAFT-dylan-jul4-balance-sms.txt and held for explicit approval before sending. This pattern prevents accidentally sending duplicate or malformed messages, especially critical when the message contains balance-due and Coast Guard compliance information.

3. Credential profile isolation: Rather than using a default shared AWS session, operations use profile-specific credentials (e.g., --profile queenofsandiego). This allows rotating credentials per crew member / ops context without disrupting other workflows.

4. Manifest request deferred to Dylan: The Coast Guard-required guest list / manifest must be populated by the organizer (Dylan), not the ops system. A manifest request template was drafted and linked in the SMS to Dylan; he is responsible for filling in guest names and contact details. This keeps ops from having to source or invent guest data, and ensures legal/safety accountability stays with the charter organizer.

What's Next

  • Dylan SMS approval and send: The balance-due message and manifest request link are queued in drafts. Once approved, it will be sent via the JADA SMS line to +1 714-380-0508.
  • Manifest collection: Dylan will populate the guest list via the provided template; that template flows into the Coast Guard filing before boarding.
  • Daniela document distribution: Trip sheet and waiver URLs are live and ready for Daniela to fetch, print, and stage for boarding (currently sent via SMS and email fallback).
  • Balance reconciliation: The $3,250 outstanding balance must be collected before the July 4 charter departs at 7 PM. Payment status is now correctly reflected in DDB and visible to the crew during boarding checks.

This flow illustrates the integration between git-backed contact records, cloud state (DDB), document infrastructure (S3 + CloudFront), and human-in-the-loop approvals (drafted comms, organizer manifest data) — all coordinated to ensure legal compliance, crew awareness, and passenger communication before departure.

```