From d8af513a5ebb2f7cc76e25e729c4ffdac0cfc4dd Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Fri, 22 May 2026 19:55:01 +0200 Subject: [PATCH] =?UTF-8?q?docs(decisions):=20Q-098=20=E2=80=94=20persiste?= =?UTF-8?q?nce=20of=20generated=20river/city=20mapping=20outputs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Looking-ahead question from the Phase 4 markers strip. Generated mapping (rivers via drainage, cities via econ sim + placement) is deterministic so always recomputable, but expensive — should be computed once per body and kept, not volatile. Refines D-203 (LRU evicts) and D-200 (build-time bake vs runtime persist). Gates the atlas viewer (#960). To resolve during the execution-model work (#952). Co-Authored-By: Claude Opus 4.7 (1M context) --- decisions/questions-architecture.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/decisions/questions-architecture.md b/decisions/questions-architecture.md index 0d43288b1..99b325df4 100644 --- a/decisions/questions-architecture.md +++ b/decisions/questions-architecture.md @@ -330,4 +330,12 @@ Technical foundation questions: engine, protocols, data structures, performance, --- -*46 questions (8 resolved, 1 partially resolved, 37 open). Last updated: 2026-04-05.* +### Q-098: Persistence of generated river/city mapping outputs +- **Status:** Open — to resolve during Phase 4 execution-model work (#952) +- **Question:** The deterministic cascade can recompute river courses (D8 drainage, D-208) and city placements (economic sim + attractor matching, D-211) from seed at any time, so persisting them is a *cost* optimization, not a correctness need. But the compute is expensive — recomputing per session or per atlas view is waste. How are these mapping outputs persisted so they are computed **once per body and kept**? D-203's BodyWorldState cache is an LRU — it *evicts* (volatile). The fork: **(a)** build-time bake into `systems.db` (D-200 build-time tier — precompute all, ship); **(b)** lazy compute + persist at runtime (cache DB / savegame — compute on first visit, keep); **(c)** hybrid. Whatever the answer, the in-memory LRU should sit over a *durable* store so eviction triggers a cheap reload, not a recompute. +- **Context:** Raised 2026-05-22 looking ahead from the Phase 4 markers strip (#951). Refines D-200 (three-tier execution) and D-203 (LRU cache). Gates the Atlas layer viewer (#960), which needs persisted mapping to render without recomputing. Determinism (#952) guarantees recompute is always a valid fallback. +- **Cross-reference:** [D-200](architecture.md#d-200), [D-203](architecture.md#d-203), [D-208](architecture.md#d-208), [D-211](architecture.md#d-211), #952 (determinism harness), #960 (atlas viewer) + +--- + +*47 questions (8 resolved, 1 partially resolved, 38 open). Last updated: 2026-05-22.*