A read of Don Vicente's production SOP for AI-avatar talking-head video — four locked assets, gated at every handoff, reviewed against a real render-queue bottleneck the source document names but doesn't fix.
Four stages, each closed off by a gate before the next can start. Nothing moves forward on an unverified asset.
12 numbered sub-steps sit inside these four stages — each with an explicit refusal condition (e.g. "any disk-file deviation from source," "audio speed manipulation," "spoken-word misalignment").
A 4-clip video is four sequential trips through one renderer. Nothing in the method parallelizes this — it's stated as unsolvable: "ONE RENDERER. ONE CLIP AT A TIME. ~28 MINUTES EACH. THAT IS THE ONLY REAL BOTTLENECK."
ElevenLabs audio is generated before rendering, to prevent accent drift and avoid time-stretching audio later.
55–60 words per 20-second render, targeting 3.20–3.81 words/sec — keeps delivery at a natural pace.
Validation checks the actual rendered file, never the prompt that was supposed to produce it.
Accepted clips are frozen. A failure downstream only re-cuts what's downstream — never re-rolls what already passed.
"Every clip can be perfect and the video still sounds broken where they meet." At least 0.45s of silence is now required at every join — added after Clip 3 sounded cut off despite passing every prior gate on its own.
The Aug 19 fix didn't just re-render the broken clip — it changed the gate itself so the failure class can't recur. That's rare discipline for a fast-moving pipeline.
Burned rooms, fingerprinted opening frames, and word-locked scripts remove the usual causes of continuity drift across a multi-clip avatar video.
"Nothing reaches you that a human has not watched" — a hard gate, not a suggestion, paired with an honest list of failure modes automation can't catch (finger count, brow drift, weak delivery).
Only failed clips re-fire. Approved clips are never touched again, so one bad render doesn't cost the whole video.
Your global lip-sync workflow and the DV Method's primary rule run in opposite directions on which side sets the timing.
Video's natural performance sets pacing. ElevenLabs supplies voice identity only — never generated first.
Voice sets the pacing target first; clips are cut to match it. A final timbre swap (Step 12) still preserves whatever timing the render actually produced.
If "scale" means more videos per day rather than more reliable single videos, the fix is outside this SOP — parallel renderer capacity — not more gates. The report itself calls this unsolvable.
Concurrent access to the renderer "silently drops" work and is handled by agreeing not to do that. It won't hold once more than one person or process touches the queue.
One-time-use backgrounds protect continuity but become an operational ceiling at volume — no mention of how the room ledger gets restocked.
Worth verifying this is actually free rather than pre-paid/sunk — the number matters a lot more once volume increases.
No mention of testing or versioning for the script chain. The Aug 19 note already describes one of them silently corrupting clip splits on a stray re-run — that class of bug can recur anywhere else in the chain.
| Metric | Value |
|---|---|
| Standard clip duration | 20 sec (fixed) |
| Target word fill per clip | 55–60 words |
| Speech cadence standard | 3.20–3.81 wps |
| Required inter-clip silence | ≥ 0.45 sec |
| Minimum mid-sentence breath | 0.36–1.08 sec |
| Render time per clip | ~28 min |
| 4-clip video, total render time | ~2 hours |
| Cost per render (claimed) | 0 credits |
Strong, honest SOP for never shipping a broken avatar video — the quality bar and failure-mode awareness are genuinely good, and the Aug 19 changelog shows real operational learning.
It is not yet a scale method; it's a correctness method that happens to run once per video. If the goal is throughput, the next document to write is about renderer parallelization and room/asset inventory management — not additional gates.