Worldbuilding teams rarely lose canon because nobody cared. They lose it because a decision was made in a call, summarized differently in chat, copied into one character sheet, and never reconciled with the timeline, glossary, visual brief, or published text.

The counterintuitive fix is not “put everything in one giant lore bible.” A giant document can become another place where changes disappear. What a team needs is a handoff system: a small set of states, named owners, review rules, and version markers that tell everyone whether a statement is proposed, approved, superseded, or still disputed.

The minimum viable system is small: 3 canon states, 1 decision sentence, a 5-line handoff packet, and a 15-minute weekly audit. That is enough structure to catch most ownership and version drift without turning the creative team into administrators.

The tools can be simple. Git documents commits, branches, tags, and contribution workflows; GitHub documents review and approval patterns for pull requests. Those software practices should not be copied mechanically into a creative team, but they demonstrate a useful principle: changes become safer when the proposal, reviewer, discussion, accepted version, and release point are visible.

Separate proposal, approved canon, and deprecated canon

The most important rule is semantic, not technical.

Every lore statement should have one of at least three states:

Proposal — someone wants this to become true, but downstream work should not depend on it yet.

Approved canon — the designated authority has accepted it and the team may build against it.

Deprecated or superseded — it used to be accepted, but a later decision replaced it. It remains traceable because old drafts, art, or dialogue may still contain it.

Without these states, teams accidentally treat confident wording as authority. A designer writes “the city has two moons” in a concept note, an artist draws both moons, and suddenly the note becomes canon because several people relied on it.

State should travel with the fact.

Write the decision sentence before the explanation

Long discussion is useful for reasoning, but handoff needs a compact decision.

Use a one-sentence form:

Decision: In the current canon, [specific fact], effective from [story/version point], replacing [old rule if any].

Then add rationale, alternatives rejected, and open questions below it.

This structure solves two problems. First, someone can quote the accepted fact without accidentally quoting a rejected idea. Second, future reviewers can distinguish “what we decided” from “why we decided it.”

If you cannot write the decision in one sentence, the team may still be negotiating more than one issue.

Assign authority by category, not by whoever replies first

A creator-heavy project often has several legitimate authorities. The lead writer may own plot causality, the art director owns visual continuity, a game designer owns playable rules, and a legal or licensing lead may control what can be promised to a partner.

Put those domains in a small authority matrix.

Decision type Primary owner Required reviewer Optional consultation
Plot causality Narrative lead continuity editor character writer
Character visual identity art director narrative lead marketing/licensing
World rule / power system world lead narrative + gameplay if relevant science/culture adviser
Commercial usage licensing lead legal/brand owner creative leads
Localization-sensitive naming localization lead canon owner market adviser

The purpose is not hierarchy for its own sake. It prevents approval from drifting to the most available person.

Review the dependency list before approving a change

A lore change is cheap until another asset depends on it.

Before approval, list what the change touches:

  • existing chapters or scripts;
  • character biographies;
  • maps and timelines;
  • concept art or 3D assets;
  • item descriptions;
  • game rules;
  • marketing copy;
  • translations;
  • partner materials.

A small change to a character's age can alter a timeline. A renamed faction can break search, links, localization, and licensed copy. A new power limitation can invalidate fight choreography.

The review question is therefore not only “Is this idea better?” It is “What existing promises does this idea make false?”

Treat review as a conversation that must eventually close

GitHub's review workflow distinguishes comments, requested changes, and approvals. A creative team can use the same conceptual separation without pretending a story is software.

A reviewer should do one of four things:

  1. approve;
  2. approve with clearly non-blocking notes;
  3. request a specific change;
  4. state that they do not have authority or enough context.

Avoid endless “looks interesting” comments that keep a decision socially alive but operationally unresolved.

When a requested change is addressed, close the thread with the accepted wording. Otherwise six weeks later someone will read the old objection and assume the issue is still open.

Use release tags for canon milestones

Git tags are designed to mark specific points in project history. For a creative project, a comparable release marker can be useful:

  • CANON-2026-10-WEB
  • NOVEL-BOOK03-FINAL
  • GAME-DEMO-V1
  • LICENSING-BIBLE-2026Q4

The exact naming system matters less than the promise: a tag identifies a known bundle of approved decisions.

This is especially helpful when different outputs move at different speeds. The novel may already use a new rule while a licensing deck still represents the prior approved release. Instead of saying “use the latest files,” say which canon release the recipient is supposed to use.

Do not version by filename alone

final_v7_reallyfinal.docx is not a version-control strategy.

Even teams that do not use Git should keep:

  • a stable document identifier;
  • a current status;
  • a last-approved date;
  • an owner;
  • a change log;
  • links to superseded versions.

If the team does use Git or another repository, use commits for meaningful changes and release tags for milestones. Do not rely on folder timestamps as the only history.

The important creative habit is that a changed fact leaves a trace.

Make every handoff fit into five lines

A receiving teammate should not need a meeting to discover what changed.

Use this packet:

  1. What changed: one sentence.
  2. Canon status: proposal / approved / superseded.
  3. Effective version: which release or work now uses it.
  4. Dependencies: files or teams that must update.
  5. Owner and next checkpoint: who decides the unresolved part, if any.

Attach supporting material after those five lines.

This is deliberately small. A handoff succeeds when the next person can act correctly before reading the entire backstory.

Handle exceptions without quietly rewriting the rule

Stories often need exceptions. The danger is an exception that silently becomes a second rule.

Document exceptions with four fields:

  • base rule;
  • exception;
  • why it applies here;
  • whether the exception can recur.

For example: “Teleportation normally requires a keyed gate. Character X can cross once without a gate because artifact Y is consumed. This does not create a reusable ability.”

That wording protects future scenes from treating a one-off dramatic event as a permanent system upgrade.

Separate source licensing from canon approval

A team can approve an idea creatively and still lack the right to reuse a source asset.

Creative Commons provides multiple license types with different conditions concerning attribution, commercial use, derivatives, and sharing terms. That means “we found it online” and “we approved it for the world” are completely different checks.

For external images, text, maps, fonts, music, or research assets, record:

  • source URL;
  • creator or institution;
  • license or permission status;
  • required attribution;
  • whether adaptation and commercial use are allowed;
  • whether the asset is reference-only rather than distributable.

Canon review cannot substitute for rights review.

Run a 15-minute handoff audit each week

Once a week, sample five recent decisions and ask:

  • Can a new teammate identify the current approved statement?
  • Is the owner obvious?
  • Is there a release/version marker?
  • Are superseded words still presented as current somewhere important?
  • Do dependent teams know the change exists?
  • Are open review comments genuinely open?

If two or more samples fail, the problem is not that the team needs a bigger wiki. The handoff mechanism is breaking.

Fix the path by which decisions become authoritative.

Do not centralize everything

A canon system should centralize authority and traceability, not every working note.

Writers still need scratch files. Artists need exploratory boards. Researchers need source notes. Producers need schedules. Forcing all of those into one canonical document makes the canonical layer noisy and discourages experimentation.

Keep working material flexible; promote only decisions that downstream work needs.

A lightweight structure might be:

  • /proposals/ — active decisions under review;
  • /canon/ — currently approved rules;
  • /deprecated/ — superseded decisions with replacement links;
  • /releases/ — snapshots or release manifests;
  • /sources/ — rights and research records.

The folders are optional. The states are not.

Disagreement is safest before approval, not after publication

A healthy canon workflow makes disagreement cheap early. People should be able to challenge a proposal, point out a dependency, or ask for evidence without feeling that they are “blocking the project.”

Once a decision is approved and released, the cost of reversal grows. Published chapters, art, localization, code, merchandise, and partner decks can all depend on it.

That is why the workflow should be strict at the boundary between proposal and approved, but lightweight everywhere else.

The result is not a frozen world. It is a world that can change deliberately without making yesterday's collaborators unknowingly wrong.

Sources

Related Reading