--- schema_version: 1 type: "essay" id: "essay-from-54-effects-to-12-events" slug: "from-54-effects-to-12-events" title: "From 54 Effects to 12 Events" summary: "Rebuilding Shard changed the architecture from a growing stack of AI-governance systems into a smaller deterministic kernel built around a world file, ledger, clock, and finite plan." dek: "V1 surrounded language models with systems. V2 asked which state should never belong to a model in the first place." status: "published" visibility: "public" indexing: "index" categories: - "ai" - "building" - "product" tags: - "Shard" - "AI architecture" - "narrative systems" - "event sourcing" - "evaluation" created: "2026-07-23" updated: "2026-07-23" published: "2026-07-23" canonical_path: "/writing/from-54-effects-to-12-events" canonical_url: "https://rahilchamola.com/writing/from-54-effects-to-12-events" preferred_citation: "Chamola, Rahil. “From 54 Effects to 12 Events.” Curated Randomness, 2026." reading_minutes: 16 authors: - id: "rahil-chamola" name: "Rahil Chamola" role: "author" series: id: "making-curated-randomness" title: "Making Curated Randomness" part: 2 related_slugs: - "the-model-is-not-the-product" - "10-things-ai-has-taught-me" citations: - id: "shard-the-bet" label: "Building Shard, Part 1" title: "Building Shard, Part 1: The Bet" author: "Rahil Chamola" publisher: "Chamomo" published: "2026-03-10" note: "States the original third-option thesis, TypeScript-first design, and the claim that the LLM is the runtime rather than the product." - id: "shard-architecture" label: "Building Shard, Part 2" title: "Building Shard, Part 2: Brain and Body" author: "Rahil Chamola" publisher: "Chamomo" published: "2026-03-10" note: "Documents the original Game Master and Narrator split, effect bus, coherence layers, and pure-function governance." - id: "shard-decisions" label: "Building Shard, Part 4" title: "Building Shard, Part 4: What I Killed" author: "Rahil Chamola" publisher: "Chamomo" published: "2026-03-10" note: "Records removed features and the reliability standard used during the v1 build." - id: "shard-lessons" label: "Building Shard, Part 5" title: "Building Shard, Part 5: 10 Lessons" author: "Rahil Chamola" publisher: "Chamomo" published: "2026-03-10" note: "Records the original doctrines of generation versus governance, model-to-task matching, strict types, testing, and emergence." - id: "shard-project-page" label: "Shard project page" title: "Shard" author: "Rahil Chamola" publisher: "Chamomo" published: "2026-03-10" note: "Provides the public historical count of 54-plus effect types and describes the original product and architecture." - id: "shard-v2-may-architecture" label: "Early v2 architecture" title: "Architecture: Shard v2" publisher: "Shard v2 repository" published: "2026-05-16" note: "A superseded planning document that still retained a three-model pipeline, validators, contracts, and broader launch ambitions." - id: "shard-v2-gdd" label: "Canonical v2 game design" title: "Game Design: Shard v2" publisher: "Shard v2 repository" published: "2026-06-09" note: "The canonical build contract for the world file, twelve-kind ledger, clock, finite plan, derived views, determinism boundary, and ending gates." - id: "shard-v2-review" label: "Game-design review" title: "Review: Shard v2 game design" publisher: "Shard v2 repository" published: "2026-06-10" note: "Finds the architectural spine sound while identifying weaknesses in reward grammar, bonds, growth, items, pacing, and failure states." - id: "shard-v2-council-plan" label: "Experience plan" title: "Shard v2 council experience plan" publisher: "Shard v2 repository" published: "2026-06-11" note: "Records the evidence baseline, N=1 tuning limitation, real-player test gate, latency and cache concerns, and feature-sprawl guardrails." - id: "shard-v2-ledger-code" label: "Ledger implementation" title: "Shard v2 ledger type contract" publisher: "Shard v2 source repository" published: "2026-06-20" note: "Implements twelve stable event kinds, typed details, append-only events, and referentially constrained proposals at the reviewed repository head." evolution_note: "This essay compares the five public March 2026 articles with the superseded May v2 architecture, canonical June v2 GDD, current implementation, Git history, review documents, and stored test evidence. Claims about a change in product or architecture are source-backed. Claims about how Rahil's thinking evolved are explicitly marked as interpretation. Real-player validation remains unresolved in the reviewed evidence." --- # From 54 Effects to 12 Events _V1 surrounded language models with systems. V2 asked which state should never belong to a model in the first place._ > **Evolution note.** This essay compares the five public March 2026 articles with the superseded May v2 architecture, canonical June v2 GDD, current implementation, Git history, review documents, and stored test evidence. Claims about a change in product or architecture are source-backed. Claims about how Rahil's thinking evolved are explicitly marked as interpretation. Real-player validation remains unresolved in the reviewed evidence. In March, I published a five-part series about an AI narrative game called Shard. The central line was already the right one: design the system before touching the AI. The LLM is the runtime, not the product. The uncomfortable part is that I had not followed that principle as far as I thought. V1 had types, validators, pure functions, model roles, effect buses, directors, relationship axes, quest state, identity state, and coherence layers. It was designed rather than merely prompted. It was also still organized around making model output safe after the model had been trusted with too much of the world. > **The v2 correction** · insight > > The model imagines. The code keeps the books. V2 is smaller not because the story is less ambitious, but because fewer truths are allowed to depend on generation. > **How to read this account** · note > > “Documented” means the public articles, design documents, code, or Git history say it directly. “My interpretation” means the evidence supports a pattern but does not record my internal reasoning in those words. “Unresolved” means the repository does not contain enough evidence to make the stronger claim. **01 / THE ORIGINAL BET** ## Structure without scripting. Freedom without chaos. The original product bet sat between two bad poles. A visual novel can preserve consequence because every branch is authored, but its freedom is bounded by what was written. A chatbot can respond to almost anything, but the world often has no durable state and no reason for one exchange to matter to the next. Shard tried to hold structure and improvisation at the same time. The first architecture began in TypeScript. Thirty-three interfaces described relationships, effects, worlds, quests, identity, and other game structures before the first model call. One model acted as Game Master and decided what happened. Another acted as Narrator and decided how it read. An effect bus translated proposals into game changes. Pure functions validated and applied those changes. Five coherence layers and eight directors tried to keep the generated experience consistent and shaped. This was a meaningful improvement over one model trying to be novelist, game designer, state store, and referee at once. “Generation proposes; code governs” remains one of the strongest lessons from v1. Strict types caught failures that fluent output concealed. Real play exposed problems that solo use avoided. Features that were only 90 percent reliable were treated as broken rather than impressive. The public project page described 54-plus effect types. A sword swing and a confession flowed through one extensible pipeline. At the time, that looked like architectural leverage: add a new mechanic by adding an effect rather than inventing a new subsystem. **02 / THE LIMIT** ## The repair stack became the architecture The same extensibility also created places for responsibility to accumulate. A generated action could require parsing, validation, semantic correction, effect application, relationship updates, quest reconciliation, memory handling, and narration. Every new system made the world richer. Every boundary between them created another opportunity for the model's interpretation and the code's truth to disagree. The Git history after the March articles matters here. V1 did not freeze at the architecture I had just explained. It added another model role, later changed the model pipeline again, compressed prompts, fixed timeouts, repaired world generation, reworked playability, and replaced the choice system. That history does not prove the original architecture was wrong. It does prove the published article was a snapshot rather than the settled system it could sound like. > **My interpretation** · question > > V1 decomposed the problem by assigning more specialized jobs to models and surrounding them with governance. V2 decomposes it by asking which facts are deterministic. This is a shift from model-role architecture to truth-boundary architecture. **03 / THE FALSE START** ## The first v2 plan was still v1 wearing cleaner clothes The earliest v2 architecture did not immediately discover the smaller kernel. The May plan still proposed three model roles: a simulator, Game Master, and Narrator, plus validators, effects, constitutions, NPC contracts, and audio. It changed the product framing to a finite prestige-television episode, but much of the inherited machinery remained. That intermediate document is useful precisely because it was superseded. A redesign can change names, screens, and model assignments while preserving the assumptions that made the original system difficult. V2 became a real redesign only when the product promise and the source of truth changed together. **04 / PRODUCT** ## The outcome changed before the kernel did The June design document explicitly stops calling Shard an AI storytelling engine or platform. The new promise is a beautiful escape: a story that moves the player and leaves them with characters they want to remember. The primary question is no longer whether the simulation can continue coherently. It is whether the person was moved. That outcome removes some technically interesting work and makes other work non-negotiable. A story has to end. Characters need histories the player can trust. The world should continue when it is not looking at the player, but knowledge cannot teleport between characters. Choices need resistance and consequence. Time, probability, identity, and ending conditions cannot drift because the prose sounded persuasive. Once the outcome became a finite emotional story, the architecture had to protect pacing, memory, and closure, even at the cost of some emergence. **05 / THE KERNEL** ## World file, ledger, clock, plan V2 reduces the durable machine to four primary objects. The world file defines what can exist. The ledger records what happened. The clock establishes when it happened and who could be present. The plan gives the story a shape and a finite route to an ending. Relationships, promises, inventory, knowledge, and other familiar game concepts can be derived as views over that history instead of competing stores of truth. *The v2 critical path, simplified* ```text player intent → code resolves deterministic checks and current context → one scene model imagines prose and proposed events → code validates references and applies accepted events → append-only ledger records history → views derive relationships, knowledge, promises, and inventory → an asynchronous tick advances the wider world ``` The synchronous scene path uses one model call rather than a procession of model personas. A cheaper asynchronous tick can advance the wider world separately. This is not a universal claim that one model is better than several. It is a latency and responsibility decision: every sequential call on the player's path adds time, cost, failure modes, and another opportunity for state to diverge. The ledger defines twelve stable kinds: scene, move, dialogue, fact, feeling, item, bond, promise, clock, arrival, departure, and consequence. The model may propose an event and its meaning. Code checks whether referenced characters, places, and objects exist before accepting it. V2 deliberately avoids a semantic validator that asks another model whether the event was wise. Referential truth is narrow enough to enforce. Narrative quality remains something to evaluate, not a boolean the system can pretend to prove. **06 / DETERMINISM** ## Decide what the model is allowed to be wrong about A useful AI architecture does not begin with “What can the model do?” It begins with “Which errors can the product survive?” Shard can survive a line of dialogue that is less elegant than the previous one. It cannot survive a dead character arriving without explanation, a private fact becoming public knowledge, a failed check being narrated as success, or a story that never reaches its ending. - Code owns identifiers, reference validity, dice, time, ordering, plan gates, and ending eligibility. - Configuration owns the world, authored canon, fixed points, difficulty and resistance dials, and permitted variation. - The model owns interpretation, scene construction, dialogue, texture, and proposed meaning inside the current constraints. - Evaluation owns whether those choices create a moving experience. Neither types nor another fluent model can certify that alone. This boundary is more durable than routing every role to one favourite provider. Models can improve or be replaced behind the scene seam. The invariants remain understandable because they live in code and data rather than in a prompt's implied memory. **07 / ENDINGS** ## Emergence needed a destination One of the original lessons was “emergent beats prescribed.” V2 does not completely reverse it, but it narrows the claim. Unbounded emergence can produce variety without shape. A satisfying story needs pressure, progression, irreversible turns, and an ending that feels caused rather than stopped. The plan now selects one of six story shapes and moves toward one of three ending modes. Code-enforced gates prevent the final act from opening before structural requirements are met and prevent the episode from extending indefinitely once an ending is due. Later implementation added fixed points, episode-gated canon, fidelity controls, codices, and author-editable beats. The improvisation remains real, but it happens around a spine. > **My interpretation** · question > > The principle evolved from “emergent beats prescribed” to “prescribe the constraints that make emergence meaningful.” Authorship becomes scaffolding rather than a dialogue tree. **08 / MEMORY** ## History became a product surface V1 stored a relationship as six changing axes. V2 treats the shared history as canonical and relationship labels as views. That sounds like a data-model change. It is also a product change. A number says affection increased. A history can show the promise, betrayal, gift, rescue, or silence that made the relationship what it is. The later v2 work turns that history outward through keepsakes, a phone, an inner cast, codices, seasons, and character persistence. These should not be understood only as more features. They are attempts to make the retention mechanism match the emotional promise: the player returns because a character and a shared past still matter. There is an ethical constraint inside the same design. Characters know what they witnessed or were told; the model does not get to use the player's full ledger as universal character knowledge. Good memory design is partly about remembering the right thing and partly about refusing to leak it into the wrong mind. **09 / WHAT IS NOT PROVEN** ## A cleaner kernel is not evidence of a better game The June review found the architectural spine promising and the reward grammar underdeveloped. Bonds could be optimized rather than felt. Growth could be exploited. Items lacked texture. Cliffhangers, clocks, failure motion, and ending visibility still needed design work. Deterministic state prevents certain categories of contradiction; it does not manufacture desire, surprise, pacing, or attachment. The council plan also records an N=1 tuning baseline and calls for three to five real players before larger feature work. The repository contains synthetic persona testing, but the evidence reviewed for this essay does not establish that the real-player gate occurred. One stored synthetic browser result fails before meaningful play. Synthetic coverage is useful for repeatability; it is not a substitute for watching a person become confused, bored, moved, or unwilling to return. The design document says v2 structurally cannot fail to end. The code contains explicit plans and gates, which supports the mechanism. I have not found acceptance evidence strong enough to turn that design claim into a universal result. The same document sets a 600-line file ceiling, while current scene and view modules exceed it. The doctrine is ahead of parts of the implementation. Cost and latency are real but time-bound. The June numbers are a development snapshot. What carries forward is the need to budget latency, cache behavior, degradation, and cost as part of the experience. **10 / TRANSFER** ## What I would carry into another AI product 1. Name the human outcome before selecting a model topology. A change in success metric can invalidate an elegant architecture. 2. Separate model, code, configuration, and evaluation responsibilities explicitly. “The AI handles it” is not a boundary. 3. Keep the durable record append-only when history and causality matter. Derive convenient views rather than creating competing truths. 4. Validate what code can actually know. Referential validity is enforceable; narrative quality requires evaluation and human judgment. 5. Keep sequential model calls off the critical path unless each one earns its latency, cost, and failure surface. 6. Design termination. Generative systems need structural conditions for completion, not a hope that the model senses the right moment. 7. Treat memory as an experience and privacy design, not merely a larger context window. 8. Test architecture with deterministic suites and test the product with people. Neither replaces the other. 9. Audit whether a redesign changed the governing assumption or only renamed its components. The original Shard thesis was right about one thing: the model was never supposed to be the product. V1 still made the model the center of too many systems because so much architecture existed to interpret, constrain, repair, and reconcile what it produced. V2 moves the center of gravity. The world file says what can exist. The ledger says what happened. The clock says when. The plan says where the story is going. The model gets to do the work it is uniquely good at: imagine the moment between those truths. > The model imagines. The code keeps the books. The product decides what matters. --- Creator: Rahil Chamola Canonical source: https://rahilchamola.com/writing/from-54-effects-to-12-events Preferred citation: Chamola, Rahil. “From 54 Effects to 12 Events.” Curated Randomness, 2026.