Brief → Scenario → Scenes: a Narrative-Ingestion Pipeline

A client sends what they have: a paragraph, a voice memo, a half-written scenario, sometimes a PDF deck. The storyboard stage downstream wants something different — a numbered shot list, with per-shot framing, angle, movement, lens, lighting. The translation between the two is the part that always runs over. Under deadline you skim the brief, write half the shot list, lose the why-this-shot-matters thread by the third entry, and hit save anyway. The same brief from the same client comes out differently every time, because nobody documented the steps.

What follows documents those steps as three LLM stages, so the brief-to-shot-list path is reproducible instead of reinvented per project.

The pipeline is the narrative-ingestion layer of a generative-video production system. Three stages turn a free-form client brief — plus optional knowledge-base files — into a structured, editable, shot-granular scene list ready for storyboard and stills generation downstream.

Stage 1 — Brief analysis

Inputs

• brief — free-form client text
• kbFiles — optional knowledge-base attachments, each carrying pre-extracted text (PDF, script, reference docs, notes)

Process

• LLM system role: professional production director
• Temperature: 0.4 (consistency-biased)
• Generous token budget (~12k) — the output is a structured shot list, not prose

Outputs

1. Project overview — style description, aspect ratio (16:9 / 9:16 / 1:1), estimated duration, technical notes.
2. Shot list — shots named in the {scene-number}{letter} pattern (1A, 1B, 1C, 2A, 2B, …) with:
   • description — seven-element rich prose (subject + action, location, framing, angle, movement, lens, lighting)
   • type — one of full-ai | composite | live
   • duration — seconds (commercial pacing of 0.2–0.8 is typical)
   • isKeyFrame — optional, "first" or "last", for frame-pairing transition stitching

Stage 2 — Scenario parsing

For projects where the user provides an already-written screenplay or narrative instead of a brief. Different entry point, same output shape.

• LLM at temperature 0.3 (deterministic), dynamic token budget scaled to scenario length.
• The LLM identifies logical cuts and splits them into shots using the same naming scheme.
• Same seven-element shot descriptions as Stage 1.

Stage 3 — Scenario editing

The loop between "first draft" and "what the user actually wants." Distinct from per-shot refinement steps, which edit one shot at a time. This stage edits the shot list.

Inputs

• Current shot list (JSON)
• Edit instruction in free-form natural language: "add a close-up of the product box before scene 2", "remove shots 3A–3B, merge 3C into scene 4."

Behavior

• The LLM applies only the requested changes and preserves all other fields verbatim — an edit-preservation discipline.
• Enforces camera variety: no two consecutive shots share identical framing.
• Re-indexes shot names when additions or deletions shift letter sequences inside a scene, so 2A/2B/2C stays continuous (never 2A/2C/2D).

Design choices that matter

"Scene" vs. "shot" — the scene-letter scheme

A scene is a narrative unit ("morning kitchen"). Inside a scene, shots are visual beats covering that unit from multiple angles. The {scene-number}{letter} naming is load-bearing:

• The scene number groups shots that share location, time, and continuity.
• The letter suffix orders shots within the scene.
• Shots inside a scene are treated as a series by downstream stages — they must stay visually consistent across the cut sequence.
• Shots across scenes may vary freely.

Seven mandatory description elements

Every shot description — at every stage — contains the same seven elements: subject + action, location, framing, angle, movement, lens, lighting. The scheme is not the same as A.O.C.; it's an upstream structure feeding downstream A.O.C. generation. It gives the storyboard stage enough to draw, and the stills stage enough to frame.

isKeyFrame and transition pairs

Shots marked isKeyFrame: "first" and isKeyFrame: "last" are explicitly paired for video-transition stitching: the "first" shot's render becomes the start frame, the "last" shot's render becomes the end frame for a single generated clip, producing a seamless morph transition. Setting this at brief time — not after generation — is what makes the downstream pairing automatic.

type: full-ai / composite / live

• full-ai — entire frame generated.
• composite — live-action subject + AI background.
• live — real footage, no generation; prompts are still generated as editorial guidance.

The type is set at brief/scenario time because downstream prompt generation depends on it — a stills prompt for a composite describes the foreground subject only, while a full-ai prompt describes the entire frame. Deferring this decision contaminates every subsequent stage.

Why three stages, not one

A monolithic "brief → shot list" prompt is tempting but produces brittle output. Splitting into analysis, parsing, and editing gives three properties:

• Two entry points. Some projects start from a brief, others from a screenplay. Same output shape lets every downstream stage stay agnostic.
• Edit-as-a-stage. The "edit instruction" loop has dedicated semantics — preserve-everything-else, re-index shot names, enforce camera variety — that don't belong in the initial-generation prompt.
• Per-stage temperature. Analysis tolerates a little creative interpretation (0.4); parsing of a hand-written scenario must not invent (0.3); editing should be near-deterministic. One temperature can't satisfy all three.

The whole pipeline is the part of the system that the LLM authors. Everything below it — storyboards, stills, video — operates on its structured output, never on the original brief.