Shard
A story system built around truths the model cannot rewrite.
Shard sits between a scripted visual novel and an unbounded chatbot. It uses language models for the moment-to-moment scene, then gives identity, history, time, chance, and endings to deterministic systems that can be inspected.
Structure without scripting. Freedom without chaos.
The original wager was to preserve durable consequence without pre-authoring every branch.
Freedom is bounded by what someone wrote in advance.
The world has little reason to remember why it mattered.
V1 answered this tension by giving models specialized jobs and surrounding their output with typed governance. That was already a serious system. It was also still organized around repairing model output after too much truth had entered the model's jurisdiction.
The first v2 plan changed the cast, not the assumption.
A real redesign began only when the product promise and the source of truth changed together.
Four decisions changed the centre of gravity.
- 01
Design the system before touching the AI
WhyThe game needed explicit types, world rules, and consequence handling before generation could be useful.
What changedV1 split generation into model roles and surrounded their output with typed governance.
- 02
A finite episode, but inherited machinery
WhyThe early redesign changed the experience frame while retaining three model roles, validators, effects, and contracts.
What changedIt became evidence that a redesign can preserve the assumption that made the first system difficult.
Sources - 03
Optimize for a finite emotional story
WhyThe desired outcome became a story that moves the player and leaves memorable characters, not a simulation that can continue forever.
What changedPacing, memory, privacy, and closure became architectural constraints.
Sources - 04
Move durable truth into an append-only ledger
WhyHistory and causality need one inspectable source rather than several mutable interpretations.
What changedRelationships, knowledge, promises, and inventory can be derived as views over accepted events.
World file, ledger, clock, plan.
Four durable objects now carry the truths that narration is allowed to interpret but not overwrite.
The v2 critical path
The model receives a constrained scene context. Deterministic code accepts valid events into one ledger, then derives the views the next scene needs.
Player intent enters deterministic scene code with the world file and finite plan. The scene model returns prose and proposed events. Code validates references, applies accepted events to the append-only ledger, and derives relationship, knowledge, promise, and inventory views. A separate asynchronous tick can read and extend wider world history.
Twelve kinds the ledger can keep.
These are current schema kinds, not a score. Each accepted event becomes part of the history from which later views are derived.
- 01scene
- 02move
- 03dialogue
- 04fact
- 05feeling
- 06item
- 07bond
- 08promise
- 09clock
- 10arrival
- 11departure
- 12consequence
Several counts, several definitions
The sources count different scopes. They show changing vocabulary and architectural boundaries, not a measured percentage improvement.
- Public March claim54+
Effect types named by the historical public project page.
Sources - March type union73
Unique effect spellings in the reviewed union, including aliases and deprecated kinds.
- V2 retrospective28
The later design document's retrospective description of the v1 effect bus.
Sources - V2 ledger12
Canonical event kinds in the current ledger contract.
Sources
Decide what the model is allowed to be wrong about.
Code, configuration, models, and evaluation own different questions and different failure modes.
Who owns which truth
| Owner | Owns | Does not decide |
|---|---|---|
| Code |
| It cannot decide whether a scene is moving or beautifully written. |
| Configuration |
| It provides a possibility space, not the final moment-to-moment story. |
| Model |
| It does not own durable truth, dice, identity, or reference validity. |
| Evaluation |
| A fluent model or passing typecheck cannot certify the human outcome. |
The operating ruleThe model imagines. The code keeps the books. The product decides what matters.
A cleaner kernel is not evidence of a better game.
The architecture is inspectable. The emotional experience still needs durable evidence from real players.
What the evidence can support
- Documented
- Interpretation
- Unresolved
- 01Documented
Shard was designed as a third option between authored branching and unconstrained chat.
The March public series states this product wager directly and describes the TypeScript-first architecture built to support it.
- 02Documented
V2 implements twelve canonical ledger event kinds.
The current type contract defines scene, move, dialogue, fact, feeling, item, bond, promise, clock, arrival, departure, and consequence.
- 03Interpretation
The deeper change is from model-role architecture to truth-boundary architecture.
V1 specialized model jobs and repaired their output. V2 first asks which facts are deterministic, then gives the model a narrower creative seam.
- 04Unresolved
The design pressures every story toward an ending, but a universal guarantee is not established.
The code includes plans and ending gates. The reviewed implementation can still depend on a model reporting that an ending occurred.
- 05Unresolved
Real-player validation is still an open evidence gate.
The repository contains synthetic testing infrastructure, but the reviewed artifacts do not establish that the planned real-player gate occurred.
Lessons worth carrying into another AI product.
- 01
Name the human outcome before selecting a model topology.
- 02
Separate model, code, configuration, and evaluation responsibilities.
- 03
Keep one append-only record when history and causality matter.
- 04
Validate what code can know and evaluate what people must feel.
- 05
Keep sequential model calls off the critical path unless each one earns its cost and latency.
- 06
Design completion conditions for generative systems.
Source ledger
- 01Original public thesis
Building Shard, Part 1: The Bet
Chamomo ·
States the third-option thesis, TypeScript-first design, and the claim that the LLM is the runtime rather than the product.
- 02Original public architecture
Building Shard, Part 2: Brain and Body
Chamomo ·
Documents model roles, the effect bus, coherence layers, and typed governance in the March system.
- 03Historical project page
Shard
Chamomo ·
Provides the public historical claim of 54-plus effect types.
- 04March implementation snapshot
V1 effect type union
Shard source snapshot ·
Exposes 73 unique spellings when aliases and deprecated kinds are included.
- 05Superseded redesign
Architecture: Shard v2
Shard v2 design record ·
Retains a three-model pipeline and much of the inherited governance machinery.
- 06Current product contract
Game Design: Shard v2
Shard v2 design record ·
Defines the finite emotional-story promise, four-part kernel, twelve-kind ledger, derived views, and ending gates. It retrospectively calls v1 a 28-effect bus.
- 07Game-design review
Review: Shard v2 game design
Shard v2 review record ·
Finds the architectural spine sound while identifying unresolved reward, bond, pacing, item, and failure-state questions.
- 08Experience evidence plan
Shard v2 council experience plan
Shard v2 planning record ·
Records an N=1 tuning baseline and calls for a real-player gate before further feature expansion.
- 09Current ledger contract
Shard v2 ledger types
Shard v2 implementation snapshot ·
Implements twelve stable event kinds and typed, append-only history at the reviewed head.
- 10Current scene path
Shard v2 scene engine
Shard v2 implementation snapshot ·
Implements the primary scene-model seam, deterministic checks, accepted events, retry behavior, and ending pressure.
Notes growing from this project.
- BuddingAI architectureDurable truth lives outside the model.
Shard's v2 world file, append-only ledger, clock, and finite plan are the clearest worked example of narration interpreting durable truth without owning it.
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
Why continueThe case study exposes the current system and its evidence limits. The essay follows the redesign from the inherited machinery to the smaller deterministic kernel.