The counterintuitive rule of collaborative worldbuilding is this: do not try to make everyone "own the lore." Shared ownership sounds healthy, but when every writer, artist and editor can silently redefine a faction, the result is not collaboration. It is parallel canon.
A small faction package can stay coherent with only four hard controls:
- one canonical faction brief;
- one named decision owner for each category;
- one visible review state before canon changes;
- one version trail that tells the next person what changed and why.
For a team of two, this may be a folder and a checklist. For a team of twenty, it may be Git, GitHub, a document system and formal approvals. The tool is secondary. The handoff contract is the real system.
Start with numbers: four states, three owners, two clocks
Before discussing personalities or software, define the workflow in terms anyone can audit.
Use four content states:
- Draft — exploratory; not safe to cite as canon.
- Review — proposed change with evidence and downstream impact noted.
- Approved — canon for the current version.
- Deprecated — retained for history but no longer current.
Use three ownership roles:
- Author: proposes the change.
- Domain owner: checks the faction's logic, continuity and source boundaries.
- Release owner: decides when approved material becomes the version other teams should use.
One person can hold two roles on a small team, but the roles should still be named.
Use two clocks:
- review clock: how long an approval normally waits before escalation;
- release clock: when approved changes are bundled into a stable handoff.
This prevents the common failure where concept art uses Monday's lore, dialogue uses Wednesday's rewrite, and the website publishes Friday's interpretation.
The faction brief should be smaller than the faction
A canonical brief is not an encyclopedia. It is the minimum stable interface other teams need.
For each faction or institution, keep one page with:
Identity. Name, public role, internal purpose, and one sentence describing what it believes it is protecting.
Authority. Who can make binding decisions? How is leadership selected, replaced or challenged?
Resources. What does the institution control: money, land, information, ritual legitimacy, armed force, technology, medicine, transport, education?
Constraints. What can it not do without losing legitimacy, triggering a rival, breaking a treaty or exhausting a scarce resource?
Internal conflict. Which two goals cannot both be maximized?
External dependencies. Which other faction, class, market, ecosystem or institution keeps it functioning?
Canon locks. Facts downstream teams must not casually rewrite: founder, jurisdiction, succession rule, taboo, signature technology, treaty, timeline anchor.
Everything else can live in expandable notes.
The brief works like an API contract. Artists should not need to read forty pages to know whether a uniform can display a forbidden emblem. A quest designer should not need to search old chats to know who can legally issue an arrest order.
Handoffs fail when they transfer files but not decisions
A good handoff contains three things:
- the current artifact;
- the decision context;
- the unresolved questions.
Suppose a writer changes a merchant guild from hereditary leadership to elected leadership. Sending the new paragraph is not enough. The handoff should also say why the change happened and what it affects: family dynasties, insignia, election scenes, corruption mechanics, old character biographies, and any dialogue that calls the leader "heir."
Use a handoff note with five fields:
- Change:
- Reason:
- Affected canon:
- Teams/assets to recheck:
- Open question:
That is more valuable than a long meeting because it survives the meeting.
Approval should follow risk, not hierarchy
Not every comma needs a lore director. Not every faction rewrite should be merged by the newest contributor.
Create three approval levels.
Level 1: presentation
Spelling, formatting, wording that does not alter meaning, image crop, navigation labels. One reviewer is enough.
Level 2: interpretation
A costume symbol, local custom, minor rank, explanatory paragraph, scene detail that narrows an ambiguous point. Domain owner review is usually enough.
Level 3: canon architecture
Leadership system, founding event, religion-state relationship, territory, succession, major technology, inter-faction treaty, timeline anchor. Require explicit approval from the release owner and review of downstream impact.
This is the same principle used in software review systems: higher-impact changes get stronger gates. GitHub's protected-branch documentation, for example, supports required reviews and can require code-owner approval before protected branches are merged. CODEOWNERS can automatically request relevant reviewers for owned paths. Those mechanisms are designed for code repositories, but the collaboration principle transfers cleanly to structured lore: define ownership and make approval visible.
Do not imitate software ceremony for its own sake. A two-person writing team does not need enterprise branch protection. It still benefits from knowing which changes are "typo," "interpretation" and "canon architecture."
Version control is valuable even when nobody writes code
Version control solves a storytelling problem: what changed between the version an artist saw and the version the editor is using now?
Git's branching model allows work to develop on separate branches and later merge into a stable line. GitHub pull requests add review, discussion and approval around changes. For a team comfortable with those tools, storing Markdown lore files in Git can make the history unusually clear.
A workable structure might be:
/factions/wolf-court.md/factions/phoenix-command.md/institutions/arbitration-chamber.md/timeline/era-07.md/glossary/terms.md
A change to the Wolf Court succession rule then appears as a readable diff rather than a new file called wolf-court-final-final-v7-really-final.docx.
But Git is not mandatory. A document platform with version history can work if the team preserves the same concepts: canonical location, named reviewers, visible approval state and durable change notes.
The wrong tool is the one the team stops using.
Build a dependency map before a big faction change
Factions rarely live on one page. A single canon edit can affect:
- character motivations;
- ranks and costumes;
- maps and borders;
- laws and punishments;
- economy and trade;
- religious rites;
- military doctrine;
- UI labels;
- collectible cards;
- game quests;
- website copy;
- licensing references.
Before approving a Level 3 change, ask: where else is this fact encoded?
A simple dependency table can be enough:
| Canon fact | Depends on it | Owner | Recheck |
|---|---|---|---|
| Phoenix Command reports to civilian council | Lena bio, rank chart, city law page | Lore | Required |
| Wolf Court succession is musical trial | Xiao Ling arc, ritual scene, card text | Story | Required |
| Arbitration Chamber is neutral territory | map, faction diplomacy, brand guide | World/Brand | Required |
The table prevents a "small" lore decision from leaving contradictory copies everywhere.
Separate source evidence from invented canon
This matters especially when a fictional institution borrows from real cultures, religions, legal systems or historical states.
Keep two fields apart:
Source note: what a real source actually says, where it comes from, and what context it belongs to.
Creative transformation: what the fictional faction changes, combines or invents.
Do not paste a real minority practice into a villain faction because it looks exotic. Do not turn a living religion's office into a generic "mystic bureaucracy" without understanding context. And do not cite a source as if it endorses your fictional interpretation.
For purely fictional factions, this discipline still helps: it tells later collaborators which details are research anchors and which are deliberate invention.
The approval meeting should produce a change record, not just agreement
A meeting can feel productive while producing no stable result.
End every canon review with:
- approved version identifier;
- exact changed facts;
- rejected alternatives that should not quietly return next week;
- downstream assets to update;
- owner and due state for each follow-up;
- date the new version becomes the handoff baseline.
If no one writes that down, the meeting is only a memory.
When branches help — and when they create chaos
Use separate working branches or copies when:
- two people are exploring mutually exclusive faction structures;
- a large rewrite should not disturb the current release;
- a game adaptation needs temporary changes before canon approval.
Avoid long-lived branches for every department if they drift for months. Git's branching workflows can support long-running branches, but creative teams still need frequent integration. Otherwise every merge becomes a negotiation between different fictional universes.
A useful rule is: experiment freely, reconcile early.
A compact collaboration template
For every proposed canon change, record:
Faction / institution:
Current canon version:
Proposed change:
Why now:
Approval level: 1 / 2 / 3
Evidence or research note:
Affected characters:
Affected locations:
Affected timeline entries:
Affected visual assets:
Affected product/game/web copy:
Reviewer:
Decision: Draft / Review / Approved / Rejected / Deprecated
Effective version:
Open questions:
The template is intentionally boring. Boring systems are good at protecting imaginative work from administrative confusion.
The real goal: let specialists move fast without splitting the world
A lore writer should be able to deepen a faction. An artist should be able to design it. A game designer should be able to turn it into mechanics. A licensing team should be able to describe it to a partner.
They do not need to work in the same file at the same time. They do need to know which facts are current, who can approve a change, and what changed since their last handoff.
That is the core of faction collaboration: one canon, many contributors, visible decisions.
Sources
- GitHub Docs — Requesting a pull request review. https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/requesting-a-pull-request-review
- GitHub Docs — About protected branches. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
- GitHub Docs — About code owners. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
- Pro Git — Branching Workflows. https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows