Implementing a Story World Constitution

What This Guide Is

This is the practical companion to the Collaborative Fiction Governance Framework. The framework describes the theory -- what governance components a shared fictional world needs and why. This guide walks a group through actually setting them up.

The audience is anyone who has read the framework (or is reading it alongside this guide) and wants to apply it to a specific project. The guide is organized around the tasks a group needs to complete, roughly in the order they should be done.

Throughout this guide, "the group" means whoever is participating in the collaborative fiction project -- two co-authors, a writer's room of twelve, a tabletop RPG group, or an open fan community of hundreds. The processes scale differently at different sizes, and the guide notes where size matters.

Step 1: Establish the Governance Document

Before making any governance decisions, create a place to record them. This is the governance document -- a companion to the project's creative reference document (bible, wiki, campaign notes). The creative reference records what's true in the world. The governance document records how things become true, how they change, and who decides.

The governance document doesn't need to be elaborate. At minimum, it records:

Which canonical levels the project uses and what each one means (the framework recommends five; the group might use fewer)
Who holds each governance role, or how the roles are distributed
What the change thresholds are at each canonical level
Any project-specific governance decisions (e.g., "divergent canon is encouraged," "all new species biology requires peer review before entering working canon")

For a small group (two to five people), this might be a single page at the front of the shared document. For a large community, it might be a standalone document with its own versioning. The format matters less than the existence -- having governance decisions written down somewhere accessible is what prevents "I thought we agreed..." disputes later.

When to create it: At the start of the project, ideally. But many groups won't think about governance until they've been working for a while and hit their first consistency problem or creative disagreement. That's fine. The framework can be adopted mid-project (see Step 3 for how to handle existing content).

Step 2: Set the Parametric Elements

The framework has structural elements (components every project needs) and parametric elements (settings each project configures for itself). Step 2 is configuring the parameters. The group should discuss and decide these together -- governance imposed by one person without discussion undermines the consent-based model that makes it work.

Choosing Your Canonical Levels

The framework recommends five levels: foundational, established, working, exploratory, and divergent. Not every project needs all five.

Three-level version (for small or early-stage projects): Settled, active, and outside. Settled is everything the group has committed to. Active is everything currently in play. Outside is anything that deliberately contradicts the shared world. This collapses foundational/established into one level and working/exploratory into another. It's simpler but loses the distinction between "hard to change because it's foundational" and "hard to change because other stuff depends on it," and between "in active use but not yet hardened" and "explicitly experimental." For a small group with good communication, those distinctions might not matter yet. They will start to matter as the project grows.

Five-level version (the framework's recommendation): Use all five levels as defined in the framework. This gives the group the full range of tools -- clear protection for foundations, a distinction between load-bearing and in-progress canon, a safe space for experimentation, and a designated zone for alternate takes. Most groups that have been working together for a while and have accumulated enough content to need governance will benefit from the full five.

Custom configurations: Some projects might add levels (e.g., separating "foundational physics" from "foundational tone" because they have different change implications) or rename them (using terminology that fits the project's culture). This is fine as long as each level carries a distinct behavioral expectation -- if two levels would produce the same contributor behavior, they should be merged.

Distributing the Governance Roles

The framework defines four roles: founder, steward, contributor, and arbiter. The group needs to decide how these map to actual people.

For a solo author or pair of co-authors: One or two people hold all roles. The governance document still has value -- it records decisions for your future self, who will have forgotten why something was settled. The steward role is the one to pay most attention to, because it's easy to let the reference document fall behind when you're the only one who needs it.

For a small group (three to eight people): Roles often map naturally to existing group dynamics. The person who started the project or proposed the world concept is often the natural founder. The person who enjoys maintaining the wiki or tracking details is the natural steward. Everyone is a contributor. The arbiter might be the founder by default, or the group might arbitrate by consensus. What matters is that the mapping is explicit -- stated in the governance document -- rather than assumed. Assumed roles produce "I thought you were handling that" failures.

For a large group or open community: Roles likely need to be formalized more explicitly. The founder role might be held by a founding committee whose membership is defined. The steward role might be a rotating position or a team. Arbitration might follow a defined process (vote, appeal, panel decision). The contributor role might have tiers -- established contributors whose work enters at working canon by default, and new contributors whose work enters at exploratory until reviewed. The governance document should specify these structures clearly enough that a new participant can read it and understand how the project works.

What each role actually involves in practice:

The founder makes relatively few decisions but they're the most consequential ones. In active periods, the founder might not need to do anything -- foundational canon is settled and everything is running on the other levels. The founder becomes active when someone proposes a foundational change, when a dispute escalates to a level where foundational principles need to be interpreted, or when the project's direction needs reaffirmation. The risk is either over-involvement (the founder treats every decision as foundational and micromanages) or under-involvement (the founder is absent when a genuinely foundational question arises).

The steward does the most continuous work. In a healthy project, the steward is regularly updating the reference document as new content enters working canon, tracking which working-canon content has hardened into established canon, checking new contributions for consistency, and periodically reviewing the accumulated canon for problems. This is unglamorous, ongoing labor. If the steward falls behind, the group doesn't notice immediately -- the effects are delayed, showing up weeks or months later as contradictions, disputes about what was decided, and a reference document that no longer reflects the actual state of the world. Groups should check in on the steward's workload regularly and redistribute if it's becoming unsustainable.

The contributor role is what most participants spend most of their time doing -- creating content. The governance-relevant responsibilities are: checking new contributions against higher-level canon before introducing them, marking contributions at the appropriate canonical level (especially distinguishing working from exploratory), and flagging potential inconsistencies when they notice them. Contributors who take these responsibilities seriously reduce the steward's workload significantly.

The arbiter is ideally idle. If the arbiter is making frequent decisions, that's a signal that the other governance components aren't working -- either the canonical levels are unclear, the change process isn't being followed, or contributors aren't checking consistency. When the arbiter does act, what matters is that decisions are recorded and their reasoning is explained, so that they serve as precedent for future similar situations.

Setting Change Thresholds

The framework requires that change thresholds increase with canonical level -- it should be harder to change foundational canon than working canon. The group needs to decide what "harder" means in practice.

For small groups, thresholds might be informal: working canon can be changed by the contributor who introduced it (with a heads-up to the group), established canon requires group discussion, foundational canon requires consensus. The informality works as long as the group has good communication norms and trusts each other's judgment.

For larger groups, thresholds should be more defined:

Working canon: changeable by the contributor who introduced it, or by any contributor with steward acknowledgment. No formal approval needed, but changes should be announced.
Established canon: requires a proposal, an impact assessment (what depends on this?), discussion among affected contributors, and approval by a defined threshold (majority, supermajority, consensus -- the group decides).
Foundational canon: requires a formal proposal, a full impact assessment, discussion among all active participants, a high approval threshold, and a transition period before the change takes effect.

The specific thresholds (majority vs. consensus, one-week vs. one-month discussion periods) are for the group to set based on their own decision-making culture. The framework's structural requirement is only that the thresholds increase with canonical level.

Step 3: Designate the Initial Canon

If the group is starting fresh (no existing content), this step is straightforward -- there's nothing to designate yet. The foundational canon is whatever the group establishes as the project's core commitments, and everything else will be designated as it's created.

If the group is adopting the framework mid-project (the more common case), all existing content needs to be sorted into canonical levels. This can feel overwhelming for a project with substantial accumulated worldbuilding, but it doesn't have to be done all at once.

The Triage Approach

Start with the most important content and work outward.

First pass -- identify the foundations. What commitments define this project? What, if changed, would make it a different project? These are usually small in number and already implicitly understood by the group, even if they've never been written down. The tone, the genre, the core premise, the physics, the structural principles that everyone has been following without stating them. Write these down as foundational canon. This pass should be fast -- if you're debating whether something is foundational, it probably isn't. Foundational canon should be obvious.

Second pass -- identify the load-bearing decisions. What has been established in creative work and built upon? Species biologies that multiple stories reference. Character relationships that have developed over time. Historical events that form the backdrop for current stories. Political structures that characters operate within. These are established canon -- decisions that have accumulated dependencies. This pass takes longer because it requires surveying the existing creative work, but it doesn't need to be exhaustive on the first round. Focus on the content that's most frequently referenced and most central to ongoing work.

Third pass -- everything else is working canon by default. Content that's been contributed but isn't yet load-bearing -- recent additions, details that haven't been built on yet, contributions that are in active use but haven't been stress-tested -- is working canon until it either hardens (accumulates dependencies) or gets revised. Don't overthink this pass. The goal is to distinguish "things we can change relatively easily" from "things that would cascade if changed," not to achieve perfect classification.

Exploratory and divergent content should be identified if it exists (proposals that were never resolved, alternate-take stories, experimental material that was never integrated), but this can wait until the first three passes are done.

Recording the Designations

However the group tracks its creative content -- bible document, wiki, shared folder, campaign notes -- the canonical level should be visible. Options include:

Status markers in the document itself (the bible in the companion project uses [SETTLED], [WORKING], and [OPEN] -- these map roughly to established, working, and exploratory)
A separate index that lists content and its canonical level
Tags or categories in a wiki system
A section of the governance document that lists foundational canon explicitly (since it's small enough to enumerate)

The method matters less than the accessibility. Any contributor should be able to determine the canonical level of any piece of content without having to ask someone.

Step 4: Operationalize the Change Process

The framework describes how content moves between canonical levels in the abstract. This step makes it concrete for the group's actual working process.

When New Content Is Created

The contributor creates something -- a story, a worldbuilding document, a session that establishes new facts about the world. Before or during contribution, they should:

Check consistency with foundational and established canon. This doesn't require reading the entire bible every time -- it means checking the specific areas their contribution touches. If the story involves Species B, check what's established about Species B. If it introduces a new technology, check whether it's consistent with the established physics.
Designate the level. Most new contributions enter at working canon by default -- they're part of the shared world and can be built on. If the contributor is unsure about something, they can designate it as exploratory ("I'm trying this out; feedback welcome before it becomes part of the world"). If the contribution deliberately contradicts canon, it's divergent and should be marked as such.
Announce the contribution to the group -- with enough information that other contributors and the steward can assess consistency without having to read the entire piece. "I wrote a story that establishes Species D has a mating season" is enough for someone to say "wait, does that fit with what we established about their lifecycle?"

When a Change Is Proposed

Someone wants to change existing canon -- revise an established species trait, modify a character relationship, alter a historical event. The process depends on the canonical level.

Changing working canon: Relatively low friction. The contributor who introduced it should be notified. If the change affects anyone else's in-progress work, those people should be consulted. The steward records the change. If nobody objects, it happens.

Changing established canon: Higher friction, because dependencies exist. The proposer states what they want to change and why. The steward (or the proposer, if there's no dedicated steward) identifies what depends on the existing decision -- which stories reference it, which other canon was built on it, which ongoing work assumes it. The group discusses, considering both the merits of the change and the cost of the cascade. If the group approves (at whatever threshold they've set), the steward manages the transition: updating the reference document, flagging affected content, and tracking any necessary revisions to dependent material.

Changing foundational canon: Highest friction, deliberately. This follows the formal process described in the framework -- proposal, impact assessment, full discussion, high-threshold approval, transition period. Foundational changes should be rare. If they're happening frequently, that's a signal that the foundational canon was set at the wrong level of specificity (too detailed, constraining things that should have been left to established or working canon).

When a Contradiction Surfaces

Someone notices that two pieces of content are inconsistent. The process:

Flag it. Anyone can flag a contradiction -- contributor, steward, or someone who noticed while reading. The flag should identify the specific pieces of content and the nature of the inconsistency.
Classify it. Is it a hard contradiction (both can't be true), a soft contradiction (tension but potentially reconcilable), an implication conflict (something implies a contradiction with higher-level canon), or a tone violation? The classification determines how urgently it needs resolution.
Check canonical levels. If the contradicting pieces are at different levels, the higher level generally takes precedence. If they're at the same level, the resolution requires discussion.
Resolve it. For working-canon contradictions, the contributors involved discuss and agree. For established-canon contradictions, the arbiter may need to be involved. The resolution should be recorded -- both what was decided and why -- so it becomes precedent.
Update the record. The steward updates the reference document to reflect the resolution, and checks whether the resolution has implications for other content.

Step 5: Maintain the System

Governance is not a one-time setup. It requires ongoing maintenance -- mostly from the steward, but with participation from everyone.

Regular Stewardship Tasks

Keep the reference document current. As new content enters working canon and working canon hardens into established canon, the reference document should reflect the changes. A reference document that's three months behind the actual state of the world is worse than no reference document, because contributors trust it and make decisions based on stale information.

Track dependencies. When new content builds on existing canon, note the dependency. This doesn't need to be a formal database -- even a simple annotation ("this story assumes the Species B joining biology from [established story]") is enough to make impact assessments possible when changes are proposed.

Watch for hardening. Working canon that's been built on repeatedly has effectively become established canon whether anyone designated it as such or not. The steward should periodically check whether working-canon content has accumulated enough dependencies to warrant reclassification.

Audit periodically. In a long-running project, set a cadence for reviewing the accumulated canon for inconsistencies that slipped through. Quarterly is reasonable for active projects. The audit doesn't need to be exhaustive -- focusing on recently added content and areas of active development catches most problems.

Signs the System Is Working

Contributors are creating new content confidently, without constant anxiety about contradicting something. The reference document is consulted regularly and trusted. Disagreements about canon are resolved through the defined process rather than through argument or avoidance. New contributors can read the governance document and the reference document and understand what's settled, what's open, and how to participate. The arbiter is rarely needed.

Signs the System Isn't Working

The reference document is out of date. This is the earliest and most reliable signal. If the steward has fallen behind, the governance system is degrading even if nobody notices yet.

Contributors don't know what's established. If people frequently disagree about whether something is settled canon or still in flux, the canonical designations aren't clear or aren't accessible.

Everything feels foundational. If the group treats every decision as hard to change, creativity is being suppressed. Most content should be at the working level, where it can be revised without heavy process. If the group has accidentally locked too much content at the established or foundational level, a recalibration is needed.

Nothing feels established. The opposite problem -- if the group treats all content as perpetually mutable, contributors can't rely on anything, and the shared world feels unstable. This usually means the hardening process isn't happening -- working canon that should have been recognized as established is still being treated as provisional.

The arbiter is constantly busy. Frequent arbitration means contradictions aren't being caught early (stewardship failure) or the group can't resolve disagreements through discussion (communication failure or unclear canonical levels). Address the upstream cause rather than relying on arbitration as a routine process.

The founder is making all the decisions. If the founder is active at every canonical level rather than primarily at the foundational level, the authority distribution has collapsed into concentrated authority regardless of what the governance document says. This may be appropriate for some projects, but if it wasn't the group's intention, it should be addressed.

The governance feels like overhead rather than support. If contributors experience the governance framework as a burden -- extra steps that slow down creative work without clear benefit -- either the framework is misconfigured for the project (too much process for the group's size, thresholds set too high, too many levels for the amount of content) or the group hasn't internalized why the process exists. The first problem is solved by adjusting the parametric elements. The second is harder and may require revisiting the framework's adoption -- governance that isn't understood can't be governance by consent.

Common Failure Modes

These are the patterns that cause collaborative fiction governance to break down in practice. Recognizing them early is easier than fixing them late.

The Absent Steward

The most common failure. Nobody is actively maintaining the reference document, tracking dependencies, or checking consistency. The group has governance on paper but not in practice. Content accumulates without designation. Contradictions build up unnoticed. When they finally surface, they're entangled with months of dependent content and much harder to resolve than they would have been if caught early.

Prevention: Make stewardship visible and valued. Check in on it regularly. If the steward is overwhelmed, redistribute the work or reduce the scope of what's being tracked. A partial stewardship practice (tracking only established and foundational canon, letting working canon manage itself) is better than no stewardship practice.

The Frozen World

The group becomes so protective of established canon that working canon can't harden because nobody wants to commit, and new contributions feel risky because they might contradict something. The canonical hierarchy collapses upward -- everything is treated as if it's at the foundational level, and the creative space shrinks to whatever can be safely contributed without touching anything.

Prevention: Keep foundational canon small and specific. Remind the group that working canon is supposed to be mutable -- that's the whole point of the level. Celebrate revision as a sign that the world is developing, not as a sign that someone made a mistake.

The Drift

The group starts well but gradually stops following the governance process. Contributions stop being checked. The reference document falls behind. Canonical levels blur. The governance document exists but nobody consults it. This is entropy -- the natural tendency of any process to degrade without maintenance.

Prevention: Periodic check-ins on the governance process itself (the meta-governance layer). A brief "is the governance still working?" conversation at regular intervals -- monthly for active projects, quarterly for slower ones -- catches drift before it becomes collapse.

The Veto Spiral

A contributor (often the founder, but not always) uses their governance authority to block contributions they personally dislike, framing aesthetic objections as consistency concerns. The governance process becomes a gatekeeping mechanism rather than a coherence mechanism. Other contributors lose trust in the process and either disengage or route around it.

Prevention: The framework distinguishes between consistency (is this compatible with established canon?) and quality (is this good?). Governance addresses consistency. Quality is a creative judgment that should be handled through the group's creative process, not through canonical gatekeeping. If someone is using consistency objections to disguise quality objections, the group should name what's happening and address it directly.

The Infinite Discussion

A proposed change triggers extended discussion that never resolves because the group lacks a defined endpoint. Nobody wants to be the one to call the vote or make the decision. The proposal stays open indefinitely, blocking creative work in the affected area and draining energy from the group.

Prevention: The change process should include defined timelines -- discussion periods with clear end dates, after which a decision is made by whatever threshold the group has set. The arbiter role exists precisely for cases that don't resolve through discussion. Using it isn't a failure of the group; it's the system working as designed.

The Canon War

Two contributors (or factions) have incompatible visions for the world and use the governance process to fight a proxy war -- each proposing changes that advance their vision and opposing changes that advance the other's. The governance process becomes a battleground rather than a collaboration tool.

Prevention: This is usually a foundational-level disagreement being fought at the established-canon level. If two contributors have fundamentally different visions for the project, the resolution is to address the foundational disagreement directly -- possibly by recognizing that the project needs a foundational revision, or by acknowledging that the two visions are incompatible and the contributors need to fork into separate projects (each of which can have its own governance). The divergent-canon level can also serve as a pressure valve -- contributors can explore their preferred vision in the divergent space without threatening the shared canon.

Scaling Notes

The need for governance doesn't scale on a single axis. Team size is one factor, but a solo author can need more governance than a small group if their project is complex enough. The framework's governance overhead should be calibrated to the actual complexity of the coordination problem, which has several independent dimensions.

What Drives Governance Complexity

Number of participants is the obvious one. More people means more divergent assumptions, more potential for contradiction, and more need for explicit process. But it's not the dominant factor in every case.

World scope and interconnection is often more important. A single story set in a single location with a small cast is simple to keep consistent regardless of how many people work on it. A world with multiple interconnected projects -- stories set in different eras, different locations, or different genres that share underlying physics, species, history, and political structures -- generates governance complexity even for a solo author. Each project is making decisions that constrain the others, and the shared layers need to be managed as shared canon even when there's only one person doing the sharing. The number of projects within a shared world matters as much as the number of people within a project.

Depth of the dependency chain amplifies the cost of changes. A world with shallow dependencies (most decisions are independent of each other) can tolerate informal governance because changes don't cascade far. A world with deep dependencies (species biology constrains culture, which constrains politics, which constrains institutional structures, which constrains the medical facility, which constrains the stories) means that a change at any layer potentially ripples through everything above it. Deeper dependencies demand more careful stewardship and more rigorous change processes, regardless of team size.

Volume of accumulated canon increases the stewardship burden over time. A new project with a few pages of foundational commitments needs minimal tracking. A project that's been running for years with dozens of stories, hundreds of established details, and complex webs of dependency needs active, systematic stewardship or it will lose coherence to entropy.

Rate of production affects how quickly governance problems compound. A project producing new content weekly generates contradictions and dependency-tracking needs faster than a project producing content quarterly. High-rate projects need governance that's lightweight per-contribution but rigorous in aggregate -- fast consistency checks at intake, regular audits to catch what slipped through.

Calibrating by Actual Complexity

Rather than prescribing governance intensity by team size alone, assess the project's governance needs across the factors above and calibrate accordingly.

Low complexity (solo or small team, single project, shallow dependencies, small canon, slow pace): Start with a reference document that marks what's settled vs. what's in flux. Designate someone as steward even if it's yourself. Use three canonical levels if five feels like overkill. Formalize further when the need becomes apparent. The value of reading the framework even at this stage is knowing what the components are so you can add them deliberately rather than inventing them in a crisis.

Medium complexity (any team size, but the world has multiple interconnected projects or deep dependencies or substantial accumulated canon): Use the full five canonical levels. Assign all four roles explicitly. Write the governance document. Invest in stewardship -- this is where the absent-steward failure mode is most dangerous, because the complexity is high enough that informal tracking breaks down but may not yet feel urgent enough to formalize. A solo author with two interconnected story worlds sharing foundational layers needs governance at this level even though there's only one participant, because the coordination problem is between projects, not between people.

High complexity (larger teams, or any team with extensive accumulated canon, deep dependencies, high production rate, and multiple interconnected projects): Formalize everything. The governance document should be thorough enough that a new participant can read it and understand how the project works without asking. Roles should be explicitly assigned with defined terms. Change processes should have defined timelines and thresholds. The steward role may need to be a team. Regular governance audits become essential rather than optional.

Open communities (any scale, but participation is unbounded): All of the above, plus: the governance document is the primary onboarding tool. It should be prominently visible, clearly written, and regularly maintained. The community should have a defined process for adopting the governance -- new members explicitly agree to it, or participation implies consent, but the choice should be stated. The divergent-canon level becomes especially important as a safety valve for creative diversity. And the meta-governance process should be genuinely democratic -- governance changes in an open community should reflect the community's will, not just the founders' preferences. The founders' legitimate authority is over foundational canon (the project's identity); governance process belongs to the community.

Multi-Project Worlds: The Tree Model

When multiple creative projects share an underlying world -- stories set in different eras, different genres built on the same foundations, companion projects that reference each other -- the governance structure needs to account for bidirectional flow between the shared world and the individual projects.

The right model is a biological tree, not a corporate hierarchy.

The root system is the shared universe canon -- physics, species biology, deep history, the foundational substrate that all projects depend on. This is what makes the projects part of the same world rather than unrelated stories. The root system has its own canon hierarchy: some of it is foundational (the laws of physics, the existence of the species), some is established (specific historical events, detailed species biology), and some is working or exploratory (aspects of the shared world that haven't been fully developed yet).

The trunk and branches represent the structural relationships between projects. The trunk is the shared history and setting that all projects draw from. Branches diverge where projects separate -- in time period, location, genre, or focus. The branch point determines how much canon is shared between any two projects. Two projects set in the same era at the same location share a long branch (lots of shared canon). Two projects set in different eras on different sides of the galaxy share only the trunk and roots (physics, species, deep history). The branching pattern is itself a piece of governance information that should be documented.

The leaves are the individual projects -- the medical drama, the bubble/contact stories, whatever comes next. This is where creative work actually happens, where new content is generated through storytelling. Each leaf has its own project-level canon hierarchy: its own foundational commitments (genre, tone, cast, format), its own established and working canon, its own exploratory and divergent space.

Flow runs in both directions. This is what makes the tree model essential rather than decorative.

Root to leaf (constraint): The shared universe canon feeds each project with the substrate it needs. Every project must be consistent with the root system. A project can't contradict the physics, the species biology, or the shared history without going through the universe-level change process. This flow is like water -- it's what keeps the projects alive as part of the same world.

Leaf to root (contribution): The projects do the creative photosynthesis. When a story establishes something about a species' biology, when a narrative event becomes part of the shared history, when a cultural detail gets invented through storytelling -- these products flow back down to enrich the root system, becoming available to all projects. This flow is like sugar -- it's what makes the root system grow. A shared universe with no active projects doesn't develop further. The creative work at the leaf level drives growth at every level of the tree.

The root system is co-constructed, not pre-built. The shared universe canon isn't finished before the projects begin. It starts as a set of foundational commitments and grows as the projects feed it. Much of the richest shared-world canon -- the detailed species biology, the specific historical events, the cultural texture -- gets generated at the project level first and then accepted into the shared root system. This means the universe-level stewardship role isn't just maintaining a static document. It's actively integrating contributions from the projects, checking them for cross-project consistency, and managing the growth of the root system over time.

Governance implications of the tree model:

The world needs a root-level governance document (a universe constitution) that covers the shared canon, its hierarchy, and the process for accepting contributions from projects. This is distinct from any project-level governance.

Each project needs its own project-level governance (or a section of the universe constitution dedicated to it) covering its project-specific canon and creative process.

The boundary between root and leaf needs to be explicitly defined: which content is shared (and therefore governed at the universe level) and which is project-specific (and therefore governed within the project). The boundary will be at different points for different projects depending on where they branch.

The contribution protocol -- how project-level creative work gets assessed and accepted into the root system -- is as important as the constraint protocol. It needs to answer: when a project establishes something that touches the shared layers, how is that flagged? How is it checked against other projects? How is it accepted or contested? What happens when two projects on different branches contribute conflicting content to the same part of the root system?

The branch-point inventory -- documenting where each project diverges from the shared trunk -- helps determine which projects need to coordinate on which content. Two projects that share a long branch need tight coordination. Two projects on distant branches may barely interact except through the root system.

This structure applies regardless of whether the projects have the same participants. A solo author's two interconnected projects need this just as much as two separate writing groups building in the same shared world.