7.6 Building Your Own SOP
Every chapter in this part describes a component. This one is the document that holds them together and makes the pipeline survive a bad week.
The test of an SOP is not that it looks professional. It is that on a Tuesday when you have two hours and no enthusiasm, you can follow it and produce something publishable.
The SOP format
Five fields per step, and nothing else:
| Field | Example |
|---|---|
| Step | Generate scene batch |
| Tool | Node graph t2i-persona-v3 via API |
| Threshold | 150 frames, stop at 25% failure rate |
| Owner | You (or a contractor from 12.x) |
| Time | 20 minutes including review |
Why thresholds rather than descriptions. A step that says "generate enough images" is not executable. A step that says "150 frames, stop if the failure rate exceeds a quarter" is. Thresholds are what turn a procedure into something you can hand to someone else — or follow at 11 p.m.
Why time estimates. They make the process visible. A production SOP totalling three hours is a different life decision than one totalling nine, and you cannot compare until the numbers exist.
SOP 1: one post
Target: 20 to 40 minutes end to end. If it takes longer, a step is missing or is being improvised.
| # | Step | Tool | Threshold | Time |
|---|---|---|---|---|
| 1 | Pull the next prompt variant | Prompt list (5.2) | One variant, no browsing | 1 min |
| 2 | Generate | Engine (7.2) | 3–6 frames for a still; 2–3 clips for video | 2 min |
| 3 | Technical screen | Eyes (5.6 stage 1) | Reject anything with a visible defect in 2 s | 2 min |
| 4 | Identity QA | 4.6 rubric vs sheet | Nothing scoring ≤2 survives | 2 min |
| 5 | Canon check | Bible + timeline register | Any contradiction is a reject | 1 min |
| 6 | Edit if needed | Post-processing (5.5) | Three attempts maximum | 0–10 min |
| 7 | Motion / voice / sync if video | 6.2, 6.5, 6.6 | Voice first, then video | 0–10 min |
| 8 | Assemble and grade | Editor + preset (6.7) | Delivery checklist | 3 min |
| 9 | Caption and hook | Templates | Hook generated deliberately, not chosen | 3 min |
| 10 | Disclosure check | 11.3 | Label present before scheduling | 1 min |
| 11 | Record metadata | System (7.4) | Automatic except score | 1 min |
| 12 | Schedule or publish | Scheduler behind the gate | Human decision | 1 min |
The two steps that most often blow the budget: step 6, because the three-attempt rule is not enforced, and step 5, because the The ten facts a persona cannot break, each specific enough to check in ten seconds. has drifted and the check requires thought. Both are upstream problems expressed at the last stage.
SOP 2: the week
Four slots. This is the rhythm the rest of the book assumes:
| Slot | Day | Duration | Purpose |
|---|---|---|---|
| Production 1 | Monday | 90 min | Generate, QA, schedule the week's first half |
| Production 2 | Wednesday | 90 min | Second half, plus any video |
| Production 3 | Friday | 60 min | Bank building: generate ahead of need |
| Review | Sunday | 45 min | Analytics, refill prompt list, asset audit |
Why three production slots rather than daily work. Batching is what makes an hour productive: one setup, one QA session, one upload run. Daily production means paying the setup cost five times.
Why a bank-building slot. Friday's output is not for this week; it is the buffer that makes the pipeline survive an illness, a trip, or a bad One production run, sized from the survival rate rather than from ambition.. Chapter 5.6's The four destinations decided at QA rather than later: publish, bank, retouch, or discard. needs twenty approved frames in reserve, and this slot is where they come from.
Why the review slot is separate and scheduled. Chapter 2.6's analytics reading, the The maintained set of forty reusable prompt variants, refilled in the weekly review slot. refill, and the quarterly asset audit (5.3) all live here. Unscheduled review does not happen.
SOP 3: the failure playbook
The document you write once and hope never to need. Four scenarios, with a first response for each.
A model or Under the AI Act, whoever develops an AI system or places it on the market under its own name. is discontinued or breaks. Response: switch to the second provider (7.5's two-vendor rule). Your keyframes, prompts, and references are provider-neutral, so this is a re-run rather than a rebuild. Precondition: you already tested clips on the second provider.
An account is restricted or banned. Response: appeal, and meanwhile publish on the secondary platform. Your canonical assets are outside the platforms (7.3), so the persona survives. Precondition: you have a second platform presence, even a small one.
A batch comes back wrong or off-identity. Response: stop producing, diagnose with 7.2's table, re-run the identity check against the The versioned plate of the persona's face and body that every generation is scored against.. Do not publish from the batch. Precondition: you have banked frames so a production halt does not mean a posting halt.
The month's budget is exhausted early. Response: 7.5's three readings — check the model choice, check the rejection rate, then decide whether the volume is genuinely higher. Precondition: you track Generation spend divided by frames passing QA; the metric that makes tier changes comparable., so you can tell which reading applies.
The common structure: each scenario has a first response and a precondition that must already be true. The preconditions are the reason this SOP is worth writing before you need it.
Versioning the SOP
The process ages. Models change, platforms change, prices change, and your own preferences change. A SOP that is three versions old produces a pipeline that no longer matches reality — and the failure is quiet, because the document still reads well.
Version it with a date and a reason, the same discipline as chapter 4.7's adapter versions:
sop-post.md v4 2026-10-01 new: disclosure step added before scheduling
sop-week.md v3 2026-09-15 changed: three production slots, moved bank to Friday
sop-failure.md v2 2026-08-20 added: video provider switch procedure
Review the SOP in the quarterly cadence (12.5's operations rhythm). Three questions: which step did I skip repeatedly, which step took longer than written, and what did I do differently that works? Each answer is an edit.
The step you always skip is the interesting one. Either it is unnecessary — remove it — or it is necessary and you are accumulating risk. Deciding which is a real operational decision, and it is one of the few places where noticing your own behavior changes the system.
Where this goes wrong
An SOP without thresholds. Not executable.
No time estimates. You cannot see the process.
SOPs that describe intentions, not steps. "Review quality carefully" is not a step.
No failure playbook. Every outage is improvised.
No bank. A production halt becomes a posting halt.
An unversioned SOP. It silently stops matching reality.
Never reviewing it. The step you always skip stays in, and the process stays broken.
The gate
- Does every step have a tool, a threshold, an owner, and a time?
- Does your one-post SOP fit in 20–40 minutes, and do you know which step blows it?
- Do you have four scheduled slots, including a bank-building slot and a review slot?
- Does your failure playbook cover model loss, account loss, batch failure, and budget exhaustion — each with a precondition that is already true?
- Is the SOP versioned with dates and reasons?
- Is the SOP reviewed quarterly, and have you removed a step you always skip?
What you leave with
A five-field SOP format where thresholds replace descriptions, a twelve-step one-post procedure with a 20–40 minute target and the two steps that usually overrun, a four-slot week with a bank-building slot and a scheduled review, a four-scenario failure playbook where each response has a precondition, and versioning discipline with three questions that keep the document true. Part VII is complete: the pipeline exists, costs a known amount, and survives a bad week.