# Kling `video_list` / `video_list + element_list` closeout plan Status: active verification-design document Captured: 2026-04-01 ## Purpose This document defines how to close the remaining major runtime-semantic residuals around: - `video_list` - `video_list + element_list` The goal is not vague experimentation. The goal is to reduce the remaining ambiguity to explicit terminal states under the stricter 100%-closeout target. --- # 1. What is already closed ## 1.1 `video_list` existence / shape Already closed strongly enough by preserved docs and current live evidence: - `video_list[]` exists - current visible contract is URL-shaped through `video_url` - base64 shoved into `video_url` is not accepted - reachable remote URL usage is accepted - current practical continuity reading is scene-to-scene reference, not exact same-clip extension - additional runtime finding from current testing: create-level acceptance appears sensitive to the **reference video's duration**, not just the child payload duration ## 1.2 `element_list` practical existence Already closed strongly enough by preserved docs + live testing: - element create works - element query works - element IDs can be attached in Omni generation - `element_list + sound="on"` works in current tested scope ## 1.3 What is not yet closed The remaining question is not whether these surfaces exist. The remaining question is: > what exactly do they do when used for continuity-sensitive production work? --- # 2. The remaining open questions ## A. `video_list` continuity-strength question Question: - when clip B references clip A through `video_list[].video_url`, how much continuity actually carries over in practice? This should be evaluated on: - subject continuity - wardrobe continuity - scene layout continuity - camera-angle / shot-language carryover - motion/style continuity - edit usability Important: - do **not** frame success as exact extension - do **not** judge against frame-perfect continuation - judge against practical edit-usable continuity ### Newly discovered runtime constraint from current testing - a parent/reference video longer than 10 seconds can trigger upstream rejection even when the child clip duration is short - current evidence suggests the constraint is on the **reference video fed through `video_list`**, not merely on the child duration field - a 15-second parent clip produced a 400 error with `Video duration can not longer than 10s` - after switching to a 5-second parent reference, create-level acceptance succeeded again, including 7-second and 3-second child probes Current operational reading: - continuity chaining should assume a **reference-video ceiling of 10s** unless stronger contrary evidence appears - use 10s-or-shorter parent clips for `video_list` chaining - do not over-generalize the earlier error as `child duration must be <= 10s`; current evidence points more strongly to `reference video must be <= 10s` ## B. `video_list` control-surface question Question: - does `refer_type='feature'` materially outperform `refer_type='base'` for the current intended continuity use? Current policy reading: - `feature` is the stronger current candidate for continuity semantics - `base` is a secondary comparison only if needed ## C. `video_list + element_list` complementarity question Question: - when both are supplied, does the result plausibly behave like: - `video_list` = scene continuity surface - `element_list` = recurring identity surface This is the most important residual question. Success would not mean perfect obedience. Success would mean: - continuity is not obviously broken by adding `element_list` - identity is not obviously lost by relying on `video_list` alone - the two surfaces appear complementary rather than mutually destructive ### Create-level update Current testing has now upgraded this from pure hypothesis to partial live acceptance: - with a 5-second parent reference, `video_list + element_list + sound='off'` achieved create-level acceptance for both 7-second and 3-second child probes - this does **not** yet close output-quality parity - it does close an important contract question: the combination is not rejected categorically at create time when the reference video stays within the shorter runtime envelope ## D. Audio interaction boundary question Question: - should continuity-focused `video_list` runs continue to be treated as `sound='off'` only, per current recovered docs, even if other Omni routes support native audio? Current safest reading: - yes, keep `sound='off'` for the `video_list` path unless stronger contrary evidence emerges Current enforcement status: - local validator currently enforces `sound` omitted/off whenever `video_list` is present - current live/create testing has not overturned that rule This item may be closable by classification rather than by spending. --- # 3. Closure philosophy Do not try to prove too much in one round. Each run should answer only one main question. If one run can settle a classification boundary cleanly, stop there. The right target is: - minimal billable creates - maximal semantic clarity --- # 4. Minimal verification ladder ## Round 1 — `video_list` continuity baseline ### Purpose Verify that short-window chaining with a fresh Kling URL can produce practical continuity carryover. ### Inputs - parent clip A: already-generated Kling clip with clearly recognizable people / wardrobe / scene - child clip B: new prompt continuing the scene logically - `video_list = [{ video_url: , refer_type: 'feature', keep_original_sound: 'yes' }]` - `sound='off'` ### Success criteria - child clip still reads as the same scene family / same people / same wardrobe / same visual world - continuity is good enough for edit use - result does not need to be exact extension ### Terminal states - fully closed by live verification if practical continuity is clearly present - or closed by explicit weak-result finding if continuity is too weak to recommend operationally ## Round 2 — `video_list` refer_type comparison (only if Round 1 leaves ambiguity) ### Purpose Compare `feature` vs `base` only if `feature` does not already answer the practical question clearly enough. ### Principle Do not spend on this if Round 1 already yields a confident operational answer. ### Terminal states - close by live comparison if necessary - otherwise close by explicit non-need / not worth extra spend ## Round 3 — `video_list + element_list` complementarity test ### Purpose Test whether recurring identity assets and continuity reference can coexist constructively. ### Inputs - parent clip A with known people - child clip B with: - `video_list` referencing parent clip A - same people attached through `element_list` - no audio (`sound='off'`) for the cleanest continuity reading ### Success criteria - continuity still reads plausibly - identities still read plausibly - no obvious collapse suggesting the two mechanisms are fighting destructively ### Terminal states - fully closed by live verification if complementarity is reasonably clear - or closed by explicit negative finding if the combination degrades continuity/identity enough to reject the pattern operationally --- # 5. Recommended test-scene design ## Best scene type for continuity tests Use a scene with: - 1 or 2 clearly recognizable people - stable wardrobe - stable lighting - simple but distinctive environment - obvious camera/pose continuity potential Avoid for the closeout round: - overly crowded scenes - high moderation-risk content - too many moving props - audio-heavy dialogue complexity - multi-shot complexity Reason: - closeout testing should isolate continuity, not mix multiple uncertainty sources --- # 6. Evaluation rubric For each run, score these dimensions qualitatively: ## Subject continuity - do the people still read as the same people? ## Wardrobe continuity - does clothing stay compatible with the parent clip? ## Scene continuity - does the child clip feel like the same environment/world? ## Camera-language continuity - does the shot feel plausibly adjacent in the same scene sequence? ## Edit usability - would an editor plausibly cut A -> B without it feeling like a total reset? The correct standard is not perfection. The correct standard is production usefulness. --- # 7. What to avoid claiming Do not claim any of the following unless directly proven: - exact same-clip extension - full speaker/audio continuity through `video_list` - guaranteed compatibility of every `element_list` identity setup with every `video_list` continuation case - frame-exact carryover The closeout target is practical truth, not inflated truth. --- # 8. Expected closeout outcomes ## Best-case outcome - `video_list` is live-confirmed as a practical scene-continuity tool - `video_list + element_list` is live-confirmed as a practical continuity + recurring-identity combination - `sound='off'` remains the clean current rule for continuity-focused `video_list` runs ## Acceptable outcome - `video_list` works only moderately well, but still enough to justify its current fallback role - `video_list + element_list` is mixed, and therefore classified as usable-with-caution rather than a default recommendation ## Negative-but-valuable outcome - one or both patterns prove weaker than hoped - but the classification becomes explicit and the ambiguity is closed That still counts as closeout progress. --- # 9. Immediate next move Before any billable verification run: - classify each planned payload as `doc-derived`, `live-confirm extension`, or `hypothesis-only` - name the exact create count in advance - state the hard stop condition in advance - keep the first round as small as possible The next practical verification candidate should therefore be: > one minimal `video_list` continuity run using a fresh parent Kling URL, `refer_type='feature'`, `sound='off'`, and a deliberately continuity-readable scene.