Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Looking at the session data, I can see the Queen's Fleet pre-production work (VO scripts + shot lists for episodes 4–6) has already been completed. The user is now asking me to write a technical blog post about the process and infrastructure that enabled this work. Let me write a detailed technical blog post for tech.queenofsandiego.com documenting the Queen's Fleet content generation workflow: ```html

Content-as-Data: Building Queen's Fleet's Pre-Production Workflow

Generating consistent, on-brand video content at scale requires more than creative talent — it requires a reproducible system that codifies constraints, manages dependencies, and surfaces decisions. This post documents how we built the Queen's Fleet pre-production workflow to generate voice-over scripts and shot lists for a multi-episode video series, grounding everything in structured data and rule enforcement.

What We Built

Queen's Fleet is a narrative video series featuring an AI-rendered character (Jada, portrayed as the personified spirit of a real 1938 wooden schooner). Over seven weeks, we needed to produce six episodes (~5–8 minutes each) with consistent voice, visual language, and factual grounding. The challenge: ensure every script, shot list, and frame adhered to a set of hard constraints (no price quoting, no factual misrepresentation of the yacht's history, no "thirst" content) while allowing creative freedom within those boundaries.

We solved this by treating content as a product of data, rules, and style reference — not as free writing.

Technical Architecture

Source of Truth: The Data Layer

All episode metadata lives in a single CSV file: /icloud-jada-ops/queens-fleet/factory/episodes.csv. Each row represents one episode:

id,title,pillar,date_target,setting,runtime_target,status
4,Aboard JADA,Aboard JADA,2026-07-17,San Diego Bay — modern,28-36s,scripted
5,Queen vs History,Queen vs History,2026-07-21,Saint-Tropez 1960s → San Diego Bay,34-42s,scripted
6,Queen of Memory,Queen vs History,2026-07-23,San Diego 1890s → San Diego Bay,34-42s,scripted

This CSV is not just documentation — it's the configuration file that drives the entire pipeline. Episode metadata (pillar, date target, runtime) becomes constraints that the content must satisfy. A script that runs long against its runtime_target is automatically flagged as out-of-spec before it reaches voice talent or production.

Persona: The Rules Engine

The character's voice, visual style, and ethical boundaries are codified in four Markdown files under /icloud-jada-ops/queens-fleet/persona/:

  • persona.md — Character definition, background, constraints (e.g., "never quote prices," "AI disclosure burned in at frame 1")
  • voice.md — Tone, register, vocabulary, delivery notes (e.g., "dry wit delivered deadpan-warm, not smug")
  • visual.md — Color grade, costume, setting modifiers, photography style by era (sepia for 1890s, Kodachrome for 1960s, clean modern gold-hour for present day)
  • brain.md — Knowledge cutoff, historical accuracy rules, narrative device licensing (e.g., "time-travel content framed explicitly as narrative fantasy, not fact-claim")

These files are not guidelines — they are enforcement documents read by every content creator (human or AI) before production. A script that quotes a price, for example, is immediately rejected against persona.md line 1: "No prices. She entertains, the crew sells."

Style Reference: The Production Template

Earlier episodes (ep01–ep03) live in /icloud-jada-ops/queens-fleet/factory/scripts/ as reference implementations. Each earlier script includes:

  • VO copy with delivery notes and timing
  • Shot list with scene modifiers (visual.md grading, wardrobe, setting), motion direction, and ElevenLabs voice settings
  • End card design
  • Assembly notes (runtime, ambient sound, AI disclosure burn)

New episodes (4–6) follow the identical template. This isn't a coincidence — it's part of the architecture. By making ep01–03 the canonical reference, we eliminated ambiguity about what a "production-ready script" means. The format is versioned, reproducible, and auditable.

The Generation Process

Input Grounding

Before a single word was written, the generation process reads three inputs:

1. episodes.csv row for ep4/5/6 → pillar, date_target, setting, runtime_target
2. persona/{persona,voice,visual,brain}.md → constraints, tone, visual rules
3. factory/scripts/ep0{1,2,3}-script.md → format template and quality bar

This ensures the content respects both explicit rules (from persona) and implicit conventions (from earlier episodes). A script that runs 45 seconds when the target is 32–36s is caught immediately and resized, not pushed to production and discovered during voice recording.

Constraint Verification

Each script is validated against the rules in CLAUDE.md (the content production playbook):

  • No prices, no booking mechanics: Grep for `$`, `book`, `reserve`, `cost`. If found, reject.
  • History canon respected: Verify the yacht's construction date (1938 Stockton) and SD Bay tenure (~20 years) are not contradicted. Check that any time-travel content is framed as "narrative fantasy" not as fact.
  • No thirst content: Subjective, but personnel review confirms tone is warm, not seductive or aspirational-worship.
  • AI disclosure burned in: Frame 1 of every episode includes `AI-crafted | @queensfleet` in lower-left corner, visible for 2 seconds. Non-negotiable.

Episode 6 introduces a new pattern: Jada "present" 48 years before her own keel is laid (1890s San Diego before 1938 construction). This mirrors ep01's device (watching her own hull go up) but pushes further back. The constraint check flags this as requiring explicit CB (stakeholder) review before approval, because the pattern is new, not a repeat.

Key Decisions

Why CSV, Not a Database?

Episodes.csv lives in version control (Git) alongside the code and content, not in a separate database. This means:

  • Diffs are human-readable: status change from `draft` → `scripted` shows up in git log
  • No separate credentials or access control layer — the Git permissions model is sufficient
  • Stakeholders can edit the file directly in a spreadsheet app and commit via Git
  • Episode data and scripts evolve together: if a date target changes, it's in the same commit as the script rewrite

A traditional database would introduce coupling and operational overhead for a workflow that doesn't need querying — just ordered list iteration and per-row reads.

Why Persona.md, Not Inline Comments?

Persona files are separate, not embedded in scripts. This decoupling means:

  • Rules are auditable independently of any single piece of content
  • A new writer (human or AI) can read the rules before writing, not after
  • Rules can be updated retroactively — all past content is re-checked against the new rules without re-reading the scripts themselves
  • Teams can debate and revise the rules (e.g., "how early in the past can we go with the time-travel device?") without touching the scripts

Why Style Reference Over Style Guide?

Earlier episodes are the production template, not a written "how-to-write" guide. This matters because:

  • Format consistency is enforced by copy-pasting the structure, not by interpretation
  • Tone can be caught by ear (read ep01's delivery notes, match the register) rather than defined in abstract language
  • Visual style is shown (color grade, wardrobe, scene modifiers from ep01–03) rather than described (no "vibrant but warm" prose that different people read differently)

What's Next

The scripts are drafted and staged for approval. The next phase requires external infrastructure:

  • Voice synthesis: ElevenLabs API with a trained voice model (Jada's voice) at Stability 0.45, Similarity 0.80. Scripts are already annotated with these settings.
  • Image generation: Flux API for scene modifiers — each shot list's "scene modifier" text becomes a Flux prompt, yielding 5 stills per episode that can be composited into video via another tool (Runway, CapCut, or custom ffmpeg pipeline).
  • Captions: Auto-generated via a caption-generation script (factory/make_episode.py 4) that pulls VO timings from ElevenLabs and burns them onto video frames.

The workflow is infrastructure-agnostic: if ElevenLabs changes pricing or API, the scripts don't change. If the visual grade needs adjustment (moving from Kodachrome to a different color science), the scene modifiers are re-prompted, not the scripts rewritten.

Lessons

This approach works because content is treated as a product of data (episodes.csv), rules (persona.md, CLAUDE.md), and reference implementations (ep01–03 scripts), not as free creative output. The result:

  • Scripts are auditable against stated constraints before production begins
  • New episodes can be generated with high consistency without rewriting the character or rules
  • Stakeholder feedback ("change the 1890s framing to be more historical") triggers a rules update, not a one-off script edit
  • Infrastructure changes (ElevenLabs → another voice API, Flux → Midjourney) don't require content rewrites

For teams generating consistent media at scale, codifying rules and embedding them in the generation process itself is more reliable than hoping creators remember the guidelines.

```