Claude in the run-of-show: what works, what doesn't.
By Dr. Vincent W. Allen, DPS · May 2, 2026 · 5 min read · Part of AI-Native Broadcast Operations
A 23-page run-of-show lands at 6:14pm. Doors at 8:00am tomorrow. The client edited four sections since the last version. Here's the prompt that gets you to a usable cue list before dinner.
What Claude is actually good at, in this seat
Three jobs, all squarely in the model's strengths:
- Cue list extraction. A run-of-show document has segments, talent transitions, audio cues, video cues, lower-third triggers, presentation slide breaks, Q&A windows. Pulling those into a structured table is what the model does in 30 seconds and what an exhausted operator does in 90 minutes at 11pm.
- Version diffing. The client sent v3 at 6:14pm. You have v2. What changed? Claude tells you in a one-paragraph summary plus a section-by-section diff, in the format you specify.
- Conflict flagging. "Segment 4 ends at 9:42, segment 5 starts at 9:41. Audio source changes mid-talk — is the lavalier swap accounted for? Q&A is scoped for 15 minutes but the run-of-show only allocates 8." The model surfaces these in a numbered list.
What Claude is bad at, in this seat
Three jobs the model will hallucinate confidently, every time:
- Equipment-spec answers. "Will this cue work on a Blackmagic Constellation 8K?" The model will give you an authoritative-sounding wrong answer. Never trust the model on hardware specs. Cross-check against the manufacturer doc, every time.
- Live calling. "Should I cut to camera 2 or stay wide?" That's TD judgment under live pressure. The model has no situational awareness, no audio cue, no read on the talent's energy. It is not in the seat.
- Vendor-specific bug knowledge. "Does TriCaster TC2 still have the latency drift on the M/E1 bus when…?" The model's training data ages out of vendor firmware reality. Operators who've shipped on the equipment know. Models guess.
The prompt pattern I use
Here's the rough scaffold. Don't copy it verbatim — your client's run-of-show format is different. But the structure transfers.
You are reviewing a run-of-show document for a live broadcast. Audience: institutional investors / corporate town hall / cultural broadcast. Production stack: [Blackmagic Constellation, Crestron, Evertz, Resolume]. My role: Technical Director on the live desk. Tasks, in this exact order: 1. Extract a structured cue list. Columns: segment_number, time_start, time_end, cue_type (audio/video/lower-third/transition), action, notes. 2. Flag any conflicts: - Segments that overlap in time - Audio source changes without a documented swap - Cue-type collisions (e.g., simultaneous LT triggers) - Q&A allocations that don't math out 3. Diff this version against [paste prior version]. Summarize changes by section in plain English. 4. List the three things I should personally verify before doors. Do NOT include things you'd typically delegate to a comms producer or stage manager. Do not invent specs. If a cell is ambiguous, say "ambiguous — clarify with [role]."
A note on confidentiality
If you're working inside a Fortune 500 environment, the run-of-show is privileged information. Use the enterprise tenancy your client provides. Do not paste investor-day cue lists into a personal Claude account. The Intuit engagement I'm currently in operates inside a $500/month per-employee AI-development token budget — institutional access with appropriate data handling. That's the bar.
Bottom line
Claude in the run-of-show is a force-multiplier for the pre-show and immediately-pre-show window. It is not a TD. The judgment loop stays human. What changes is how prepared the human is when they sit down. Read the pillar essay for the full four-layer stack, or jump to GPT-4 for site reports for the post-show side of the workflow.