# Kling pipeline action items — derived from blog notes + live findings Status: working execution note Captured: 2026-03-29 Basis: - live API probing in this repo - continuity experiments - external blog-note summaries under `docs/current/` ## Purpose This document converts external positioning material plus our measured behavior into concrete pipeline decisions and next steps. ## Executive summary The main gap is no longer “does the API work?” The main gap is “how do we reproduce the marketed quality level, especially around continuity and subject stability?” Our live work already established that the core create/query paths work. The next phase is quality reproduction and workflow tuning. --- ## What is already strong enough to treat as working baseline ### API / contract baseline - Auth path works: AK/SK -> JWT Bearer - API base works: `https://api-singapore.klingai.com` - Query single/list endpoints are real and usable - Working creation families for the current production-facing layer now include: - text2video - image2video - omni-video multi-shot - broader docs-corpus routes such as `reference2video` / `multi-image2video` should not be read here as part of the current production-default layer - `mode='std'` works; `standard` does not - Omni multi-shot requires `multi_prompt[]` items with at least: - `index` - `duration` - Inline base64 image input is valid ### Quality / behavior baseline - Text generation baseline is reproducible - Image/reference generation works with sufficiently valid images - Omni multi-shot works technically and returns final videos - But continuity is not automatically seamless across shot boundaries --- ## High-confidence interpretation from combined sources ### Kling VIDEO 3.0 Treat as: - prompt-first - semantic-control / directing-first - stronger fit for text-led exploration and multi-character scenes ### Kling VIDEO 3.0 Omni Treat as: - reference-first - identity-lock / production-consistency-first - likely best when using richer assets, especially element/video-reference workflows ### Operational implication We should stop expecting “text-only custom multi-shot” to fully reproduce the strongest marketed Omni continuity. If we want blog/demo-level stability, we likely need to move upward in workflow sophistication: - stronger element binding - reference-heavy prompting - possibly video-reference-driven subject anchoring - tighter storyboard discipline --- ## Concrete pipeline decisions ### Decision 1 — Separate contract verification from quality reproduction Do not mix these tracks. #### Track A: contract verification Purpose: - confirm path / fields / response schema / callbacks / cost #### Track B: quality reproduction Purpose: - reproduce reference-grade continuity / consistency / subject lock Reason: - cheap probe prompts are good for API truth - cheap probe prompts are not good enough for marketed-quality reproduction ### Decision 2 — Use external image sourcing whenever possible Do not spend Kling credits generating still inputs unless necessary. Reason: - image/reference experimentation consumed meaningful spend - external still sourcing is cheaper and often good enough for video-generation inputs Pipeline impact: - source stills externally when possible - reserve Kling spend for video generation and quality-critical reference workflows ### Decision 3 — Treat multi-shot as storyboard sequencing, not guaranteed seamless continuation Reason: - our continuity tests showed angle-boundary disruption even when the overall scene context stayed similar Pipeline impact: - do not market or internally assume multi-shot = seamless one-take - describe it as shot-sequenced continuity unless proven otherwise for a specific workflow ### Decision 4 — Prioritize richer reference workflows for Omni experiments Reason: - blog material consistently pushes Elements / Character Identity / video reference / subject locking - our current tests were still relatively lightweight Pipeline impact: - next Omni quality tests should prefer: - multi-image reference - stronger character/prop anchors - if possible, short video-reference workflows --- ## Next critical experiments These experiments are explicitly designated as the next core quality-reproduction work, but deferred for later execution. - C1 — minimal shot delta continuity baseline - C2 — moderate shot delta continuity test - R2 — single-image anchored continuity test - R3 — multi-image reference continuity test - R4 — video-reference / element-driven continuity test Current status: deferred intentionally; keep as priority experiments for the next quality-focused phase. ## Immediate next action items ### A. Documentation / code sync 1. Update validators/builders to better reflect measured multi-shot requirements - ensure `multi_prompt[].index` is treated as required for Omni multi-shot 2. Keep explicit “confirmed vs marketing-claimed” labels in docs 3. Continue storing external notes separately from contract docs ### B. Continuity experiment design 1. Build a dedicated test matrix for continuity - same scene + same subject + minimal camera delta - same scene + same subject + moderate camera delta - same scene + same subject + aggressive camera delta 2. Score outputs on: - identity continuity - scene continuity - camera continuity - boundary visibility 3. Identify the “best tolerable shot delta” envelope ### C. Reference-strength experiments 1. Compare these workflows directly: - text-only multi-shot - image-anchored multi-shot - multi-image reference multi-shot - video-reference or element-driven workflow (if accessible) 2. Hold scene concept constant while changing only the anchoring method 3. Measure whether stronger references reduce angle/identity drift ### D. Callback / production reliability 1. Set up externally reachable callback URL 2. Capture real callback payloads 3. Confirm callback auth / signature / headers if present 4. Store canonical payload examples in docs ### E. Extend-video truth finding 1. Keep testing with source videos generated from eligible models only 2. Separate “endpoint exists” from “source eligibility is satisfied” 3. Do not depend on extend for production design until eligibility rules are proven --- ## Prompting rules to adopt now ### For continuity-oriented multi-shot tests - keep environment fixed - keep time-of-day fixed - keep subject identity fixed - keep direction of movement fixed - reduce shot-to-shot camera change - write shots in strict chronological order - make overlap between adjacent shots very high ### Avoid for continuity tests - wide-to-close jumps that are too aggressive - angle reversals unless explicitly testing breakpoints - changing environment descriptors between shots - changing subject descriptors between shots --- ## Data / artifact organization rules ### Keep using these categories - `kling-api-reference.md` → measured contract / live truth - `kling-api-series-3-spec.md` → series 3 spec interpretation - external blog notes → positioning / workflow guidance only - history JSONs → raw run evidence - downloads / judge outputs → visual proof artifacts ### Why this structure matters It preserves the distinction between: - measured truth - vendor positioning - workflow hypothesis - user judgment of actual outputs --- ## Current bottom line The pipeline is no longer blocked on API uncertainty. The next bottleneck is quality-reproduction discipline. That means the next meaningful improvements will come less from endpoint discovery and more from: - better references - better storyboard design - better continuity test design - stronger callback / production observability ## 2026-03-29 contract upgrade — Omni first-frame path - New confirmed Omni image-reference path: - `image_list[].image_url + type='first_frame'` - This should replace our earlier weaker assumption that Omni would accept reference-style `image_list[].image` payloads. - Future Omni reference quality tests should prefer this path over the plain `image` field when testing real image-to-video conditioning. ## 2026-03-29 spend-control rule - Every create call is billable unless proven otherwise. - Schema/body-shape probing must be treated as real spend, not harmless validation. - First successful create ends the probe round. - If more than one create is needed for the same immediate purpose, get explicit approval first with expected count and unit exposure. ## 2026-03-29 SOT execution discipline - Qingque-derived API reference must be consulted before any new create payload is attempted. - If a field/workflow is not present in SOT, treat it as hypothesis-only. - Hypothesis-only payloads should not be sent to billable create endpoints without explicit approval. ## 2026-03-29 policy decision — single-scene ceiling = 15s - Treat 15 seconds as the maximum target length for one scene. - Do not use chained short clips as the default method to simulate one continuous scene. - Keep clip-linking logic only for transitions between distinct scenes where broader narrative continuity still matters.