Map Sora jobs to Versely rows

Job first. Model second. The fastest way to waste credits after a sunset is to chase "something that feels like Sora" without writing down what each call actually did. Vibes do not migrate. Jobs do. Inventory every Sora call as a job, then map it to a live Versely row that can perform that job today.

This is operations, not film school. You are building a translation table: old request, required outputs, constraints, new row. When the table is honest, migration is boring in the best way. When the table is missing, every producer improvises and your look fractures across episodes.

Write the job before you name a model

Open a sheet with one row per historical Sora call pattern. Columns that matter:

• Job name in plain language (product turntable, talking demo, establishing night street).
• Duration and aspect needs.
• Audio needs (silent, native audio, VO later).
• Continuity needs (identity lock, wardrobe, prop handedness).
• Quality bar (hero, B-roll, sketch).
• How often you run it per week.

Notice what is absent: "cinematic," "dreamy," "like that one trailer." Those words feel good and sort nothing. A job like "5 second white-sweep product orbit for PDP embeds" can be priced, tested, and replaced. A vibe cannot.

If you are still building the wider plan, keep this sheet beside the Sora API sunset migration plan. The plan is the calendar. The sheet is the work. Teams that only have a calendar keep rediscovering the same missing shot types under deadline heat.

Group jobs by frequency. Daily jobs get proofed first. Monthly experimental jobs can wait. Hero shots that appear in paid media get stricter acceptance tests than connective B-roll. Not every row deserves the same credit budget.

Map jobs to live rows, not to nostalgia

Once jobs are listed, open the live catalog and choose rows by capability match. Start at models and filter by the job constraints you wrote. Text-to-video versus image-to-video, native audio versus silent, length ceilings, and edit features matter more than brand lore.

For contested choices, compare with a job lens, not a fan lens. A writeup like Seedance 2.5 vs Wan 3.0 vs MiniMax H3 is useful when you already know whether you need motion fidelity, prompt obedience, or cost control for that row. Reading comparisons before you know the job just recreates vibe shopping.

Record the mapping explicitly: job_id -> versely_row -> notes -> proof_clip_path. Notes should include failures you already saw. "Good on products, weak on tiny text" saves the next editor a day. Proof clips should be short and boringly decisive. If stakeholders cannot tell pass from fail in fifteen seconds, your acceptance test is mush.

Expect many-to-one mappings. Several old Sora patterns may land on the same Versely row with different prompts and reference stills. That is healthy. Expect a few jobs that need a stitch plan: generate beats separately, then edit. Multi-beat storyboard nostalgia does not obligate a single-call miracle on a new stack.

Run proofs like a lab, not like a moodboard

Pick one exemplar per job. Rebuild it on the mapped row with a fixed credit budget. Judge against the commercial checklist: readable subject, usable length, audio path, continuity hooks. Do not judge against "does it feel identical to Sora." Identical is mostly unavailable. Useful is the bar.

If the proof fails, change one variable at a time: prompt structure, reference image, row choice, or duration. Changing everything at once teaches you nothing and burns credits. Log the attempt. Migration without logs becomes folklore ("we tried that model, it was bad") with no reproducible detail.

Share proofs with the people who ship, not only with people who taste. An editor who has to caption and mix the clip will catch problems a still-frame review misses. A producer who has to hit a weekly cadence will catch cost problems a one-off demo hides.

When a mapping stabilizes, freeze it in the series bible. New freelancers should not invent a new row because a trailer impressed them on Monday. Trailers are not your job sheet.

Keep the table alive after sunset week

Migration is not a single weekend. After the deadline, review the sheet monthly. Retire jobs you no longer run. Split jobs that became two different quality bars. Update rows when a better match appears in the catalog. A living table prevents silent drift back into vibe shopping.

Price from the table. If a client package includes twelve product orbits a month, you can estimate credits from the mapped row and your keep rate. If your package still says "Sora-quality motion" with no job list, you are selling fog. Fog becomes margin pain.

When you are ready to turn the sheet into production habits, sign up for Versely and keep each job tied to a confirmable row so producers stop guessing under pressure. Job first. Model second. That order is how migrations stay solvent.

A practical workshop format helps stubborn teams. Spend ninety minutes listing jobs on stickies, cluster duplicates, then assign owners to write acceptance tests. Do not open the model catalog until the stickies exist. Catalog-first meetings turn into trailer parties. Job-first meetings end with a sheet you can price.

When two rows both seem to fit, keep both in a bakeoff for one week of real episode work, not one glamorous demo. Measure keep rate, credit spend per keep, and editor minutes to make the clip shippable. The winner is usually the boringly reliable row. Flashy demos hide cleanup costs.

Document prompt skeletons beside the mapping. A row without a prompt skeleton invites each freelancer to reinvent phrasing, which reinvents failure modes. Skeletons should include camera distance, subject nouns, motion limits, and what to avoid. Leave room for episode-specific nouns. Lock the grammar that protects continuity.

Finally, tell clients what changed in plain language. "We remapped product orbits to a live row with native-audio optional and a stitch path for multi-beat spots" is adult communication. "We switched to the new hot model" is how scope arguments start. Your mapping sheet is also a sales clarity tool.

Treat this as a weekly habit, not a one-time document. Reopen the checklist every Monday during busy seasons and ask what changed in tools, keep rates, and client expectations. Small updates prevent large apologies.

FAQ

Should every Sora clip get its own mapping?

Map patterns, not every file. If fifty clips are the same product orbit, that is one job with many instances. Unique one-offs can share a "special" bucket until they recur.

What if no row matches a job perfectly?

Split the job, stitch clips, or change the creative requirement. Perfect clones of a sunset system are a fantasy. Useful replacements are the craft.

Who owns the mapping sheet?

One producer owns it. Editors can propose changes. Unowned sheets rot, and then everyone remaps from memory during the worst week.