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.
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:
- defining the “Why”;
- identifying all affected pages;
- updating the core material;
- propagating dependent edits in waves;
- 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: