Skip to content
KN-86 Deckline

Persistent record store: durable world records across missions

Design state: Josh made every decision below in the 2026-08-22 design session; this note records them. v1.3 | 2026-08-29 Owner: Gameplay Design (the model); Runtime / C Engineer (the store) Related:

A single durable store

Section titled “A single durable store”

One table holds the records. A “system” (a company HR host, a housing registry, a tax mirror) is a tag on a record; the engine simulates no separate per-system databases. A record is one row attached to a world-entity node, tagged with the system that holds it. The screener’s cross-system comparison is a filter-and-compare over the one table. A pre-check is a single tag-filtered lookup. A pre-check’s suspicion flag lands on the legend object, never on the operator (Josh, 2026-08-22): legend flags sit outside the engine’s operator visibility state, and the canon three-state vocabulary is unchanged (../cartridges/modules/cloneshop.md).

Persistence follows observation

Section titled “Persistence follows observation”

The store persists two things:

  1. Records the operator planted. The record of the operator’s interference.
  2. References to records the operator saw. Captured as DOSSIER facts holding entity references; the content is re-derivable from the record’s provenance.

Nothing else persists. The world is definite only where someone has looked; a region no operator has touched regenerates identical from its generation inputs.

Provenance, per record

Section titled “Provenance, per record”

There is no single world seed to persist. The generator mission/board-gen.lsp draws each contract instance its own narrative_seed through the gen-draw-seed seam, which parks the raw 32-bit value on the mission_board.c side at mint and hands it to the World Engine as the seed on accept, and mission_world.c resets the prior mission region at the mission-instance boundary before generating the next seed-and-archetype pair. A bare seed therefore cannot re-derive a row once the region that produced it has been replaced.

Every persisted record and every seen-record reference stores its originating provenance: the generating seed, the archetype, and the entity address within that generation. Regeneration from the triple re-derives the untouched content as a deterministic function, per the World Engine’s generation rule. The alternative shape, stable global entity identifiers minted at persist time, trades re-derivation for an id registry; ADR-0064 Decision 4 records it as considered and rejected, with re-derivation measured too slow on device as the named revisit trigger.

Mission worlds stay run-state

Section titled “Mission worlds stay run-state”

Mission worlds stay ephemeral run-state as today: one region per mission, reset at the mission-instance boundary (world-engine.md). A mission world references the durable store where it touches it.

Writes and reads

Section titled “Writes and reads”

Writes go through the engine’s sanctioned mission-outcome path (the ADR-0043 / ADR-0055 pattern: the cart reports a goal, the engine applies the outcome). A planted record is an engine-applied outcome of a resolved mission; no cart or program writes the store. Under world-engine.md invariant 3, the one durable consequence of play is a sanctioned dossier-commit; this design widens the durable-consequence set to two sanctioned paths, and ADR-0064 ratifies the widening.

Reads are the verification query surface: single-row pre-check lookups, and the screener’s multi-tag joins run to a scrutiny depth.

Client outcomes touch the store nowhere

Section titled “Client outcomes touch the store nowhere”

Client orders for forged identities and their outcome mail run through Deck Hub, the deck’s acquisition surface (../programs/deck-hub.md; Josh, 2026-08-22). A client job resolves as a contract, so the fee lands through mission resolution, the sanctioned wallet writer; the mail is narrative plus a reputation event (maker blowback with a named cause). Neither the order, the mail, nor the event adds a write path to this store.

Sizing

Section titled “Sizing”

The one new engineering requirement is durability: world records must survive across missions and cartridge swaps, persisting the way DOSSIER’s store does. Sizing the store is the first implementation question, and the question is a measurement: how many records the device holds before its actual limits are reached. Capacity expands as needed until those limits are met; no predetermined byte budget constrains the design.

Migration notes

Section titled “Migration notes”
  • Staleness sweep, 2026-08-29. The narrative-seed provenance paragraph credited mission_board.c with the policy draw; the draw moved to mission/board-gen.lsp (GWP-777) and the C side parks the raw 32-bit value through the gen-draw-seed seam.