View full image ↗Describe actions, not adjectives
“Expressive” is a mood, not an acceptance test. Replace it with a short movement list: both eyes blink separately; the mouth closes at rest and opens across ordinary speech; the head can turn left and right without exposing unpainted gaps; the hood, glasses and tail each have an agreed response. Add the performance context. A shoulder-up chatting model and a full-body dance avatar need different parts, ranges and failure checks.
For a 2D model, label the artwork that must move independently and mark concealed areas that need painting. Live2D’s PSD guidance says the lowest layer in a group becomes a texture on import and that line and fill layers at that level need to be combined first. That is a concrete production constraint, not a universal naming recipe. Ask the artist and rigger to agree on their own layer convention, then include a small annotated example in the brief.
Make a model-parts and movement matrix
Use four columns: visible element, required motion, driver and edge case. “Front hair / side-to-side sway / head angle plus physics / must not cross the near eye” is more actionable than “nice hair physics.” For a 3D handoff, the same matrix can cover eye gaze, mouth shapes, spring bones, first-person visibility and any removable accessory. Mark whether each behavior comes from face tracking, a hotkey, an animation or physics so two systems are not silently fighting for the same control.
Keep optional polish separate from the minimum pass. If a tongue toggle, jacket swap or secondary outfit is optional, give it its own line and approval state. This protects the core model from an endless cloud of “while you’re there” requests without turning the guide into contract advice.
List editable sources and runtime exports separately
Live2D documents a real distinction between the editable .cmo3 model and runtime output: .moc3 data, a .model3.json settings file, textures and optional physics files. A handoff that contains only what the performance app loads may be usable on stage but difficult to revise. Conversely, an editable file without its linked artwork, textures or export settings may not recreate the delivered result.
Write two inventories. The source package lists layered art, editable model or scene files, texture sources, fonts or other dependencies that are actually included, and the tool/version used. The delivery package lists the exact folder to import, model format and version, expressions, motions, thumbnails and a plain-text readme. Do not assume that purchase transfers every editable source or every permission; record what the creator has expressly agreed to provide.
Approve with a tiny movement reel
Ask for a short neutral-to-extreme check rather than a glamorous reveal clip: neutral face, blink, wink if included, quiet and loud mouth movement, three head angles, each expression toggle, then any body or accessory motion. Note clipping, sticking controls and abrupt transitions by timestamp. This is an editorially proposed review exercise, not a claim that one checklist fits every rig.
Finish the handoff note with model name, version, delivered date, credited creators, intended apps and known limits. One sentence such as “the side braid clips through the raised collar at maximum right turn” is not an embarrassment; it is durable production knowledge. The goal is a package another authorized collaborator can understand without reconstructing the commission from chat history.
Sources & limits
Live2D documentation establishes PSD import behavior and the distinction between editable and runtime files. The movement matrix, approval reel and package inventories are original editorial tools, not legal terms or reported tests.
- Import PSDs
first-party · Publication date not stated · Updated 24 February 2026 · Retrieved 19 September 2026 - File Types and Extensions
first-party · Publication date not stated · Updated 4 February 2025 · Retrieved 19 September 2026
Send a correction with the passage and supporting source.
