A dragon can survive a rewrite. It often cannot survive five people making “small improvements” without a shared record of what is source evidence, what is interpretation, and what is original canon.
Team collaboration fails when everyone receives the same noun—“dragon”—but carries a different mental model. One writer imagines an imperial symbol, an artist remembers a museum jade, a game designer wants a flying boss, and marketing wants a generic fire-breather because it reads instantly in a thumbnail. The conflict is not solved by adding a larger mood board. It is solved by making the handoff explicit.
This workflow is for writers, artists, game teams, editors, and licensing partners who need to share a dragon concept without flattening cultural distinctions or silently changing the creature between versions.
Start the handoff with a source card, not a character sheet
A character sheet tells collaborators what the current design looks like. A source card explains why some choices exist and which choices are safe to change.
For each real-world source, record:
- institution and object/page title;
- culture, period, medium, and date as the source describes them;
- what is directly visible or stated;
- what you infer;
- what you are deliberately inventing;
- what the source does not prove.
For example, The Metropolitan Museum of Art has Chinese dragon objects from different periods and media, including jade, textiles, and porcelain. A British Museum hanging scroll depicts a dragon in a Japanese Edo-period context while also discussing inherited Chinese associations with clouds and water. These are not interchangeable “dragon facts.” They are evidence from specific objects and contexts.
That distinction matters during collaboration. If one teammate says, “Dragons are always associated with X,” the source card gives the team a place to challenge the word always.
Separate four layers before anyone edits the design
Every handoff should label four layers.
Evidence: what a named source directly supports.
Interpretation: the team’s reading of why that evidence matters.
Transformation: the deliberate fictional change.
Canon: the rule that the project has now decided to keep.
A simple example:
- Evidence: a specific Qing-period object uses an imperial dragon motif.
- Interpretation: court association can communicate authority to viewers familiar with that context.
- Transformation: this fictional dynasty adopts a related visual grammar but changes the number, material, and ritual meaning.
- Canon: only the throne fleet may display the five-part storm emblem.
Now an artist can redesign armor plates without accidentally changing the political rule. A writer can change a ritual scene without claiming the fictional emblem is a direct historical copy.
The four-layer model also protects research integrity. Fiction is allowed to transform. The problem is not invention; the problem is forgetting where invention began.
Create a “locked / flexible / unknown” map
Not every field deserves the same approval burden.
Mark the design in three categories:
Locked: identity-critical rules. Changing them would create a different creature, faction, or story function.
Flexible: implementation choices. They can vary between scenes, products, or media while respecting the rule.
Unknown: unresolved questions. They are not permission for random invention; they are visible gaps waiting for a decision.
A dragon handoff might look like this:
| Field | State | Example |
|---|---|---|
| relationship to water | Locked | power requires atmospheric moisture |
| exact horn silhouette | Flexible | may change by age and art style |
| hatchling social behavior | Unknown | no canon decision yet |
| political emblem use | Locked | restricted to one institution |
| scale texture | Flexible | realistic, stylized, or mechanical depending on medium |
This map prevents two opposite problems: teams freezing harmless visual details, and teams improvising identity-critical rules.
Use a decision log for every change that crosses media
When a novel, website, game, trailer, and merchandise line share the same dragon, small changes propagate.
A decision log should answer six questions:
- What changed?
- Why?
- Who approved it?
- Which sources or existing canon were checked?
- Which downstream assets are affected?
- Is the change retroactive?
Do not bury the answer in chat. Chat is good for discussion and terrible as the only canonical record.
Version-control concepts are useful here even for non-code teams. A tagged release can mark “Dragon Bible v1.2 approved for trailer production.” The team then knows exactly which state a vendor received. If v1.3 changes the wing mechanism, no one has to guess whether the old poster is wrong or simply belongs to the previous approved release.
Design approvals around risk, not hierarchy
Requiring the project lead to approve every claw shape will slow the team and encourage people to stop asking. Approving nothing will create canon drift.
Instead, define approval thresholds.
A low-risk change affects presentation only: camera angle, lighting, pose, crop, or a material variation already allowed by canon.
A medium-risk change affects an implementation rule: the dragon’s apparent size, a weapon attachment, a color range, or behavior not yet shown on screen.
A high-risk change affects identity, cultural framing, faction meaning, power limits, origin, life cycle, or relationships to named characters and events.
The approval path should become stricter as risk rises. This makes collaboration faster because most routine work remains routine while identity changes receive deliberate review.
Make visual teams return questions, not fill gaps
A dangerous handoff sentence is: “Use your judgment.”
Creative judgment is essential, but unmarked gaps encourage accidental canon.
Give artists and vendors a question protocol:
- If the brief is silent on a visible feature, mark it
OPEN. - Offer up to three visual options.
- State whether each option is source-inspired, existing-canon-derived, or wholly invented.
- Do not silently merge motifs from unrelated cultures because they “look Asian.”
- Return identity-critical questions before final rendering.
This is especially important for dragons because the word covers a huge range of cultural images. A Chinese court textile, a Japanese ink painting, a modern fantasy wyvern, and a European heraldic dragon do not become one neutral design language just because an international audience recognizes all of them as “dragons.”
Run a cross-media contradiction check
Before approval, compare at least these surfaces:
- prose description;
- concept art;
- model sheet or game model;
- ability list;
- faction or character biography;
- website copy;
- product description;
- marketing key art.
Look specifically for contradictions that are easy to miss:
Scale: novel says the dragon fits a courtyard; key art makes it city-sized.
Movement: game animation implies powered flight; canon says it rides storm currents and cannot fly in dry air.
Color: merchandise introduces a faction color reserved for another group.
Symbol: an artist adds an imperial motif because it looks prestigious, but the story treats that motif as legally restricted.
Behavior: promotional copy calls the creature “feral” while the novel establishes language and political agency.
A contradiction check should end with decisions, not comments. Every issue becomes fix asset, change canon, allow variation, or needs author decision.
Give external partners a minimum viable canon pack
A licensing or outsourcing partner does not need the entire internal archive. They need the smallest package that prevents expensive mistakes.
A useful external pack contains:
- one-page identity summary;
- approved visual references;
- locked/flexible/unknown map;
- prohibited combinations;
- color and emblem rules;
- scale references;
- current approved release number;
- pronunciation/naming notes where relevant;
- three examples of “looks acceptable but is wrong”;
- contact and approval path.
The “wrong examples” are often more useful than another page of adjectives. If a dragon must never be rendered as a generic horned fire-breather, show what that mistake looks like and explain which rule it violates.
Do not send unsorted research folders to external partners and expect them to infer the project’s interpretation. Research is evidence; the canon pack is a decision product.
Preserve disagreement instead of erasing it
When two teams disagree, do not overwrite the losing proposal as if it never existed. Record the alternatives and the reason for the decision.
That history prevents the same argument from returning six months later and helps future collaborators understand constraints that are not obvious from the final image.
A lightweight record can say:
Option B rejected because its horn and cloud motif combined references from unrelated source contexts and weakened the faction-specific silhouette. Revisit only if the faction concept changes.
This is not bureaucracy. It is compressed memory.
The handoff is successful when a new teammate can make one safe decision alone
The final test is practical. Give the pack to someone who did not attend the original meetings and ask them to make one small design decision.
Can they identify what is locked? Can they find the source trail? Can they tell the difference between evidence and invention? Can they recognize when they need approval? Can they produce a variation without changing identity?
If yes, the collaboration system is working.
If every new teammate still needs a private explanation from the original creator, the team does not have a handoff process. It has a person-shaped bottleneck.
Sources
- The Metropolitan Museum of Art — Dragon, jade, China. https://www.metmuseum.org/art/collection/search/43084
- The Metropolitan Museum of Art — Panel with dragon, China. https://www.metmuseum.org/art/collection/search/50497
- The Metropolitan Museum of Art — Vase with Dragon amid Clouds. https://www.metmuseum.org/art/collection/search/42364
- British Museum — Dragon in clouds, hanging scroll. https://www.britishmuseum.org/collection/object/A_1934-0714-0-1
- Git Book — Tagging. https://git-scm.com/book/en/v2/Git-Basics-Tagging.html