To manage change requests in AI video production, record each requested change against a specific approved version, classify why it is needed, identify every affected production asset, and decide whether to accept, revise, defer, or reject it before work resumes. The decision should state the new approval owner, delivery impact, and evidence required to close the request.
That is the direct answer. A comment such as “make the character warmer” or “use the new product message everywhere” may sound like one revision, but it can affect references, shots, voice, captions, localized versions, edit timing, and final files. A useful workflow turns the comment into a bounded production decision instead of allowing it to spread invisibly through the project.
Distinguish a correction from a change
Not every review note is the same kind of work. Classify the request before discussing how to execute it.
- Correction: the current work does not meet an already approved requirement, such as the wrong product color, an omitted line, or a continuity error.
- Refinement: the approved direction remains valid, but a bounded adjustment may improve clarity, performance, framing, rhythm, or emphasis.
- Scope change: the team wants a new audience, message, scene, character state, market, aspect ratio, language, runtime, or deliverable.
- Source change: an approved script, product file, character reference, brand asset, voice direction, or other governing input has been replaced.
- Risk escalation: a source, identity, claim, usage, or release question needs a different reviewer or further assessment before production continues.
This classification matters because the decision paths are different. A correction should be tested against the existing acceptance criteria. A scope or source change requires an impact review. A risk escalation may need the affected work to pause even when the requested visual edit is simple.
Do not use the categories to avoid responsibility or debate fees inside the creative review. Use them to establish which approved assumption changed and what decision is now required.
Anchor every request to a reviewable version
A change request should identify exactly what the reviewer saw. Include the file or review link, version identifier, date, timecode or shot identifier, language and format where relevant, and the approval stage.
Without that anchor, the production team may correct a newer edit using a note written against an older one. The same phrase can also mean different things in a storyboard, pilot, picture lock, localized version, or final export.
Use stable identifiers for important source files and outputs. If an approved script or reference changes, create a new version and preserve the relationship to the earlier decision. The project’s change record does not need every working preview, but it should show which approved state the request would replace.
This approach complements a project provenance record, which connects important inputs, production events, approvals, and delivered files. The change request adds the reason and decision for moving from one controlled state to another.
Write the request as an observable outcome
Rewrite subjective comments into a result that reviewers can assess. A complete request can contain:
- Location: the sequence, shot, line, asset, or version affected.
- Observed issue: what the reviewer sees or hears in the current version.
- Required outcome: what must be true after the change.
- Reason: the approved requirement, audience need, source update, or release condition behind it.
- Owner: the person authorized to accept the revised result.
- Priority and decision date: when the request must be resolved relative to production and release.
For example, “the product needs more impact” is not yet testable. A more useful request might say that the product name is not readable during the final call to action and must remain legible for the approved end-frame duration. The second statement gives production a specific communication problem without prescribing an untested visual solution.
When the outcome is deliberately exploratory, say so. The team may commission two bounded alternatives before choosing a direction. Exploration should still have a decision owner, a stopping point, and a statement of what the alternatives are intended to resolve.
Trace the dependency chain before estimating the change
Review both upstream inputs and downstream outputs. A request may affect more than the visible shot.
Check the dependency chain across:
- Brief, message hierarchy, script, treatment, or adaptation rules
- Character, product, environment, camera, typography, and continuity references
- Storyboard, shot list, timing pass, and production-method decisions
- Selected shots, composites, edit, transitions, graphics, voice, music, and sound
- Captions, transcripts, on-screen text, accessibility assets, and language versions
- Landscape, vertical, square, cut-down, clean, and market-specific versions
- Review records, approved masters, delivery manifests, and archive files
A source change near the top of this chain can invalidate several approved items below it. A request limited to one export may have no effect on the creative master. Mark the boundary explicitly instead of assuming every change is either trivial or global.
Dependencies and review windows belong in the production schedule. For change control, the same map shows where work must be reopened and which later tasks should wait.
Assess impact before production resumes
Create a concise impact note for any request that changes an approved input or milestone. It should answer:
| Area | Decision question |
|---|---|
| Creative | Does the story, message, performance, visual system, or edit logic change? |
| Production | Which assets, shots, sequences, or methods must be revised or rebuilt? |
| Versions | Which formats, languages, captions, graphics, audio tracks, or market files are affected? |
| Review | Which earlier approval is reopened, and who can approve the replacement? |
| Delivery | Does the request change the required package, sequence of work, or target date? |
| Source and identity | Does it introduce or replace protected material, a recognizable person or voice, a product fact, or a property rule? |
Do not promise that AI makes every change fast. A generated or composited shot may depend on selected reference states, adjacent continuity, edit timing, and approved sound. Changing one element can require a controlled rebuild rather than a local adjustment.
The impact note can remain proportional. A spelling correction on an isolated end card may need only a short record and export check. A new character design after pilot approval needs a wider review because it may alter the visual bible, existing shots, continuity decisions, and future production rules.
Choose one of four decisions
Every material request should end in a visible decision:
- Accept: the outcome and impact are understood, an owner approves the change, and affected work is authorized to proceed.
- Revise the request: the need is valid, but the proposed outcome, boundary, or acceptance test is not yet clear enough.
- Defer: the change is useful but belongs in a later batch, market version, release, or production stage.
- Reject: the request conflicts with the approved objective, source boundary, production method, delivery condition, or another controlling decision.
Record the reason. Rejection should not mean that a concern disappears; it should explain which approved requirement takes priority or which alternative will address the underlying issue.
When several requests compete, rank them by their relationship to the release objective: required correction, source or identity issue, audience comprehension, delivery requirement, creative refinement, or optional variation. The exact hierarchy should be agreed for the project rather than assumed universally.
Reopen only the approval that actually changed
A new request should not automatically send the entire project back to the beginning. Identify the earliest affected approval gate and the downstream work that depends on it.
If a caption contains an approved-wording error, the creative direction may remain closed. If the product message changes, the script, voice, graphics, captions, edit timing, and localized versions may need to reopen. If a character’s defining costume changes, visual references and every dependent shot may need review, while the story structure can remain approved.
Name the people who are deciding the reopened question. Separate objective, creative, risk, and delivery decisions so different reviewers do not turn every round into a general referendum on the project. Change control uses those same decision boundaries after an approval has been granted.
Test the change in context
Review the revised result where its effect can be judged. A corrected frame may look right in isolation but break continuity with the shots around it. A new voice line may be accurate but alter timing, music, captions, or the emotional shape of the scene. A vertical revision may not solve the same problem in landscape.
The closing evidence should match the request:
- A frame or shot comparison for a local visual correction
- A sequence review for performance, continuity, action, or edit changes
- A complete version review for copy, audio, caption, language, or format changes
- A refreshed representative pilot when a recurring production rule changes
- A delivery check when filenames, masters, or output specifications change
After acceptance, update the governing reference, approved version, and affected production records. Closing the comment without updating the source of truth allows the old requirement to return in later work.
Set change windows around production gates
Changes become harder to contain as dependent work expands. Define what may still change at each gate and what happens when a closed decision is reopened.
NovMotion’s six-phase production workflow moves through strategic intake, story architecture, visual definition, pilot production, review, and scale delivery. A practical change policy can follow those boundaries: explore objectives and formats early, settle recurring visual rules before scale, and reserve late review for corrections and delivery acceptance unless the team explicitly approves a wider impact.
This is not a rule that creative work must never evolve. It makes the consequence of evolution visible while the team still has choices. A late change may still be necessary; the decision owner should see what it reopens before authorizing it.
Limitations of a change-request workflow
A change log cannot make an unclear objective clear, guarantee that reviewers agree, or prove that every requested shot is technically suitable. It also cannot confirm that supplied material is authorized, guarantee platform acceptance, promise a particular legal result, or eliminate production uncertainty.
Long continuous performances, precise physical interactions, complex action, exact product behavior, crowds, small text, and repeated identity-sensitive scenes may require more than a simple revision. The appropriate response may be to simplify the staging, divide the sequence, replace a source asset, use compositing or controlled capture, change the production method, or narrow the deliverable.
Recognizable people, voices, trademarks, product assets, scripts, and other protected material should be handled with appropriate source and approval records. NovMotion’s AI rights and likeness principles describe the site’s production baseline. Project-specific scope, schedules, approval stages, deliverables, usage rights, confidentiality, and responsibilities are defined separately, as stated in the website terms.
Decision guidance for commissioning teams
Use a formal change-request workflow when the project has several reviewers, recurring characters or products, multiple episodes or campaign assets, localized or multi-format versions, or an approved pilot that is expanding into production.
Use a lighter comment-and-approval record for a small exploratory piece when one decision owner can see the entire dependency chain and no downstream version has begun. Even then, identify the reviewed version and the required outcome.
Pause affected work when the request replaces a governing source, introduces a new identity or usage question, conflicts with another approval, or has no authorized decision owner. Continuing production under two competing versions usually creates more uncertainty than waiting for one explicit choice.
Before accepting a material change, confirm six points: the reviewed version, change category, observable outcome, affected dependencies, approval owner, and closing evidence. If your team is preparing a pilot, series, campaign, or adaptation and needs a controlled review structure, contact NovMotion with the audience, source material, delivery plan, current approval stage, and the production decision that has changed.