HISTORICAL DIG · JUL—AUG 2026
What must stay fixed between character frames?
Public production workspaces separate characters, scenes, props, storyboards, and asset libraries, while an openly licensed character model sheet makes one design inspectable across angles. They show that character references can be managed, but provide no three-frame continuity rate for any model.
HOW IT RELATES TO WORKFLOW 001
Relation to the current subject
It follows the static-story gate by turning “the same character” into an inspectable contract.
A retellable story does not mean character assets are ready for generation. This historical record takes continuity out of prompts and intuition: fix identity, wardrobe, palette, scene, and rights fields first, then ask someone outside production to explain how each one passes or fails.
Record state at the time
- AI motion comics
- Character and style assets
- Standard record
- Developing
- Historical E1 · pinned maker material, an open-license model sheet, and a platform-action republication · no BitShovel three-frame run
THE GUIDANCE AT THE TIME
Judgment at the time
Lock Version 1 first; only a contract another person can reject may enter a three-frame trial.
Open full rationale and return rules
Do not begin with a vague likeness goal. Build a Version 1 contract for one character: identity traits, silhouette, wardrobe, palette, scene anchor, allowed and forbidden changes, plus each source's provenance, rights basis, and file hash. Someone outside production must first be able to review every field. Only then may the same Version 1 enter a front, close, and action three-frame trial. Accept or reject each trait in every frame. One must-not-change drift rejects the frame; allow at most one recorded local retry, then narrow the motion, use panel animation, or composite manually.
- Who it was for
- People who have passed the static-story gate, own or clearly license their character and scene material, and need to define identity, allowed variation, and rejection rules before generation
- Why it mattered then
Open note
Without a version contract, face, wardrobe, palette, prop, and scene can all change in one retry. Without provenance and rights records, even stable-looking images cannot safely proceed into production and release checks.
- Where the judgment stops
Open note
This is an unrun, unfrozen historical trial. The fictional courier and three frames manually reuse one vector set to explain the contract; they are not generated images or continuity results. David Revoy's Pepper model sheet shows only how a human-designed character can be fixed across angles; LocalMiniDrama shows only that a pinned version exposes asset and storyboard management; and the Hongguo republication records a platform notice and submitter-evidence gaps—not a court judgment, general rights conclusion, or BitShovel legal advice.
CHECK BEFORE READING ON
Fit check
This trial applies only after the story gate, with clear source rights and a willingness to stop random retries.
This record may help
- The story, character, and scene have clear provenance, and the work can stop at one character, one scene, and three frames.
- You will let another person reject frames field by field and stop random generation after one recorded retry.
Do not use it yet when
- The provenance or rights basis of any character, likeness, brand, game element, wardrobe, scene, or reference image is unknown.
- The first pass must cover many characters, costume changes, group scenes, full-episode generation, or real release.
- You need BitShovel to prove that a model, reference mode, or workspace has solved character continuity.
HISTORICAL TRIAL · UNRUN, UNFROZEN CHARACTER CONTRACT
Historical trial
Spend 45 minutes on one character Version 1—no generation, batching, or release.
- Time needed
- Forty-five minutes to build Version 1 and have one person review it; generation wait is separate, and this round remains unrun
- Likely cost
- Do not buy batch credits. If the contract passes, set one total ceiling for one first run per frame and one recorded local retry
- Permission boundary
- Record source, rights basis, permitted changes, owner, and file hash for every reference; stop on any unknown and keep platform accounts read-only
- 01
First step
Open this step
Build Version 1 for one character only: identity, silhouette, wardrobe, palette, scene anchor, allowed and forbidden changes, with provenance and rights records. Ask one person outside production to explain every accept or reject rule. Only if the contract passes may front, close, and action frames become the next small trial.
- 02
What should exist
Open this step
A versioned character contract with provenance, a blank three-frame review sheet, rejection rules for every must-not-change trait, and a limited-motion or manual-composite fallback. It is not a generated result.
- 03
How to tell it worked
Open this step
Someone outside production can use the contract alone to explain how every trait would pass or fail across three frames and can open every source record. This means only that the contract is ready for a small trial—not that the character is consistent, releasable, or platform-approved.
- 04
Stop when
Open this step
Stop if identity or scene anchors cannot be made observable, any provenance or right is unknown, the reviewer cannot explain the rejection rules consistently, or time, spend, and retries remain uncapped.
- 05
How to back out
Open this step
Keep the passed contract version, provenance, and review notes; remove unknown material, narrow action and framing, switch to panel animation, local replacement, or manual compositing, and do not enter batch generation or release.
BITSHOVEL R3 EXPLAINER · FIXED FICTIONAL DATA
Method and interfaces
Freeze five fields first; accept or reject every frame against the contract.
Open method boundary
The fictional courier and three frames manually reuse one vector set to explain versioning, rights, acceptance, and rejection. They are not generated results, model performance, a user pack, or a continuity score.
The fictional courier, five fields, and three-frame states explain versioning, acceptance, and rejection only. The frames manually reuse one vector set; they are not model output or a continuity score.
About this image and its source
BitShovel explainer created August 16, 2026. It contains no real person, title, model, platform account, generation, spend, viewer, release, or rights-review result.
Open source page ↗SOURCES AND EVIDENCE
Sources and evidence
As of August 16, 2026, pinned maker material, an open-license human model sheet, and a platform-action republication support building the contract—not a claim that a model holds identity.
Open evidence boundary
Historical E1 remains the old page label. Revision 3 rechecks one pinned maker document, an openly licensed human-made model sheet, and a platform-action republication attributed to the official account. BitShovel did not generate a character, compare models, record retry cost, reproduce three-frame continuity, or obtain an independent-creator result.
- 01Pinned maker documentation · Rechecked now
LocalMiniDrama separates characters, scenes, props, asset libraries, and storyboards into managed objects
Open source boundary
The pinned commit supports only the workflow fact that assets and storyboards can be managed separately. BitShovel did not install or reproduce the maker's generation, continuity, local, or privacy claims, and the source gives no three-frame success rate.
Open original source ↗ - 02Open-license human-made character reference · Rechecked now
David Revoy's Pepper model sheet makes one character inspectable across multiple angles
Open source boundary
The pinned Wikimedia Commons record identifies the author and CC BY 4.0. It is a human character-design reference—not an AI motion comic, BitShovel three-frame run, model result, user pack, or platform outcome. Revision 3 links the source without redistributing the old derivative.
Open original source ↗ - 03Platform-notice republication · Rechecked now
Beijing Daily republishes a Hongguo official-account notice on character and likeness material removed after evidence gaps
Open source boundary
The republication records platform actions involving cartoon characters, brands and marks, game characters, and actor likenesses. It supports keeping presentable rights records before submission, not a substitute for contracts, original platform rules, case-specific legal analysis, or a court judgment.
Open original source ↗
REVISION RECORD
Revision record
Revision 3 delays three-frame generation until the contract passes and gives failure a stop rule.
Open 3 revisions
- Revision 1
Turned character continuity from a prompt into a versioned asset pack with rejection rules and rights records.
- Revision 2
Removed a storyboard-parameter interface that did not represent a character pack, replaced it with an openly licensed human-made model sheet, and stated that it was not an AI continuity test.
- Revision 3
Reframed character locking as a human-reviewable Version 1 contract before any three-frame generation trial; removed the old derivative image and added field-level rejection, one retry, and a limited-motion fallback.
- What the record said before
- Lock one character, one scene, and three key frames; stop random retries if any required trait cannot be recognized across them.
- What changed
- Do not generate the three frames yet. Put identity, silhouette, wardrobe, palette, scene anchor, allowed and forbidden changes, provenance, and rights into a Version 1 contract. Only after another person can explain every accept and reject rule may a three-frame trial begin; one drift rejects the frame, with at most one recorded retry.
WHAT THIS RECORD LEAVES
What this record leaves
Character continuity is not “close enough”; every frame must be rejectable by the same contract.
When identity, wardrobe, palette, scene anchor, and source rights can be checked field by field, the record yields a reversible decision to try three frames. It is still not a generation or release outcome.
Back to the Dig index