Build a character bible that catches continuity errors.

Editorial analysis

Document decisions, not adjectives

The operator profile begins with three people looking at the same character and seeing different rules. A writer reads “playful” as teasing; an animator reads it as elastic movement; a community operator reads it as permission to improvise. Replace adjectives with observable decisions: what the character knows, what they refuse, how they address mistakes, which gestures recur, and which visual changes require approval.

Split the bible into identity, performance and continuity. Identity covers fixed facts and intentional unknowns. Performance covers voice, pacing, expressions and movement limits. Continuity records dated events the audience has seen. This makes a contradiction traceable instead of turning every disagreement into a taste debate.

Source record

Map the bible to editable controls

Epic's current MetaHuman documentation separates a source Character from assembled output and lists shared and character-specific assets. It also describes an experimental Collection and Instance system in Unreal Engine 5.8 that keeps a non-destructive link to the source character. The useful production lesson is narrower than a product recommendation: name the editable source and the downstream assembly separately.

Live2D's manual gives parameters IDs, ranges and descriptions. It says consistent IDs help reuse motion across models and that descriptions help multiple creators assign parameters consistently. A character bible should therefore point to actual control names—such as the approved smile or head-angle range—rather than rely only on reference images.

Evidence: Epic Games / MetaHuman Documentation [s1] · Live2D Cubism Editor Manual [s2]

Practical application

Create a one-page continuity card

Start with a card a producer can use during review: five fixed identity facts; five speech rules; five visual anchors; three prohibited claims; the current story date; and links to the approved voice, model and wardrobe sources. Add an owner and last-reviewed date to every rule. If the team cannot fit the decision layer on one page, the long bible is not yet indexed well enough.

Worked example: a hypothetical character never claims to have eaten food, calls the operator “the studio,” wears one silver ear cuff on the left, and apologizes without blaming software. A draft that says “my favorite ramen,” mirrors the cuff, or says “the AI made me do it” fails before rendering.

Practical application

Run a contradiction pass before production

For each script, mark every claim about biography, time, relationships, body, product experience and memory. Compare those marks with the card and the dated continuity log. Then review the neutral front view, profile, three-quarter view, smile, concern and speaking mouth against approved controls. Record the first frame where a mismatch appears and return it to the responsible discipline.

Once a month, give a second operator one old post, one new script and the package. Ask them to identify deliberate changes and accidental drift without oral guidance. Every miss becomes a clearer rule, a better reference, or an explicitly unresolved question—not another paragraph of lore.

Editorial analysis

Version changes as editorial events

A new rig, voice model or renderer may improve output while changing the public character. Keep the old source, the proposed source, a fixed comparison scene and the approval note together. Name the change in audience terms: narrower smile, faster response rhythm, different vocal age signal. Software version numbers belong in the production record, not as substitutes for that explanation.

The acceptance test is simple: another operator can locate the governing rule, reproduce the approved baseline and explain every intended difference. That is continuity as an operating system, not a promise that no frame will ever vary.