case

How We Turned the Why into a Reproducible Canon Contract for InterDead

Case study on turning the canon Why into an operational SSOT contract for InterDead.

Date: 2026-02-20

Authors: Sam Starling

Categories: cases

Tags: interdead, case-study, canon, ssot, narrative-design

On the great and terrible Why in game design.

Context

InterDead operates at the intersection of narrative architecture and mechanical implementation, where the number of entities, protocols, and localizations continually grows. In such an environment, every element interacts with many others, creating a cumulative complexity effect.

Problem

Early on, this created typical risks for a complex narrative system. Local decisions emerged without shared causality, meanings were duplicated, terminology was interpreted differently by different contributors, and internal contradictions multiplied as the canon expanded. Multilingual support further complicated consistency. In short, the project was scaling faster than the discipline required to maintain it.

Hypothesis

We proposed that if the canon is moved into a public wiki and each entity receives an explicit “Why,” the entire structure becomes more manageable. Canon updates could be introduced in waves, causality would become verifiable, team synchronization would accelerate, and localizations would become derivative rather than autonomous versions.

Solution

The goal was to turn the “Why” from a philosophical notion into an operational tool. It became a canon contract.

Every entity is now required to have:

  • a defined purpose;
  • documented causal links;
  • a clear scope of applicability;
  • describable consequences.

The wiki serves both as a formalization environment and as a system of constraints that enforces discipline.

Effect Metrics

This is not a quantitative case; its impact is architectural. The approach brought predictability during scaling, reduced internal contradictions, minimized semantic divergence between localizations, and accelerated decision-making. Most importantly, it provided full control over causality.

Additional side effects included faster editorial processes and improved audience engagement — the latter addressed separately in the case “How We Offset Development Costs.”

Limitations

The approach is not universal. It raises the entry threshold, requires terminological discipline, and slows spontaneous iteration. For projects based on rapid prototyping without a long-term canon, this level of structure may be excessive.

Self-Discipline as the Core Factor

The model works only if every decision is required to answer “Why,” the canon is fixed before scaling, and the public nature of the wiki acts as pressure toward formulation precision. Creativity becomes structured rather than constrained.

Model Architecture

SSOT: Single Source of Truth

There is one primary version of the canon — in our case, English. All other localizations are derivative, which eliminates disputes over which version is “correct.”

Change-list Process

Any change to the canon follows a clear sequence:

  1. defining the “Why”;
  2. identifying all affected pages;
  3. updating the core material;
  4. propagating dependent edits in waves;
  5. verifying localizations.

This prevents chaotic edits.

Three Publication Modes

We distinguish between manual publication, semi-automated builds, and full API synchronization via Action API + CI.

Manual publication is flexible but error-prone. Semi-automated builds reduce copy-paste. Full API synchronization offers high synchronicity and scalability. API automation includes separation of localizations, a unified format, a CI pipeline, diff logic, and token/rate-limit management. Automation, however, does not eliminate editorial responsibility during semantic changes.

Next Stage

The next layer of complexity is cultural canon adaptation — preserving the “Why” while shifting cultural context. This will be covered in a separate case.

Conclusion

By making the internal system public during development, we turned the “Why” into a contract, an editorial filter, an architectural stabilizer, and a synchronization mechanism — not an abstraction but an actionable part of production.

Operational Implementation

The full operational model is documented here:

InterDead reproducible canon pipeline

Back to blog