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.
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.
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.
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.
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.
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.
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.
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 worldThe 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.
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.
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.
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.
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.
What I would carry into another AI product
- Name the human outcome before selecting a model topology. A change in success metric can invalidate an elegant architecture.
- Separate model, code, configuration, and evaluation responsibilities explicitly. “The AI handles it” is not a boundary.
- Keep the durable record append-only when history and causality matter. Derive convenient views rather than creating competing truths.
- Validate what code can actually know. Referential validity is enforceable; narrative quality requires evaluation and human judgment.
- Keep sequential model calls off the critical path unless each one earns its latency, cost, and failure surface.
- Design termination. Generative systems need structural conditions for completion, not a hope that the model senses the right moment.
- Treat memory as an experience and privacy design, not merely a larger context window.
- Test architecture with deterministic suites and test the product with people. Neither replaces the other.
- 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.
Follow the evidence.
- Building Shard, Part 1Building Shard, Part 1: The BetRahil Chamola
- Building Shard, Part 2Building Shard, Part 2: Brain and BodyRahil Chamola
- Building Shard, Part 4Building Shard, Part 4: What I KilledRahil Chamola
- Building Shard, Part 5Building Shard, Part 5: 10 LessonsRahil Chamola
- Shard project pageShardRahil Chamola
- Early v2 architectureArchitecture: Shard v2
- Canonical v2 game designGame Design: Shard v2
- Game-design reviewReview: Shard v2 game design
- Experience planShard v2 council experience plan
- Ledger implementationShard v2 ledger type contract
What survives when models become abundant?
- 01Try the question / InstrumentModel parity test
- 02Read the argument / EssayThe model is not the product
- 03Name the consequence / Garden noteDurable truth lives outside the model.
- 04Inspect the system / Case studyShard
- 05Follow the redesign / EssayFrom 54 Effects to 12 Events
How you arrivedThe case study exposes the current system and its evidence limits. The essay follows the redesign from the inherited machinery to the smaller deterministic kernel.