Five drafts total before a single shot ever gets generated. Separating “find what’s wrong” from “fix what’s wrong” into different passes is the same principle I used on the visual side of this pipeline, just applied to prose instead of shots.
Everything I’ve posted so far about consistent AI shots assumes a script already exists. It doesn’t start there.
Before any image is generated, a topic goes through 8 automated steps to become a full 22 to 28 minute script. Completely different problem from the visual side. 🧵
The dependency graph isn’t a separate system sitting on top of the worker pool. It’s encoded directly in the query itself. No locks, no orchestrator, the database query is the dependency graph.
Parallel workers generating hundreds of shots is easy. Parallel workers generating shots where shot 47 needs shot 1 to finish first, and neither one knows the other exists, is not.
Here’s how I sequenced dependency-aware generation with nothing but SQL. The setup:🧵
If the anchor generation fails for some reason, downstream shots don’t crash and they don’t end up in some broken state. They just sit pending until it succeeds.
Planning and rendering are different jobs. Asking a model to decide what should happen and how many shots that needs, at the same time it’s deciding what something looks like, makes both decisions worse. Separating judgment from generation fixed both.
“Just generate 200 shots for this script” sounds simple. It also produces uneven, tone-deaf coverage, because the model is planning and rendering in the same breath, with no view of the whole story.
We split it into two passes instead. Here’s why that mattered. 🧵
Only after that plan is locked does actual shot generation happen.
Skip the planning phase and you get two failure modes at once, gaps where a key beat gets zero real coverage, and dumps where a throwaway line gets five shots it didn’t need.