HISTORICAL DIG · JUL—AUG 2026
How should each shot choose its generation route?
Under one “video generation” label sit different routes: text-to-video, image-to-video, first-and-last frames, subject reference, video-to-video, and native audio. Repeating a shot through the wrong route turns a capability mismatch into an apparent prompt problem.
AI SHORT-DRAMA MOTHER WORKFLOW · NODE 04
Relation to the current subject
Node 03 freezes assets and states; node 04 decides which control route deserves one probe.
Name the dominant control per shot, then select the highest-risk one. Only two routes that could meet the hard acceptance rule may enter the pre-call check. Inputs stay equal, each route gets one call, and a third route cannot hide failure.
Record state at the time
- AI short drama
- Model roles
- Standard record
- Developing
- Historical E2 · three maker capability sources and one integration issue rechecked · no BitShovel same-shot comparison
R7 CURRENT JUDGMENT
Judgment at the time
Choose what the shot must control before choosing a model; close unknown boundaries before upload.
Open full rationale and return rules
Node 04 is not a model ranking. Assign one dominant control to every accepted shot: T2V may explore composition, I2V may carry one anchor, first/last may constrain exact end states, reference mode may hold a subject, and V2V may carry authorized motion. Native audio stays off unless it will not conflict with planned dialogue. Open a probe only for the highest-risk unresolved shot and retain no more than two currently available routes. Both use the same node-03 assets, shot state, and acceptance rule; each gets one call, and every route-specific adapter is recorded. Before upload, record the exact service, model or endpoint version, check date, region, data and retention boundary, commercial-use boundary, audio default, and input hash. An unknown closes the route. A pass only admits one route to the node-05 cost ledger; it proves no consistency, quality, privacy, repeatability, or product value.
- Who it was for
- People who passed node 03, hold unique asset versions, entering and leaving states, and a hard acceptance rule, and need the smallest generation route for one high-risk shot
- Why it mattered then
Open note
Starting from model names lets route, version, region, data boundary, and cost change together, leaving failures unlocatable. Naming the shot's dominant control first limits the comparison to two routes that could answer the actual uncertainty.
- Where the judgment stops
Open note
This is an unrun, unfrozen fixed-input route probe—not a model recommendation, ranking, benchmark, prompting tutorial, or buying guide. BitShovel has not uploaded material, called a model, generated a shot, paid, compared output, or completed a short drama. Maker material establishes published entry points on the check date only, and one ArcReel issue says only that the reporter's custom endpoint differed from the interface discovery list.
BEFORE OPENING A MODEL PROBE
Fit check
Return to node 03 or node 02 while the asset contract or shot acceptance rule remains ambiguous.
This record may help
- Node 03 has resolved the shot to unique asset versions, first and last states, and one non-negotiable acceptance rule.
- Only one control capability remains unknown, and a bounded probe can use frozen, non-sensitive, cleared input.
Do not use it yet when
- Cast, setting, prop versions, or rights receipts remain ambiguous; return to node 03.
- The shot's change, duration, or acceptance rule remains unclear; return to node 02.
- You need BitShovel to recommend a best model or prove stable reproduction, privacy, value, or commercial permission—this record has none of those results.
HISTORICAL TRIAL · UNRUN, UNFROZEN 60–75 MINUTE BOUNDED ROUTE PROBE
Historical trial
One highest-risk shot, no more than two routes, and one call per route.
- Time needed
- A 60–75 minute ceiling for one highest-risk shot; this round remains unrun
- Likely cost
- At most two model calls, one per candidate; no annual plan and no prompt-tuning loop
- Permission boundary
- Use only non-sensitive, cleared node-03 assets; do not call when region, upload, retention, or commercial boundary is unknown
- 01
First step
Open this step
Write one dominant-control hypothesis and one hard acceptance rule per shot. Select the highest-risk shot and retain at most two routes. Freeze asset versions, first and last state, and input hashes. Record service, model or endpoint version, check date, region, data retention, commercial boundary, audio default, and route-adapter differences. Only when every field is clear does each route get one call.
- 02
What should exist
Open this step
A per-shot dominant-control table, one frozen probe packet, no more than two pre-call checks, and a pass, return, or close route decision.
- 03
How to tell it worked
Open this step
The hard acceptance rule admits at most one route whose exact version, input, and single result can be replayed. A pass only sends that route to node 05 for actual cost accounting.
- 04
Stop when
Open this step
Stop when the node-03 contract is incomplete, candidates exceed two, any pre-call field is unknown, a route rewrites the shot or assets, one result exceeds the cap, or neither route meets the hard acceptance rule.
- 05
How to back out
Open this step
Keep input hashes, versions, and failure classes. Return to node 02 for the shot, node 03 for the asset, or use still boards, limited motion, and manual compositing. Do not add a third route or batch generation.
BITSHOVEL R7 ROUTE PREFLIGHT · FIXED FICTIONAL INPUT
Method and interfaces
Both routes match a capability, yet both stay closed because region and data receipts are unknown.
Open method boundary
The visual contains no provider, model, account, or generated frame. It separates “the capability looks relevant” from “the call is permitted” and keeps a stop line before upload.
DEMO ROUTE 04 shows decision structure only: choose the dominant control from one frozen shot, then check no more than two routes. Service, account, model, region, and cost are absent; the call stays closed because data and region are unknown. This is not a model comparison or generated result.
About this image and its source
Created by BitShovel on August 17, 2026 with no real project, prompt, account, key, provider, uploaded material, or generated frame.
Open source page ↗SOURCES AND EVIDENCE
Sources and evidence
Three maker capability descriptions and one custom-provider discovery issue explain why exact entry points and versions need records. They do not establish quality, availability, region, data, price, or a BitShovel result.
Open evidence boundary
Historical E2 remains the old-page label. Revision 7 rechecks maker capability descriptions for Google Flow, Seedance 2.0, and Kling Video 3, and narrows ArcReel #1700 to one custom-provider discovery issue. None establishes a route for a BitShovel shot or supplies regional, data, cost, or same-shot results.
- 01Maker capability matrix · Rechecked
Google Flow separates first-frame, first-last, and reference entry points by Veo version
Open source boundary
The official table supports naming capability and version before a call. It does not establish output quality, regional availability, or access in a BitShovel account.
Open original source ↗ - 02Fixed maker version · Rechecked
Seedance 2.0 describes text, image, audio, and video inputs
Open source boundary
This is a historical 2.0 capability example, not the current best or latest route and not proof of a BitShovel run, stability, or commercial permission.
Open original source ↗ - 03Maker workflow guide · Rechecked
Kling Video 3 describes automatic and custom multi-shot and subject controls
Open source boundary
The maker guide helps identify route entry points. It is maker material, not independent stability evidence or a same-shot comparison.
Open original source ↗ - 04Specific integration issue · Rechecked
ArcReel #1700: one custom endpoint differed from the interface discovery list
Open source boundary
The reporter says custom happyhorse-1.1-t2v worked directly in ArcReel 0.24.0 while interface discovery exposed 1.0. It supports recording exact endpoints and discovery differences, not that all static lists are stale or the model is generally available.
Open original source ↗
REVISION RECORD
Revision record
R7 replaces a three-shot, six-row comparison with one unknown, two routes, and no more than two calls, while correcting the old generalization of the ArcReel case.
Open 7 revisions
- Revision 1
Stopped chasing one universal model and routed by shot requirement, fixed input, and failure route.
- Revision 2
Named T2V, I2V, first-last, reference, V2V, and native-audio routes and added an interface-discovery mismatch case.
- Revision 3
The old site replaced an editorial generated hero with an openly licensed released-film frame and moved product and process UI downstream.
- Revision 4
The old site began assigning source visuals by production task instead of using one film across every step.
- Revision 5
The old site reiterated the boundary between released narrative footage and process-product interfaces.
- Revision 6
Removed narrative hero media unrelated to model routing and retained traceable task-specific sources.
- Revision 7
Narrowed the node to one high-risk shot, two routes at most, and one call each; added a pre-call stop line and corrected the ArcReel report to one custom-provider discovery issue.
WHAT THIS RECORD LEAVES
What this record leaves
Node 04 does not produce a “best model.” It produces one explainable, stoppable route that may enter the cost ledger.
A pass only means node 05 may record actual spend, labor, retries, and accepted seconds for this route. If both fail, return the shot or asset, or use still boards, limited motion, and manual compositing; do not add a third route.
Back to the Dig index